[Servercert-wg] Critical Name Constraints (Was: Re:Question on BR 3.2.2.6)

Tadahiko Ito tadahi-ito at secom.co.jp
Wed Mar 4 01:35:16 MST 2020


Thanks Ryan and Paul

>> Any system that is ignoring nameConstraints has a CRITICAL security vulnerability.

I am sorry that my post might be miss-reading.

My concern is (something like), “do validator of client-auth cert (like VPN server) need to parse and check every entry of nameConstrain extension, 
even if client certificate only use some internal ID for that name?” 
If it were Yes, I feel like we may need to think bit more carefully.
 # I believe that is bit differenct from "ignoring nameConstraints". 
 # It seems light-weight process for me, and may not affect much. but I cannot sure so far.
 # I am asking my acquaintance about influence of nameConstraints on some server implementation, but I am not sure if I can get answer. If I got information, I will share that.

If they had already checking them and there will not be influence on performance, or change does not affect much of performance, it was needless anxiety. 
 # as you said, we did not require critical for starting point.

It is related with difference on definition of “critical” on RFCs.
(“or a critical extension that contains information that it cannot process” part)

RFC3280 says
“A certificate using system MUST reject the certificate if it encounters a critical extension it does not recognize”

RFC5280 says
"A certificate-using system MUST reject the certificate if it encounters a critical extension it does not recognize or a critical extension that contains information that it cannot process. "

As Dimitris said, 
>> On the other hand, Certificate Consumers that account for the majority of the webPKI (those participating in the SCWG), 
>> already honor and use this extension, thus the majority of the webPKI Relying Parties are currently protected. 
>> What benefit would the WebPKI have if this extension was forced to be "critical", other than just removing an "exception" to an RFC?
do we really have CRITICAL gain on security of the webPKI with that change?

I might be caring too much about “critical” handling issue, but I always feel nervous when hearing "critical", so excuse me.  
 # If there is not such naive implementation on server-side, we can forget about that.
Modern PKI implementations may just work fine, but I am not quite sure by watching betterTLS project.
We may need not care too much and just move forward to have betterPKI.

Regards Tadahiko




More information about the Servercert-wg mailing list