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
