On 22/09/15 09:34, Brian Smith wrote:
On 22/09/15 01:01, Brian Smith wrote:
<snip>
But, if the intermediate CA certificate is allowed to issue SSL
certificates, then including the EKU extension with id-kp-serverAuth is
just wasting space. Mozilla's software assumes that when the intermediate
CA certificate does not have an EKU, then the certificate is valid for all
uses. So, including an EKU with id-kp-serverAuth is redundant. And, the
wasting of space within certificates has material consequences that affect
performance and thus indirectly security.
Brian,
Given that the BRs require id-kp-serverAuth in Technically Constrained
intermediates, what would be the point of Mozilla dropping that same
requirement?
There seems little point providing options that, in reality, CAs are never
permitted to choose.
It would be the first step towards changing the BRs in the analogous manner.
Even if Mozilla and the BRs make that change, many CAs will still have
to include id-kp-serverAuth in intermediates (even
non-technically-constrained intermediates!) due to Microsoft's requirements.
https://aka.ms/rootcert Section 4.A.12, for example, says...
"Rollover root certificates, or certificates which are intended to
replace previously enrolled but expired certificates, will not be
accepted if they combine server authentication with code signing uses
unless the uses are separated by application of Extended Key Uses
(“EKU”s) at the intermediate CA certificate level that are reflected in
the whole certificate chain."
The number of CAs that issue server authentication certs that are
intended to be used solely by Mozilla's software is, I suspect,
vanishingly small.
--
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
