Amazon Root Inclusion Request

[Kathleen Wilson]

This request from Amazon is to enable EV treatment for the currently-included “Starfield Services Root Certificate Authority - G2 certificate, and to include the following 4 new root certificates, turn on the Email and Websites trust bits for them, and enable EV treatment for all of them.
- Amazon Root CA 1 (RSA key with a 2048 bit long modulus)
- Amazon Root CA 2 (RSA key with a 4096 bit long modulus)
- Amazon Root CA 3 (EC key on the NIST P-256 curve)
- Amazon Root CA 4 (EC key on the NIST P-384 curve)
All 4 of these new Amazon root certificates have cross-signed with the currently-included “Starfield Services Root Certificate Authority - G2” certificate.

The Amazon PKI is run by Amazon Trust Services ("Amazon"). Customers of the Amazon PKI are the general public. Amazon does not require that customers have a domain registration with Amazon, use domain suffixes where Amazon is the registrant, or have other services from Amazon.

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

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

Summary of Information Gathered and Verified:
https://bugzilla.mozilla.org/attachment.cgi?id=8734171

Noteworthy points:

* The primary documents are provided in English.

CA Document Repository https://www.amazontrust.com/
CP: http://www.amazontrust.com/repository/cp.pdf
CPS: http://www.amazontrust.com/repository/cps.pdf
Subscriber Agreement: https://www.amazontrust.com/repository/sa-1.1.pdf

* CA Hierarchy: The Amazon Root CAs will have internally-operated subordinate CAs that will issue certs for SSL, Code Signing, Email, etc. There will be separate subCAs for EV certificate issuance. Externally-operated subCAs are permitted according to the CPS.

* This request is to enable the Email and Websites trust bits for all 4 of the new Amazon root certs. The request is to also enable EV treatement for all 4 of the new Amazon root certs, as well as for the “Starfield Services Root Certificate Authority - G2” cert that is already included in NSS.

CPS section 3.2.2:
Amazon uses the following methods to confirm that the Applicant has control of or right to use Domain Names:
1. Confirming the Applicant as the Domain Name Registrant directly with the Domain Name Registrar; or
2. Confirming authorization of the Certificate’s issuance directly with the Domain Name Registrant using a Reliable Method of Communication verified by either (i) communication with the Domain Name Registrar or (ii) being listed as the contact information for “registrant”, “technical”, or “administrative” contacts listed in the WHOIS record for the Base Domain; or
3. Confirming authorization for the Certificate’s issuance through an email address created by prepending ‘admin’, ‘administrator’, ‘webmaster’, ‘hostmaster’, or ‘postmaster’ in the local part, followed by the at-sign (“@”), followed by the Domain Name, which may be formed by pruning zero or more components from the requested FQDN; or
4. Relying upon a Domain Authorization Document that meets the requirements listed below; or
5. Having the Applicant demonstrate control over the FQDN or Base Domain by making an agreed-upon change to information found to a file hosted in the “/.well-known/cabforum” directory at either the FQDN or the Base Domain in accordance with RFC 5785; or
6. Having the Applicant demonstrate control over the FQDN or Base Domain by the Applicant making a change to information in a DNS TXT record for the FQDN or Base Domain where the change is a random number with at least 128 bits of entropy provided to the Applicant by the CA; or
7. Having the Applicant demonstrate control over a FQDN by making an agreed upon change to DNS records for a Domain Name which is formed by pruning zero or more labels from the left side of the requested FQDN or formed by prepending a label to the left side of the requested FQDN where an appended label exhibits at least 128 bits of entropy and is provided to the Applicant by the CA; or
8. Having the Applicant demonstrate control over the requested FQDN by the CA confirming, in accordance with section 11.1.1, the Applicant’s controls the FQDN (or Base Domain of the FQDN) returned from a DNS lookup for CNAME records for the requested FQDN; or
9. Having the Applicant demonstrate control over the requested FQDN by the CA confirming, in accordance with section 11.1.2, that the Applicant controls an IP address returned from a DNS lookup for A or AAAA records for the requested FQDN; or
10. Having the Applicant demonstrate practical control over the FQDN by providing a TLS service on a host found in DNS for the FQDN and having the CA (i) initiate a TLS connection with the host and (ii) verify a response specified by the CA that exhibits 128 bits of entropy and is a in a format recognized as a valid TLS response.
Amazon does not use methods 9, 10, or 11 for validating wildcard names.

CPS section 3.2.2: Amazon uses the following methods to confirm the Applicant has control of or right to use Email Addresses:
1. Confirming authorization of the Certificate’s issuance by contacting the requested email address, or
2. Confirming control of the FQDN in the Domain portion of the Email address using methods 1, 2, 5, 7, or 8 above.

CP section 3.2.2.4: For each Fully-Qualified Domain Name listed in a Certificate, the CA SHALL confirm that, as of the date the Certificate was issued, the Applicant (or the Applicant’s Parent Company, Subsidiary Company, or Affiliate, collectively referred to as “Applicant” for the purposes of this section) either is the Domain Name Registrant or has control over the FQDN by:
1. Confirming the Applicant as the Domain Name Registrant directly with the Domain Name Registrar;
2. Communicating directly with the Domain Name Registrant using an address, email, or telephone number provided by the Domain Name Registrar;
3. Communicating directly with the Domain Name Registrant using the contact information listed in the WHOIS record’s “registrant”, “technical”, or “administrative” field;
4. Communicating with the Domain Name’s administrator using an email address created by prepending ‘admin’, ‘administrator’, ‘webmaster’, ‘hostmaster’, or ‘postmaster’ in the local part, followed by the at-sign (“@”), followed by the Domain Name, which may be formed by pruning zero or more components from the requested FQDN;
5. Relying upon a Domain Authorization Document;
6. Having the Applicant demonstrate practical control over the FQDN
by making an agreed-upon change to information found on an online Web page identified by a uniform resource identifier containing the FQDN; or
7. Using any other method of confirmation, provided that the CA maintains documented evidence that the method of confirmation establishes that the Applicant is the Domain Name Registrant or has control over the FQDN to at least the same level of assurance as those methods previously described.
Note: For purposes of determining the appropriate domain name level or Domain Namespace, the registerable Domain Name is the second-level domain for generic top-level domains (gTLD) such as .com, .net, or .org, or, if the Fully Qualified Domain Name contains a 2 letter Country Code Top-Level Domain (ccTLD), then the domain level is whatever is allowed for registration according to the rules of that ccTLD. If the CA relies upon a Domain Authorization Document to confirm the Applicant’s control over a FQDN, then the Domain Authorization Document MUST substantiate that the communication came from
either the Domain Name Registrant (including any private, anonymous, or proxy registration service) or the Domain Name Registrar listed in the WHOIS. The CA MUST verify that the Domain Authorization Document was either (i) dated on or after the certificate request date or (ii) used by the CA to verify a
previously issued certificate and that the Domain Name’s WHOIS record has not been modified since the previous Certificate’s issuance.

CP section 3.2.2.5 Authentication for an IP Address
For each IP Address listed in a Certificate, the CA SHALL confirm that, as of the date the Certificate was issued, the Applicant has control over the IP Address by:
1. Having the Applicant demonstrate practical control over the IP Address by making an agreed-upon change to information found on an online Web page identified by a uniform resource identifier containing the IP Address;
2. Obtaining documentation of IP address assignment from the Internet Assigned Numbers Authority (IANA) or a Regional Internet Registry (RIPE, APNIC, ARIN, AfriNIC, LACNIC);
3. Performing a reverse-IP address lookup and then verifying control over the resulting Domain Name under Section 3.2.2.4; or
4. Using any other method of confirmation, provided that the CA maintains documented evidence that the method of confirmation establishes that the Applicant has control over the IP Address to at least the same level of assurance as the methods previously described.
Note: IPAddresses may be listed in Subscriber Certificates using IPAddress in the subjectAltName extension or in Subordinate CA Certificates via IPAddress in permittedSubtrees within the Name Constraints extension.

CP section 3.2.2.6 Wildcard Domain Validation
Before issuing a certificate with a wildcard character (*) in a CN or subjectAltName of type DNS-ID, the CA MUST establish and follow a documented procedure that determines if the wildcard character occurs in the first label position to the left of a “registry-controlled” label or “public suffix” (e.g. “*.com”, “*.co.uk”, see RFC 6454 Section 8.2 for further explanation).
If a wildcard would fall within the label immediately to the left of a registry-controlled or public suffix, CAs MUST refuse issuance unless the applicant proves its rightful control of the entire Domain Namespace. (e.g. CAs MUST NOT issue “*.co.uk” or “*.local”, but MAY issue “*.example.com” to Example Co.).

CP section 3.2.2: Authentication of organization identity
CP section 3.2.3: Authentication of individual identity
CP section 3.2.5: Validation of authority

Root Cert Download URLs:
https://www.amazontrust.com/repository/AmazonRootCA1.cer
http://www.amazontrust.com/repository/AmazonRootCA2.cer
http://www.amazontrust.com/repository/AmazonRootCA3.cer
http://www.amazontrust.com/repository/AmazonRootCA4.cer
https://www.amazontrust.com/repository/SFSRootCAG2.cer

EV OID to recognize for all of these root certs: 2.23.140.1.1
Note that this is the CA/Browser Forum EV OID.
https://bugzilla.mozilla.org/show_bug.cgi?id=1243923 - add support for CAB forum EV certificatePolicies OID (2.23.140.1.1)
The plan for resolution of bug #1243923 is to recognize the CA/Browser Forum’s EV OID for all root certificates that are enabled for EV treatment. CA’s may still also have one of their specific EV OIDs recognized in ExtendedValidation.cpp if needed.

Test Websites:
https://good.sca1a.amazontrust.com/
https://good.sca2a.amazontrust.com/
https://good.sca3a.amazontrust.com/
https://good.sca4a.amazontrust.com/
https://good.sca0a.amazontrust.com/

CRL:
http://crl.rootca1.amazontrust.com/rootca1.crl
http://crl.rootca2.amazontrust.com/rootca2.crl
http://crl.rootca3.amazontrust.com/rootca3.crl
http://crl.rootca4.amazontrust.com/rootca4.crl
http://crl.rootg2.amazontrust.com/rootg2.crl
CP section 4.9.7: CRL issuing frequency for subscriber certificates is at least once every seven days

OCSP:
http://ocsp.rootca1.amazontrust.com/
http://ocsp.sca1a.amazontrust.com
http://ocsp.rootca2.amazontrust.com/
http://ocsp.sca2a.amazontrust.com
http://ocsp.rootca3.amazontrust.com/
http://ocsp.sca3a.amazontrust.com
http://ocsp.rootca4.amazontrust.com/
http://ocsp.sca4a.amazontrust.com
http://ocsp.rootg2.amazontrust.com
http://ocsp.sca0a.amazontrust.com
CP section 4.9.10: OCSP responses from this service MUST have a maximum expiration time of ten days

* Audit: Annual audits are preformed by EY according to the WebTrust criteria.
Standard Audit: https://cert.webtrust.org/SealFile?seal=1998&file=pdf
BR Audit: https://cert.webtrust.org/SealFile?seal=1999&file=pdf
EV Audit: https://cert.webtrust.org/SealFile?seal=2000&file=pdf

* Potentially Problematic Practices:
(http://wiki.mozilla.org/CA:Problematic_Practices)
** Amazon allows externally operated subordinate CAs.
CPS section 4.2.2: For Applications for a Subordinate CA where the Subordinate CA will not be controlled by Amazon, Amazon ensures that all the following are true:
- The APPMA has approved the Subordinate CA
- There is a contract in place requiring the Subordinate CA to comply with CA/Browser Forum guidelines
- The CA generated and stores its keys on a HSM that meets the requirements in the CP
- The CA had the key generation audited by a qualified auditor. This is not required to be a WebTrust licensed auditor, but the auditor must meet items 1, 3, 6, and 7 of section 8.2 of the CP.
- If the Subordinate CA certificate is not technically constrained, then the contract requires theSubordinate CA operator to provide evidence of a WebTrust audit with a period ending not more than one year prior to application or a WebTrust point in time readiness assessment that occurred no more than one year prior to application. Additionally, the CA must have WebTrust audits covering periods no longer than one year in duration where each audit period must immediately start after the previous period end with no gaps.

This begins the discussion of the request from from Amazon to enable EV treatment for the currently-included “Starfield Services Root Certificate Authority - G2 certificate; and to include 4 new root certificates, turn on the Email and Websites trust bits for them, and enable EV treatment for all of them. 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.

Kathleen

[Andrew R. Whalley]

Here are the notes from my read-through. I commend Amazon for the clarity
of their CP and CPS.

Reviewed Amazon Trust Services Certificate Policy

Version 1.0.3

"This [CP] is intended to communicate the minimum operating requirements
for CAs in the Amazon PKI. By design, it closely follows the CA/Brower
[sic] Forum Guidelines and Requirements and only deviates when an
Application Software Supplier has requirements that are stricter…"


Good.

"Creative Commons Attribution-NoDerivatives 4.0 International License"

Good.

1.1.2 Types of Certificate

"A certificate is a Root CA-certificate if it a Policy CA-certificate and
the subject is designated by the CA as a Root CA in the CA’s CPS."

The Root CA-Certificates designated by the CPS are self signed, and match
the definition of "self issued" from section 1.1.2.1. However 1.1.2.1.7
says Root CA-Certificates are Policy CA-certificates and 1.1.2.1.4 says
Policy CA Certificates are cross-certificates, and 1.1.2.1 says that
cross-certificates are not self-issued certificates.

1.1.2.2 End-Entity Certificates

"CAs must not issue EndEntity Certificates that simultaneously meet the
criteria of multiple of the following categories."

Good.

3.2.1 Method to prove possession of private key

Section is blank. Assuming "No stipulation" rather than missing text?

6.5.1.4 Authentication: Passwords and Accounts

"For accounts that are accessible from outside a Secure Zone or High
Security Zone, require that passwords have at least eight (8) characters…"

Eight characters seems a bit short.

6.6.3 Life cycle security controls

"apply recommended security patches to Certificate Systems within six
months of the security patch’s availability"

Six months seems a bit long.

7.1.4.4 Subject Information for Extended Validation Server Authentication
certificates

Formatting bug - not rendered as a table.

(suggests that this came from a plaintext original - is that available
anywhere?)

Amazon Trust Service Certificate Practice Statement v1.0.4

3.2.2 Authentication of organization identity

"Amazon does not use methods 9, 10, or 11 for validating wildcard names"

There is no method 11

4.2.1 Performing identification and authentication functions

"Amazon Root CAs do not check CAA records prior to issuing certificates."

Pity.

4.4.3 Notification of certificate issuance by the CA to other entities

Amazon may notify the public of the issuance of a certificate by adding it
to one or more publicly accessible … CT Logs

Good

Appendix B: Certificate Profiles

"If the signatureAlgorithm uses SHA-1, the serial number must contain at
least 64 bits of randomly generated entropy"

What about non SHA-1?

Andrew

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

[Peter Bowen]

Andrew,

Thank you for your review of our CP and CPS. Please see our responses inline.

Thanks,
Peter

> On Aug 10, 2016, at 3:12 PM, Andrew R. Whalley <awha...@chromium.org> wrote:
>
> Here are the notes from my read-through. I commend Amazon for the clarity
> of their CP and CPS.
>
> Reviewed Amazon Trust Services Certificate Policy
>
> Version 1.0.3
>
> "This [CP] is intended to communicate the minimum operating requirements
> for CAs in the Amazon PKI. By design, it closely follows the CA/Brower
> [sic] Forum Guidelines and Requirements and only deviates when an
> Application Software Supplier has requirements that are stricter…"
>
> Good.
>
> "Creative Commons Attribution-NoDerivatives 4.0 International License"
>
> Good.
>
> 1.1.2 Types of Certificate
>
> "A certificate is a Root CA-certificate if it a Policy CA-certificate and
> the subject is designated by the CA as a Root CA in the CA’s CPS."
>
> The Root CA-Certificates designated by the CPS are self signed, and match
> the definition of "self issued" from section 1.1.2.1. However 1.1.2.1.7
> says Root CA-Certificates are Policy CA-certificates and 1.1.2.1.4 says
> Policy CA Certificates are cross-certificates, and 1.1.2.1 says that
> cross-certificates are not self-issued certificates.

You are correct that this definition is missing the self-issued case. We will update our CP to reflect this by changing the definition to:

A certificate is a Root CA-certificate if the subject is designated by the CA as a Root CA in the CA’s CPS and it is either a self-issued certificate or Policy CA-certificate.

> 1.1.2.2 End-Entity Certificates
>
> "CAs must not issue EndEntity Certificates that simultaneously meet the
> criteria of multiple of the following categories."
>
> Good.
>
> 3.2.1 Method to prove possession of private key
>
> Section is blank. Assuming "No stipulation" rather than missing text?

Yes, we will update our CP to state "No stipulation" for this section.

> 6.5.1.4 Authentication: Passwords and Accounts
>
> "For accounts that are accessible from outside a Secure Zone or High
> Security Zone, require that passwords have at least eight (8) characters…"
>
> Eight characters seems a bit short.

This is taken directly from the Network and Certificate System Security Requirements (NCSSR), section 2(g)(i).

> 6.6.3 Life cycle security controls
>
> "apply recommended security patches to Certificate Systems within six
> months of the security patch’s availability"
>
> Six months seems a bit long.

As with the prior item, this is directly from NCSSR, section 1(l).

> 7.1.4.4 Subject Information for Extended Validation Server Authentication
> certificates
>
> Formatting bug - not rendered as a table.

We will fix this markdown error in the next revision of our CP.

> (suggests that this came from a plaintext original - is that available
> anywhere?)

The Amazon CP is derived from the Public CP published on GitHub at https://github.com/pzb/PublicCP.

> Amazon Trust Service Certificate Practice Statement v1.0.4
>
> 3.2.2 Authentication of organization identity
>
> "Amazon does not use methods 9, 10, or 11 for validating wildcard names"
>
> There is no method 11

With the recent passage of Ballot 169 in the CA/Browser Forum, we will be updating 3.2.2 to comply with the new validation requirements and will fix this as part of the update.

> 4.2.1 Performing identification and authentication functions
>
> "Amazon Root CAs do not check CAA records prior to issuing certificates."
>
> Pity.
>
> 4.4.3 Notification of certificate issuance by the CA to other entities
>
> Amazon may notify the public of the issuance of a certificate by adding it
> to one or more publicly accessible … CT Logs
>
> Good
>
> Appendix B: Certificate Profiles
>
> "If the signatureAlgorithm uses SHA-1, the serial number must contain at
> least 64 bits of randomly generated entropy"
>
> What about non SHA-1?

We have included at least 64 bits of entropy in all certificates issued since mid-2015. In compliance with Baseline Requirements version 1.3.7, we will update our CPS to reflect such by September 30, 2016.

> Andrew

[Kathleen Wilson]

> This request from Amazon is to enable EV treatment for the
> currently-included “Starfield Services Root Certificate
> Authority - G2 certificate, and to include the following 4 new root
> certificates, turn on the Email and Websites trust bits for them,
> and enable EV treatment for all of them.
> - Amazon Root CA 1 (RSA key with a 2048 bit long modulus)
> - Amazon Root CA 2 (RSA key with a 4096 bit long modulus)
> - Amazon Root CA 3 (EC key on the NIST P-256 curve)
> - Amazon Root CA 4 (EC key on the NIST P-384 curve)
> All 4 of these new Amazon root certificates have cross-signed with the
> currently-included “Starfield Services Root Certificate Authority - G2”
> certificate.
>
>

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

Thank you, Andrew, for your thorough review of this request from Amazon Trust Services. I did not see any show-stoppers, so I think it is OK to proceed with approval of this request in parallel with Amazon updating their CPS.

Does anyone else have questions, comments, or concerns about this request?
If not, then I will proceed with recommending approval.

Thanks,
Kathleen

[Kathleen Wilson]

On Thursday, August 25, 2016 at 2:37:43 PM UTC-7, Kathleen Wilson wrote:
> Does anyone else have questions, comments, or concerns about this request?
> If not, then I will proceed with recommending approval.

Thanks again to those of you who participated in this discussion about Amazon Trust Services' request to include 4 new Amazon root certs, turn on the Email and Websites trust bits, and enable EV treatment for them. This request is also to enable EV treatment for the “Starfield Services Root Certificate Authority - G2" certificate.

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

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

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

Thanks,
Kathleen