(I'm replying to the topic as posed in the abstract and as a user with Mozilla hat off. No suggestion of applicability to cases currently under discussion should be inferred.)
On Wed, Aug 31, 2016 at 10:43 PM, Nick Lamb <[email protected]> wrote: > 1. Implement "Require SCTs" for problematic CAs. Notify the CA they are > obliged to CT log all certificates, inform subscribers etc. or their > subscriber's certificates will suddenly be invalid in Firefox from some > future date. ... > 2. Create "at risk" category for problematic CAs which lasts some finite > period of time (or a period to be set in each case). Notify the CA they are > obliged to warn their subscribers of this status or leave the Mozilla > programme immediately. Publicly announce "at risk" status and drive as PR. ... > 3. Split NSS trust store into two or more categories based on degree of > trustworthiness. Maybe present a Firefox pref to pick "secure" vs "compatible" Maybe these are too obvious, but let's mention these for completeness anyway: 4. Stop giving EV treatment to certs designated as EV by problematic CAs. 5. Show the "sites with mixed content allowed" icon (see https://blog.mozilla.org/tanvi/2016/01/26/updated-firefox-security-indicators/ ) when some connection contributing to the current browsing context tree uses a cert from a problematic CA with doorhanger text customized to talk about problematic status of CA. 6. Distrust certificates whole notBefore is before a designated point in time or whose notAfter minus legitimate validity period is after a designated point in time. Since the CA, technically, could backdate certs, for this option to make sense there'd need to be some credible incentive not to backdate certs. (It's not logically necessary for incentive to arise from Mozilla's root program or Firefox's behavior as long as an incentive exists.) On Thu, Sep 1, 2016 at 10:30 AM, Ryan Sleevi <[email protected]> wrote: > What was discussed in the Forum is the lack of defined policies for what it > means to "implement CAA". For example, if Trustwave were to see a CAA record > for "symantec.com", could it issue the cert? Couldn't the CAA contents that allow the problematic CA to issue certs be enumerated as part of the "problematic" designation? > To what forms does the CAA record apply with regards to issuance - for > example, if a CA were to go in person, sit down in front of the CTO/COO, > verify their passport, verify with their lawyers that the CTO was duly > authorized, then even if the CAA record said otherwise, could they issue then? I'd expect issuance not to be allowed in that case (at least if the CAA record is still there after clearing DNS caches). Surely a legitimate CTO should have the means to have the CAA record adjusted (even if a CTO couldn't change a mistakenly long previously-set TTL). -- Henri Sivonen [email protected] https://hsivonen.fi/ _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
