On Wed, Jan 2, 2019 at 11:32 AM Jakob Bohm via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote:
> On 02/01/2019 17:17, Wayne Thayer wrote: > > 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. > > How do we know about the SubCA if it hasn't been disclosed? By the time the SubCA appears in CT, the 1-week disclosure deadline has very likely 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). > > Intermediate preloading will use the same distribution mechanism as OneCRL. Yes, there will be some delay before a new intermediate is known by most/all clients, but the timescale is hours, not weeks. > 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. > > Yes, the idea is that CT could remove the need to enforce intermediate disclosures via policy. > 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 > _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
