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

[Ryan Sleevi]

On Wed, Mar 4, 2020 at 3:35 AM Tadahiko Ito <tadahi-ito at secom.co.jp> wrote:

> 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?”
>

RFC 5280 says yes. It must be capable of understanding the semantics
expected, if the extension is marked critical. It's the signal "you must
understand what I'm trying to convey".


> 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.
>

I think you're too worried about critical, yes.

As currently specified in the BRs, we leave every client implementation at
risk of security issues, because we're saying "We're going to treat this
(via policy) like it's constrained, but who knows if you'll actually
support that". If we're going to carve out exceptions, such as audits, for
such CAs, then we need to make sure that we're not introducing risk to
clients.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/servercert-wg/attachments/20200304/51e9fdba/attachment.html>