[cabfcert_policy] Fwd: Re: [cabfpub] Technically Constrained SubCAs

[Dimitris Zacharopoulos]

Hello everyone,

Following up on the Technically Constrained SubCAs discussion in the
public list, I am thinking on proposing a ballot to change section 7.1.5
of the BR. I believe that for an intermediate CA to be considered
"technically constrained" _for SSL certificates_, it should contain
either a nameConstraints extension, with the three limits (dNSName,
iPAddress and DirectoryName) already described in 7.1.5, OR it should
contain an EKU that _does not_ include "kp-server-auth" or "anyEKU".

In the first case, the dNSName and iPAddress are the blocking factor. In
the second case, the EKU is the blocking factor.

I am posting this to the policy WG because it is a policy change and I
don't know if it should be discussed in this WG first or not. If there
are no objections at the technical level, I will be looking for two
endorsers and prepare a ballot.

Please, let me know your thoughts about this interpretation.


Best regards,
Dimitris.

-------- Forwarded Message --------
Subject: 	Re: [cabfpub] Technically Constrained SubCAs
Date: 	Thu, 12 May 2016 07:38:50 +0300
From: 	Dimitris Zacharopoulos <jimmy at it.auth.gr>
To: 	Rob Stradling <rob.stradling at comodo.com>
CC: 	public at cabforum.org



On 11/5/2016 4:30 μμ, Rob Stradling wrote:
>>
>> So, let's assume that there is an Intermediate CA with EKU
>> id=kp-serverAuth + NameConstraints extension (all non-critical), and an
>> Intermediate CA with no EKU but with NameConstraints extension. Is there
>> a difference regarding the technical constraints? Browsers and
>> implementations that follow RFC5280 will treat them both exactly the
>> same way.
>
> Unfortunately, the "Browsers and implementations that follow RFC5280"
> don't have 100% market share, hence why the BRs permit non-critical
> Name Constraints.
>
> Also, most browsers don't "follow RFC5280" when it comes to processing
> a CA certificate that contains the EKU extension!
>
>> Implementations that completely ignore the Name Constraints
>> extension will also treat them exactly the same way.
>
> That's not true.  Implementations that process Name Constraints will
> reject cert chains that don't fit within those constraints, whereas
> implementations that ignore Name Constraints won't do that. 

Perhaps I did not describe it clearly enough. Implementations that do
not handle name constraints, will treat a subCA with or without the
"kp-server-auth" EKU, in exactly the same way and probably allow the
verification of the SSL certificate. This is not what we discuss here
though. If an implementation ignores the nameConstraints, there is
nothing the CA/B Forum or the BRs can do about it.

I believe the nameConstraints extension alone, with the three limits
described in 7.1.5 of the BRs is sufficient for an intermediate CA to be
considered "technically constrained" for SSL certificates. An exception
to this rule would be to _include_ an EKU that _does not_ contain
"kp-server-auth" or "anyEKU". In the latter case, you don't need a
nameConstraints extension for dNSName, iPAddress and DirectoryName
because the EKU is the blocking factor.


Best regards,

Dimitris.





-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://cabforum.org/pipermail/policyreview/attachments/20160512/360ebbd0/attachment.html 
-------------- next part --------------
_______________________________________________
Public mailing list
Public at cabforum.org
https://cabforum.org/mailman/listinfo/public