On 02/01/2019 23:40, Wayne Thayer wrote: > 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. >
There is the date fields in the SubCA certificate itself, as well as any embedded CT data (assuming the parent CA is correctly CT-logged). This e-mail is simply to reduce the frequency of "Oops, we did everything else, except log into CCADB and manually add the cert". And by sending it before the established policy deadline, the policy isn't weakened. > - 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. >> Because someone else asked: Since others are consuming the Mozilla root list, some of those may want to also consume OneCRL. If they distribute OneCRL over an extremely low bandwidth protocol to low-memory devices (IoT etc.) they may wish to filter out these "blocked for policy reasons only" entries in a proxy of their own design, using scarce resources only for more severe revocations. The clearer error message would be a secondary use of the data (to be discussed in the UI design forums). Here I am simply suggesting making this data about the decisions of the Mozilla root program available in computer readable form, while giving two examples of why this data might be useful outside this forum. >>> 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. > Ah, I wasn't aware, I thought is would be in the NSS root data blob, like a few SubCAs historically included in other root stores. >> 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. > There should still be a policy requirement to disclose unconstrained 3rd party SubCAs, along with the relevant policy data. >> 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
