On 05/12/16 22:43, Brian Smith wrote:
<snip>
That's true, but at the same time we want to have standardized behavior
right? Mozilla is or will be asking people to go beyond existing standards
by:
1. Honoring Microsoft's semantics for EKU in intermediates.
2. Dropping support for interpreting the subject CN as a domain name or IP
address.
3. Maybe requiring an explicit EKU in the end-entity certificate.
My point is that #1 and #2 are already sufficient to solve this problem.
Let's make it easy for people to agree with Mozilla, by not requiring more
than is necessary, #3.
Mozilla's CA Certificate Inclusion Policy already requires that
"issuance of certificates to be used for SSL-enabled servers must also
conform to" the BRs, and most other browser providers already require
this too.
For Subscriber Certificates, the CABForum BRs already require that...
"F. extKeyUsage (required)
Either the value id‐kp‐serverAuth [RFC5280] or id‐kp‐clientAuth
[RFC5280] or both values MUST be present."
Since the policy already requires #3, ISTM that the technical
implementation should enforce #3 (unless there's a really good reason
not to).
For it to make any sense to not enforce #3 technically, there would need
to be cross-industry agreement (and a corresponding update to the BRs)
that end-entity serverAuth certs need not contain the EKU extension.
Good luck with that!!
How much effort should we go to just to shave 21 bytes off the size of
each end-entity serverAuth cert?
0:d=0 hl=2 l= 19 cons: SEQUENCE
2:d=1 hl=2 l= 3 prim: OBJECT :X509v3 Extended Key Usage
7:d=1 hl=2 l= 12 prim: OCTET STRING
0000 - 30 0a 06 08 2b 06 01 05-05 07 03 01 0...+.......
--
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
