Re: Amazon Root Inclusion Request

[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 

Re: Japan GPKI Root Renewal Request

[Andrew R. Whalley]

On Fri, Aug 5, 2016 at 5:39 AM, Peter Kurrasch  wrote:

> Kathleen--
>
> As I understand it, the request is for only CA2(Root) to be included in
> the trust store. Is that correct?
>
> The CP/CPS document submitted for the CA2(Root) hardly seems sufficient to
> satisfy anyone for one simple reason: there is no detail! I'm surprised the
> auditors (KPMG in this case) found this to be acceptable. If the CA2(Sub)
> ‎is not to be included in the Mozilla trust store then I don't see how it's
> CP/CPS can be reviewed for consideration here.
>

I've been mulling over this too.  While it does say it complies with the
BRs and they take priority, it is indeed very under specified.

I would refer the Government of Japan, Ministry of Internal Affairs and
Communications to the Amazon Trust Services CP/CPS as an example of how to
adhere closely to the BRs while still providing sufficient detail.

Andrew


> My recommendation is to reject this request and ask that the root's
> documentation be rewritten to reflect the policies and procedures that
> apply to all certs that chain to this root.
>
>
> *From: *Eric Mill
> *Sent: *Wednesday, July 20, 2016 8:15 PM‎
>
> For some reason, Gmail split up this thread into two for me. In case anyone
> else is having similar issues, here's the original detail for this request:
>
> On Wed, Apr 27, 2016 at 4:56 PM, Kathleen Wilson 
> wrote:
>
> > This request by the Government of Japan, Ministry of Internal Affairs and
> > Communications, is to include the GPKI 'ApplicationCA2 Root' certificate
> > and enable the Websites trust bit. This new root certificate has been
> > created in order to comply with the Baseline Requirements, and will
> > eventually replace the 'ApplicationCA - Japanese Government' root
> > certificate that was included via Bugzilla Bug #474706. Note that their
> > currently-included root certificate expires in 2017, and will be removed
> > via Bugzilla Bug #1268219.
> >
> > The request is documented in the following bug:
> > https://bugzilla.mozilla.org/show_bug.cgi?id=870185
> >
> > 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=8673399
> >
> > Noteworthy points:
> >
> > * The primary documents are the Root and SubCA CP/CPS, provided in
> > Japanese and English.
> >
> > Document Repository (Japanese):
> > http://www.gpki.go.jp/apca/cpcps/index.html
> > Document Repository (English):
> > https://www2.gpki.go.jp/apca2/apca2_eng.html
> > Root CP/CPS:
> > https://www2.gpki.go.jp/apca2/cpcps/cpcps_root_eng.pdf
> > SubCA CP/CPS:
> > https://www2.gpki.go.jp/apca2/cpcps/cpcps_sub_eng.pdf
> >
> > * CA Hierarchy: This root certificate has one internally-operated
> > subordinate CA that issues end-entity certificates for SSL and code
> signing.
> >
> > * This request is to turn on the Websites trust bit.
> >
> > SubCA CP/CPS section 3.2.2, Authentication of organization identity
> > As for the application procedure of a server certificate, ... the LRA
> > shall verify the authenticity of the organization to which the subscriber
> > belongs according to comparing with organizations which were written in
> the
> > application by directory of government officials that the Independent
> > Administrative Agency National Printing Bureau issued.
> >
> > SubCA CP/CPS section 3.2.3, Authentication of individual identity
> > As for the application procedure of a server certificate, ... the LRA
> > shall verify the authenticity of the subscriber according to comparing
> with
> > name, contact, etc. which were written in the application by directory of
> > government officials that the Independent Administrative Agency National
> > Printing Bureau issued.
> > The LRA also check the intention of an application by a telephone or
> > meeting.
> >
> > SubCA CP/CPS section 4.1.2, Enrollment process and responsibilities
> > (1) Server certificate
> > The subscriber shall apply accurate information on their certificate
> > applications to the LRA.
> > The LRA shall confirm that the owner of the domain name written as a
> > name(cn) of a server certificate in the application form belongs to
> > Ministries and Agencies who have jurisdiction over LRA, or its related
> > organization with the thirdparty databases and apply accurate information
> > to the Application CA2(Sub).
> >
> > * Mozilla Applied Constraints: This CA has indicated that the CA
> hierarchy
> > may be constrained to the *.go.jp domain.
> >
> > * Root Certificate Download URL:
> > https://bugzilla.mozilla.org/attachment.cgi?id=8673392
> > https://www.gpki.go.jp/apca2/APCA2Root.der
> >
> > * EV Policy OID: Not requesting EV treatment
> >
> > * Test Website:
> > https://www2.gpki.go.jp/apca2/apca2_eng.html
> >
> > * CRL URLs:
> > http://dir.gpki.go.jp/ApplicationCA.crl
> > http://dir2.gpki.go.jp/ApplicationCA2Root.crl
> >