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_Changes
to (hopefully) make things more clear.
Hopefully this CA Communication will be ready to send on Monday.
Thanks,
Kathleen
_______________________________________________
dev-security-policy mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-security-policy
