On 02/01/2019 17:17, Wayne Thayer wrote:
On Wed, Jan 2, 2019 at 7:10 AM Rob Stradling via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
On 02/01/2019 13:44, info--- via dev-security-policy wrote:
El miércoles, 2 de enero de 2019, 12:49:52 (UTC+1), Rob Stradling
escribió:
On 09/10/2018 23:53, Wayne Thayer wrote:
On Tue, Oct 9, 2018 at 3:43 AM Rob Stradling wrote:<snip>
Wayne, Kathleen:
Given the number of times that all the CAs in Mozilla's Root
Program
have been reminded about Mozilla's requirements for disclosing
intermediate certs, I wouldn't blame you if you decided to add
these 20
intermediate certs [5] to OneCRL immediately!
I think we should give this serious consideration, although it doesn't
help with the majority of these that are trusted for email.
Hi Wayne. Did you give this serious consideration?
The options to consider are:
1. Continue with current policy of treating non-disclosure of unconstrained
intermediates as an incident. This could eventually lead to having the
offending intermediate added to OneCRL, but in practice it never has
because disclosure is not difficult.
No comment
2. Change our policy to state that any undisclosed intermediate we discover
will be immediately and permanently added to OneCRL.
This needs adding some logical criteria, notably:
- Allow the SubCA certificate itself and any related technical
signatures (CRL, OCSP signer, test site signatures etc.) and deeper
SubSubCAs to be generated and added to CT as part of the signing
ceremony before submission. This of cause within the reporting
deadline already specified in Mozilla policy for new SubCAs.
- Send a stern warning e-mail to the CA contact when 2/3 of the time
between SubCA generation and deadline expiry has passed.
- Include a manual review to check for misidentification of SubCA
submission policy violations (such as the Izenpe case earlier today).
- An exception if there was a relevant CCADB issue (downtime,
configuration, account problems etc.) during the CCADB submission
deadline.
- In OneCRL, add a separate OneCRL reason marker for SubCAs revoked in
for this reason only. This to allow extremely space or bandwidth
constrained OneCRL consumers to omit those, as well as to provide
truthful error messages in full clients such as Firefox.
3. Wait for the "intermediate preloading" feature to ship in Firefox. As
currently defined, this is not an enforcement mechanism for disclosure, but
it could be.
Note however that there is always the issue that "intermediate
preloading" will typically only update along the browser/mailclient
/other software release schedule while SubCAs can be validly created and
disclosed at any time (in practice: On the CAs root ceremony schedule).
4. Assume that CT enforcement will (eventually, on some undefined timeline
for Firefox) force intermediate disclosures and eliminate the need for
Mozilla to require CAs to manually disclose serverAuth intermediates in
CCADB.
CT disclosed SubCAs not in CCADB are the typical case of currently
detected violations. Thus CT enforcement would not fix this unless CT
enforcement causes the CCADB disclosure rule to be removed/relaxed as
redundant.
I don't expect options 3 and 4 to be viable for S/MIME certificates anytime
soon, so different options might be chosen for TLS and S/MIME.
I'm interested to hear if anyone has opinions on these options.
Enjoy
Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded
_______________________________________________
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy
