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/msg02985.html

--
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online

_______________________________________________
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Reply via email to