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
On Thu, Aug 4, 2016 at 5:36 PM, Kathleen Wilson <kwil...@mozilla.com> wrote:
> 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
>
_______________________________________________
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy
