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
--
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.
Additionally, please respond with one of the following:
A) All intermediate certificates chaining up to our certificates in
Mozilla's CA program have either been audited according to Mozilla's CA
Certificate Inclusion Policy, 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>
--
Thanks,
Kathleen
_______________________________________________
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy
