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
_______________________________________________
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy
