On 5/4/2018 12:02 πμ, Wayne Thayer via dev-security-policy wrote:
In a recent discussion [1] we decided to clarify the audit requirements for
new subordinate CA certificates. I’ve  drafted a change that requires the
new certificate to appear in the next periodic audits and in the CP/CPS
prior to issuance:


We also discussed requiring root key generation ceremony (RKGC) audit
reports, but I have since realized that the BRs (section only
require these audit reports for new root certificates. I’m not convinced
that we should begin requiring an auditor’s report every time a new
subordinate CA certificate is created.

I would appreciate everyone's comments on this proposed change.

This is: https://github.com/mozilla/pkipolicy/issues/32


This is a proposed update to Mozilla's root store policy for version
2.6. Please keep discussion in this group rather than on GitHub. Silence
is consent.

Policy 2.5 (current version):
dev-security-policy mailing list

I will copy the proposed change here for convenience:


1. MUST be audited in accordance with Mozilla’s Root Store Policy. If
   the subordinate CA has a currently valid audit report at the time of
   creation of the certificate, it MUST appear on the subordinate CA's
   next periodic audit reports.
2. MUST be publicly disclosed in the CCADB by the CA that has their
   certificate included in Mozilla’s root program. The CA with a
   certificate included in Mozilla’s root program MUST disclose this
   information within a week of certificate creation, and before any
   such subordinate CA is allowed to issue certificates. All disclosure
   MUST be made freely available and without additional requirements,
   including, but not limited to, registration, legal agreements, or
   restrictions on redistribution of the certificates in whole or in part.
3. MUST be added to the relevant CP/CPS before issuing certificates.


I kind of disagree with 3. The new Subordinate CA Certificate MUST be added to CCADB (per 2.). It MUST be covered by the audit (per 1.) and show up in the next report. If a Subordinate CA is operated by the Root operator, a change in the CP/CPS could probably be just an addition of the Distinguished Name and a SHA fingerprint. However, CPS changes require administrative work and several levels of approval which IMHO is not worth the effort for such an addition. I don't see such a big value for 3. compared to 1. and 2.

Consider the case where you have a Subordinate CA Certificate that you need to update because you want to change the hashing algorithm (SHA1 --> SHA256), or change the key size, or renew. This would lead to a new subCA Certificate with CN "My Subordinate CA Certificate R2",  "My Subordinate CA Certificate R3" and so on. The controls would be exactly the same as the previous subCA Certificate.

The 3rd requirement might make more sense for externally operated Subordinate CAs. According to BRs, Key Pairs that are generated for SubCAs not to be used by the Root CA operator or an Affiliate (meaning an externally operated Subordinate CA), MUST be witnessed by a Qualified Auditor (or record the ceremony and get an opinion letter afterwards). It seems that the BRs require some special treatment when a SubCA Key Pair is generated for an externally operated entity. Is it worth the effort to reflect a similar distinction in the Mozilla Policy?

dev-security-policy mailing list
  • Policy 2.6 Proposal: Audit ... Wayne Thayer via dev-security-policy
    • Re: Policy 2.6 Proposa... Dimitris Zacharopoulos via dev-security-policy
      • Re: Policy 2.6 Pro... Ryan Sleevi via dev-security-policy
        • Re: Policy 2.6... Dimitris Zacharopoulos via dev-security-policy
          • RE: Policy... Ben Wilson via dev-security-policy
            • Re: P... Wayne Thayer via dev-security-policy
              • R... Ben Wilson via dev-security-policy
                • ... Wayne Thayer via dev-security-policy
                • ... Wayne Thayer via dev-security-policy
                • ... Wayne Thayer via dev-security-policy

Reply via email to