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.
--
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.
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?
Kathleen
_______________________________________________
dev-security-policy mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-security-policy
