Kathleen, Can you explain #5 a bit? I apologize if this was previously answered, but does this rule apply to all intermediates used by the CA itself or only those existing outside of the CA's PKI? Seems like ones operated solely by Te CA(and covered by the CA's audit) don't necessarily require disclosure (since they are under the audit). My confusion comes because of the use of "cross-certificate" in some parts of 8 where as other sections use "subordinate CA certificates". Can this be clarified?
Jeremy -----Original Message----- From: dev-security-policy [mailto:dev-security-policy-bounces+jeremy.rowley=digicert.com@lists.mozilla .org] On Behalf Of Kathleen Wilson Sent: Thursday, May 8, 2014 2:06 PM To: mozilla-dev-security-pol...@lists.mozilla.org Subject: Re: DRAFT: May CA Communication On 5/6/14, 12:05 PM, Kathleen Wilson wrote: > On 5/2/14, 1:36 PM, Peter Bowen wrote: >>> I don't think the policy allows for "c" (in regards to SSL certs). I >>> hope that eventually all of the non-technically constrained >>> intermediate certs will be part of some sort of database of allowed >>> (known and audited) intermediates. Then SSL certificate path >>> validation would fail if the chain contained an intermediate cert >>> that was not technically constrained and was not in the database. >>> >>> There's still plenty of work to do before this will be viable. >>> >>> Perhaps you're noticing an issue with the text in the CA Communication? >> >> You had proposed adding a C) for CAs who say they need more time for >> some subordinate CAs. I'm proposing that they should be required >> explicitly choose A, B, or C for each CA certificate in the heirarchy >> and to disclose some data about the C certs if Mozilla is going to >> allow them more time, so there is visibility into how many CA certs >> are out there that are not compliant with the policy. >> > > How about the following: > > > https://wiki.mozilla.org/CA:Communications#DRAFT_for_May.2C_2014 Tweaked it some more... -- 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 provide a URL to a web page or a Bugzilla Bug Number that lists all of your publicly disclosed intermediate certificates that chain up to certificates in Mozilla's CA program, and contains the required information according to section 10 of Mozilla's CA Certificate Inclusion Policy. If you decide to use the mozilla.org Bugzilla system to provide this information, then file the bug against the "CA Certificates" component of the "mozilla.org" product. (https://bugzilla.mozilla.org/enter_bug.cgi?product=mozilla.org&component=CA %20Certificates) Additionally, please respond with one of the following: A) All intermediate certificates chaining up to our certificates in Mozilla's CA program are either disclosed as requested above, or are technically constrained according to section 9 of Mozilla's CA Certificate Inclusion Policy. B) We request an extension for the following specific subordinate CAs who need more time to transition from their legacy systems to their new CA hierarchy: <list of issuer hash, issuer public key hash, and certificate serial 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> -- Also, re-ordered the items in https://wiki.mozilla.org/SecurityEngineering/mozpkix-testing#Behavior_Change s to (hopefully) make things more clear. Hopefully this CA Communication will be ready to send on Monday. Thanks, 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
