On Fri, May 2, 2014 at 10:05 AM, Kathleen Wilson <[email protected]> wrote: > In regards to action #5, I think we need to add another option to allow CAs > to specify if they have certain subordinate CAs who aren’t quite ready to > move off of their legacy systems for reasons such as: the migration to their > new system is taking longer than expected; or need to operate their legacy > subCAs a little longer to avoid service disruption. > > My goal is to move things in the right direction, I am OK with granting > extensions to subordinate CAs who can demonstrate that they have been > working towards the deadline, and explain why they need a little more time. > > Therefore, I propose adding an option “C”, as follows. > -- > 5) Send Mozilla information about your publicly disclosed intermediate > certificates that chain up to certificates in Mozilla's CA program, as per > Items #8, 9, and 10 of Mozilla's CA Certificate Inclusion Policy. > > > Please respond with one of the following: > A) All intermediate certificates chaining up to our certificates in > Mozilla's CA program are either included in our annual audits and listed in > our annual audit statements, or are technically constrained according to > section 9 of Mozilla's CA Certificate Inclusion Policy. > B) The required information, according to section 10 of Mozilla's CA > Certificate Inclusion Policy, is available here: <URL to a web page, or > Bugzilla Bug Number>. > C) We request an extension for specific subordinate CAs who need more time > to transition from their legacy systems to their new CA hierarchy. For the > subordinate CAs who were able to meet the deadline, the required > information, according to section 10 of Mozilla's CA Certificate Inclusion > Policy, is available here: <URL to a web page, or Bugzilla Bug Number>. For > each subordinate CA who needs to operate in their legacy design a little > longer, the attached document explains the reason that continued operation > is needed and their target date for resolution. <attach document(s) to > response>
I'm a little confused by this after reading the policy again. For each certificate with the CA:TRUE basic constraint that chain up to one or more certificates in the Mozilla root program, it seems like there are three possible states: a) They are technically constrained. This is covered in items #8 and #9 in the policy. There does not appear to be any required disclosure of these certificates. b) They are publicly disclosed and audited. This is covered in items #8 and #10 in the policy. These should probably be tracked just like the certificates directly in the CA program. - A special case of b) is when the subject and public key of the subordinate CA is the same as a certificate in the Mozilla CA program. (i.e. one CA cross signs another CA) c) They are neither technically constrained nor publicly disclosed and audited. For the c) case, should the CA have to disclose anything about the certificate? Maybe at least the issuer hash, issuer public key hash, and certificate serial number (the same data used for OCSP)? This would at least provide some visibility into the number of certificates in group c). If more detail is desired, the not_after date, path length constraint (if any), and Mozilla-recognized EKUs in the certificate could also be requested to give a some visibility without disclosing the customer identity. Thanks, Peter _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
