Programmatic enforcement is outside the scope of the BRs. I'd like to do something (as CAs) to remediate the issue.
-----Original Message----- From: Rob Stradling [mailto:[email protected]] Sent: Monday, March 7, 2016 4:04 AM To: Jeremy Rowley Cc: [email protected] Subject: Fixing the BR scope (was Re: More SHA-1 certs) On 04/03/16 23:41, Jeremy Rowley wrote: > > My fix is much simpler (because the BRs have traditionally avoided requiring reissuance of sub CAs). Require that all certs with serverauth, anyEKU, or no EKU be covered by the BRs. CAs required to issue certs that are covered but cannot conform (because of another policy) will get a qualified audit that can then be addressed with the browsers. There's no reason to make an exception since all three types can be used for server authentication. This gives everyone notice the CA is issuing non-compliant certs that may be risky but lets the browsers decide whether to accept the risk. [It's clearly time to change the Subject line :-) ] Hi Jeremy. Your fix would be an improvement over the current BR scope, but I agree with Andrew and Ryan [1] that we need to go further than that: if a cert is in scope, then all certs issued by its issuer need to be in scope. I don't think relying on qualified audits is the way to go. I'd like to see programmatic enforcement. I think browsers should "blacklist" intermediates that don't intend to issue, but are nonetheless capable of issuing, publicly trusted TLS certs. [1] https://www.mail-archive.com/dev-security-policy%40lists.mozilla.org/msg0298 5.html -- Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
