On Mon, Mar 7, 2016 at 12:04 PM, Jeremy Rowley <[email protected]> wrote:
> Programmatic enforcement is outside the scope of the BRs. I'd like to do > something (as CAs) to remediate the issue. > But the potential for programmatic enforcement by browsers is a factor for all CABF members to consider when creating the BRs. -- Eric > > -----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 > > > _______________________________________________ > dev-security-policy mailing list > [email protected] > https://lists.mozilla.org/listinfo/dev-security-policy > > -- konklone.com | @konklone <https://twitter.com/konklone> _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
