Re: Amazon Root Inclusion Request

2016-09-08 Thread 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 
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy


Re: Amazon Root Inclusion Request

2016-08-25 Thread 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


___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy


Re: Amazon Root Inclusion Request

2016-08-15 Thread 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  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
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy


Re: Amazon Root Inclusion Request

2016-08-10 Thread 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

On Thu, Aug 4, 2016 at 5:36 PM, Kathleen Wilson  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
> co