[cabfpub] Technically Constrained SubCAs

Dimitris Zacharopoulos jimmy at it.auth.gr
Thu May 12 08:28:41 UTC 2016

On 12/5/2016 11:04 πμ, Dimitris Zacharopoulos wrote:
> On 12/5/2016 10:59 πμ, Rob Stradling wrote:
>> On 12/05/16 05:38, Dimitris Zacharopoulos wrote:
>>> 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.
>> Let's look at an actual example:
>> https://crt.sh/?id=12967730
>> Was it your intent for this CA to be capable of issuing
>> id-kp-codeSigning end-entity certificates that Windows would trust?
>> Assuming it wasn't your intent...
>> What constraint prevents this CA from issuing id-kp-codeSigning
>> end-entity certificates that Windows would trust?
> This intermediate CA is technically constrained for SSL certificates,
> not code Signing. Section 7.1.5 tries to technically constrain
> intermediate CAs in issuing SSL certificates.
> Dimitris.
> _______________________________________________
> Public mailing list
> Public at cabforum.org
> https://cabforum.org/mailman/listinfo/public

A correction to my previous e-mail. This particular intermediate CA you 
used as an example SHOULD NOT be considered technically constrained per
my interpretation because it lacks the iPAddress scope in the Permitted
Subtree of the Name Constraints extension. However, this intermediate
https://crt.sh/?id=13371081, should be considered technically
constrained for SSL certificates, even if it lacks the EKU extension.


More information about the Public mailing list