On Fri, May 2, 2014 at 1:09 PM, Kathleen Wilson <[email protected]> wrote: > On 5/2/14, 11:17 AM, Peter Bowen wrote: >> 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. >>> -- >>> 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. > > 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. Thanks, Peter _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
