Include Symantec-brand Class 1 and Class 2 Root Certs

[Kathleen Wilson]

This request from Symantec is to include the following 4 root certificates and enable the Email trust bit for them.
1) Symantec Class 1 Public Primary Certification Authority - G6
2) Symantec Class 2 Public Primary Certification Authority - G6
3) Symantec Class 1 Public Primary Certification Authority - G4
4) Symantec Class 2 Public Primary Certification Authority - G4
These Symantec-brand root certs will eventually replace the VeriSign-brand class 1 and 2 root certs that are currently included in NSS.
The G6 root certs are SHA-256, and the G4 root certs are ECC.

The request is documented in the following bug:
https://bugzilla.mozilla.org/show_bug.cgi?id=833986

And in the pending certificates list:
https://wiki.mozilla.org/CA:PendingCAs

Summary of Information Gathered and Verified:
https://bug833986.bmoattachments.org/attachment.cgi?id=8798532

* Root Certificate Download URLs:
https://www.symantec.com/content/en/us/enterprise/verisign/roots/PCA_1_G6.pem
https://www.symantec.com/content/en/us/enterprise/verisign/roots/PCA_2_G6.pem
https://www.symantec.com/content/en/us/enterprise/verisign/roots/Symantec_Class_1_Public_Primary_Certification_Authority_G4.pem
https://www.symantec.com/content/en/us/enterprise/verisign/roots/Symantec_Class_2_Public_Primary_Certification_Authority_G4.pem

* The primary documents such as CP and CPS are provided in English.

CA Document Repository:
https://www.symantec.com/about/profile/policies/repository.jsp
CP Document:
https://www.symantec.com/content/en/us/about/media/repository/stn-cp.pdf
CPS Document:
https://www.symantec.com/content/en/us/about/media/repository/stn-cps.pdf

* CA Hierarchy: These root certs will be used to sign Class 1 and Class 2 subordinate CAs for SMIME and Client Auth purposes. SubCA keys will operate at Symantec or Symantec Affiliate sites.

* This request is to turn on the Email trust bit for these root certs.

** CP and CPS section 3.2.2: Where a domain name or e-mail address is included in the certificate Symantec or an Affiliate authenticates the Organization’s right to use that domain name either as a fully qualified Domain name or an e-mail domain.

** CP and CPS section 3.2.3:
*** Class 1 -- No identity authentication.
Limited confirmation that the certificate subscriber has access to the email address.
Symantec performs a challenge-response type of procedure in which Symantec sends email to the email address to be included in the certificate, containing unpredictable information such as a randomly generated PIN/Password unique to the owner of the email address. The owner of the email address (the subscriber of the certificate) demonstrates control over the email address by using the information within the email, to then proceed with accessing a portal with the unique information sent in the email, to download and install the certificate.
*** Class 2 -- Authenticate identity by:
Manual check performed by the enterprise administrator customer for each subscriber requesting a certificate, “in which the subscriber receives the certificate via an email sent to the address provided during enrollment”
or
Passcode-based authentication where a randomly-generated passcode is delivered out-of-band by the enterprise administrator customer to the subscriber entitled to enroll for the certificate, and the subscriber provides this passcode at enrollment time
or
Comparing information provided by the subscriber to information contained in business records or databases (customer directories such as Active Directory or LDAP.

* EV Policy OID: Not Requesting EV treatment and not requesting the Websites trust bit for these root certs.

* Test Certs: An example cert chaining up to each root is provided as attachments in https://bugzilla.mozilla.org/show_bug.cgi?id=833986

* CRL URLs:
http://crl.ws.symantec.com/pca1-g6.crl
http://crl.ws.symantec.com/pca2-g6.crl
http://crl.ws.symantec.com/pca1-g4.crl
http://crl.ws.symantec.com/pca2-g4.crl

* Audit: Annual audits are performed by KPMG according to the WebTrust criteria.
https://www.symantec.com/content/en/us/about/media/repository/Symantec-STN-WTCA-2015.pdf
https://www.symantec.com/content/en/us/about/media/repository/1_symantec_stn_wtca_6-15-2016.pdf

* Potentially Problematic Practices:
(http://wiki.mozilla.org/CA:Problematic_Practices)
** Delegation of Domain / Email validation to third parties - CPS section 1.3.2: Third parties, who enter into a contractual relationship with Symantec or an affiliate, may operate their own RA and authorize the issuance of certificates by a STN CA. Third party RAs must abide by all the requirements of the STN CP, the relevant CPS and any Enterprise Service Agreement entered into with Symantec. RAs may, however implement a more restrictive practices based on
their internal requirements.
** Allowing external entities to operate subordinate CAs -- CPS section 1.3.1: Symantec enterprise customers may operate their own CAs as a subordinate CA to a
public STN PCA. Such a customer enters into a contractual relationship with Symantec to abide by all the requirements of the STN CP and the STN CPS. These subordinate CAs may, however implement more restrictive practices based on their internal requirements.

This begins the discussion of this request from Symantec to include the following four Symantec-brand root certificates, and turn on the Email trust bit for all of them.
1) Symantec Class 1 Public Primary Certification Authority - G6
2) Symantec Class 2 Public Primary Certification Authority - G6
3) Symantec Class 1 Public Primary Certification Authority - G4
4) Symantec Class 2 Public Primary Certification Authority - G4

At the conclusion of this discussion I will provide a summary of issues noted and action items. If there are outstanding issues, then an additional discussion may be needed as follow-up. If there are no outstanding issues, then I will recommend approval of this request in the bug.

Regards
Kathleen Wilson and Aaron Wu

[Nick Lamb]

Thanks Kathleen.

I have no substantive objections to this inclusion (with only the Email trust bit to be set) at this time but I do have a minor editorial nitpick which might as well go back to Symantec while we're here.

On page 1 of the Introduction of the CP document, a footnote refers to "this CPS" when I suspect "this CP" is intended, in the phrase

"this CPS describes practices that pertain to any Class 2 or Class 3 certificate"

And similar language "this CPS" referring to what is in fact a CP occurs in a few other places such as in the box out in 13.1 about the pulled roots.

[Richard Barnes]

On Thu, Oct 6, 2016 at 12:09 PM, Kathleen Wilson <kwi...@mozilla.com>
wrote:

> This request from Symantec is to include the following 4 root certificates
> and enable the Email trust bit for them.
>

To be clear: The request is for *only* the email trust bit to be set?

I seem to recall we had some discussion a while back about what criteria
should be applied to email CAs. Where did we end up on that?

--Richard

> _______________________________________________
> dev-security-policy mailing list
> dev-secur...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
>

[Peter Bowen]

On Thu, Oct 6, 2016 at 3:57 PM, Richard Barnes <rba...@mozilla.com> wrote:
> I seem to recall we had some discussion a while back about what criteria
> should be applied to email CAs. Where did we end up on that?

I don't believe anything was settled. There is one small item in the CA policy:

"for a certificate to be used for digitally signing or encrypting
email messages, the CA takes reasonable measures to verify that the
entity submitting the request controls the email account associated
with the email address referenced in the certificate or has been
authorized by the email account holder to act on the account holder’s
behalf;"

Other than that, I don't think there are any requirements. It isn't
clear to me that the subordinate CA disclosure rule even applies to
e-mail only roots.

Thanks,
Peter

[Kathleen Wilson]

On Thursday, October 6, 2016 at 4:27:10 PM UTC-7, Peter Bowen wrote:

> On Thu, Oct 6, 2016 at 3:57 PM, Richard Barnes wrote:
> > I seem to recall we had some discussion a while back about what criteria
> > should be applied to email CAs. Where did we end up on that?
>
> I don't believe anything was settled. There is one small item in the CA policy:
>
> "for a certificate to be used for digitally signing or encrypting
> email messages, the CA takes reasonable measures to verify that the
> entity submitting the request controls the email account associated
> with the email address referenced in the certificate or has been
> authorized by the email account holder to act on the account holder’s
> behalf;"
>
> Other than that, I don't think there are any requirements.

Correct. When we had the discussion about removing trust bits, the consensus was that we should continue supporting the email trust bit.

I think the long term intent is for the CAB Forum to eventually be structured in such a way that a working group of those interested in S/MIME certs would be formed to create Baseline Requirements for that type of cert. But, that's really a discussion for the CAB Forum.

So for now, we continue to review such CAs to make sure there aren't any obvious show-stoppers, and that the email address to be included in the certs is verified to be owned/controlled by the cert subscriber.

> It isn't
> clear to me that the subordinate CA disclosure rule even applies to
> e-mail only roots.
>

We consider roots with only the email trust bit enabled to be technically constrained, such that their subCAs don't need to be disclosed.

Thanks,
Kathleen

[Jakob Bohm]

But they are not constrained as to what e-mail addresses they can
certify and at what trust level. An EV-like e-mail certificate (in
mozilla terms) is usually the same as an e-signature legally binding
person certificate (in national/regional legislative terms), making
them in some ways much more powerful than web certificates.

Especially considering the ongoing discussion of cross-signatures of a
CA that might be distrusted, disclosure of e-mail only cross signatures
and e-mail only subCAs still need to be disclosed in order to maintain
root program integrity.



Enjoy

Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded

[Matt Palmer]

On Fri, Oct 07, 2016 at 09:05:37PM +0200, Jakob Bohm wrote:
> On 07/10/2016 19:14, Kathleen Wilson wrote:

> But they are not constrained as to what e-mail addresses they can
> certify and at what trust level. An EV-like e-mail certificate (in
> mozilla terms) is usually the same as an e-signature legally binding
> person certificate (in national/regional legislative terms), making
> them in some ways much more powerful than web certificates.

Are there any legislation that says, "any trust anchor in the Mozilla store
with the e-mail trust bit turned on is automatically a valid signature trust
anchor", though? I'd expect that legislative frameworks would be at least a
*little* more prescriptive in their standards for identity verification for
digital signatures, and a trust anchor's compliance with *those* standards
would be far more important than whether or not it's in the Mozilla trust
store.

That's not to say that having more rigorous standards for inclusion in the
Mozilla root store with e-mail bit enabled wouldn't be good to have, but I
doubt that "legally binding e-signature" is a meaningful argument.

- Matt

[Kathleen Wilson]

This request from Symantec is to only enable the Email trust bit for the following 4 root certificates that will eventually replace the VeriSign-brand class 1 and 2 root certs that are currently included in NSS.

1) Symantec Class 1 Public Primary Certification Authority - G6
2) Symantec Class 2 Public Primary Certification Authority - G6
3) Symantec Class 1 Public Primary Certification Authority - G4
4) Symantec Class 2 Public Primary Certification Authority - G4

The G6 root certs are SHA-256, and the G4 root certs are ECC.

If there are no objections or concerns about this request, then I will recommend approval in the bug.
https://bugzilla.mozilla.org/show_bug.cgi?id=833986

Thanks,
Kathleen

[Jakob Bohm]

Practical note regarding that future replacement:

When deprecating CA certificates with the e-mail trust bit set, please
consider the common use case of reading an old e-mail or posting
in Mozilla Thunderbird, thus causing Thunderbird to verify a signature
made with a certificate likely to have both validity periods and
issuing CA consistent with its old date (as verified by the Received
date from the recipient's own mail server).

[Tarah Wheeler]

Thanks, Jakob; I'll try and replicate that to check.

Tarah Wheeler
Principal Security Advocate
Senior Director of Engineering, Website Security
Symantec
ta...@symantec.com


> On Nov 17, 2016, at 2:13 AM, "dev-security-...@lists.mozilla.org" <dev-security-...@lists.mozilla.org> wrote:
>
> Re: Include Symantec-brand Class 1 and Class 2 Root Certs

[Kathleen Wilson]

On Tuesday, November 15, 2016 at 3:58:26 PM UTC-8, Kathleen Wilson wrote:
> If there are no objections or concerns about this request, then I will recommend approval in the bug.

Thanks to those of you who reviewed and commented on this request from Symantec to include their Symantec-brand Class 1 and Class 2 root certs and enable the email trust bit for them.

I am now closing this discussion and will recommend approval in the bug.

https://bugzilla.mozilla.org/show_bug.cgi?id=833986

Any further follow-up on this request should be added directly to the bug.

Thanks,
Kathleen