On Wed, Jan 2, 2019 at 11:18 AM Wayne Thayer via dev-security-policy < dev-security-policy@lists.mozilla.org> 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. > 2. Change our policy to state that any undisclosed intermediate we discover > will be immediately and permanently added to OneCRL. > 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. > 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. > Given the timescales of intermediates (5-10 years) vs other certificates, it's unclear how #4 would be done. I suspect that, between #3 and #4, that #3 is probably functionally far more attractive, and operationally cleaner for CAs (given the offline nature of intermediate signing ceremonies due to the root key material). I think of the first two, #2 is more appealing than #1, as it avoids the needs to distinguish malice from operational failure, and thus provides something clear and automatable (from the client side), thus removing the necessity of discussion. #3 simply moves this from a "permanent" state to a "temporary" state, which doesn't seem like it changes much for Subscribers, but is friendlier to CAs that have operational failures. So it sounds like a combination of #3+#1 (treating it as an incident, but allowing for temporary blocking) may be a balanced approach if leniency for operational mistakes are desired, otherwise, #2 seems the easiest to set expectations and not have to litigate/renegotiate/investigate every time it happens. #4 is just a different technical means to approaching some variation of #3/#2, but with different tradeoffs, and less predictability (embedded proofs vs TLS-delivered / OCSP stapled proofs) Thus, a preference is: #2 (combination of #3 + #1) #4 _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
