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

Tue Mar 3 06:09:08 MST 2020

I appreciate the concern, but I disagree that it's well-founded.

Any system that is ignoring nameConstraints has a CRITICAL security
vulnerability. The assumptions inherent here are that we allow looser
supervision and auditing in exchange for the technical assurance of
nameConstraints.

Put differently: If something breaks, *good*, that's the entire point of
why RFC 5280 requires nameConstraints; so that insecure systems fail closed.

If SSL VPN software still has trouble, and finds that critical
nameConstraints are some unreasonable burden, they can easily transition to
issuance off a nameConstrained root (e.g. issued directly by an audited CA)
or transition PKIs.

The only reasonable alternative is to eliminate the notion of "Technically
Constrained Sub CA", and require that the entire hierarchy undergo the same
audit and supervision regime. Given how few certificates exist with
nameConstraints, this is equally achievable, but as I suspect CAs would
more vociferiously raise concerns, I suspect the more pragmatic approach is
needed.

Compatibility with insecure devices and use cases is not a feature we seek
to support. The same is true, for example, of SHA-1, or internal server
names. We know they will break some cases, but that's a feature, not a bug.

My only regret is that we permitted non-critical nameConstraints to begin
with. It would have been far safer for end-users to allow CAs zero
exceptions to the audits, rather than allowing clients to be potentially
exposed to risk, including, at the time, Apple clients (since fixed).

On Tue, Mar 3, 2020 at 6:21 AM Tadahiko Ito via Servercert-wg <
servercert-wg at cabforum.org> wrote:

> Sorry for multi-posting.
>
> I am not sure about implementation of (for example)SSL VPN, However as
> 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. ",
> they might check critical extension.
>
> we might be able to ask a few clients to test.
> However, there are so many implementation of SSL VPN, and we won't able to
> cover enough implementation.
>
> If they were free, academic people might do, but they are not free for
> many cases.
>
> It should be better to ask SSL VPN venders, whether if they support or
> not.
> However, since it is so many SSL VPN implementation, it should be very
> time-consuming for us, and there seems not much incentive for those vender
> also.
>
> If it will be critical, it should be done after some survey of
> implementations (something like betterTLS for server).
>  <https://nameconstraints.bettertls.com/>
>
> Regards Tadahiko
>
> -----Original Message-----
> From: Tadahiko Ito
> Sent: Tuesday, March 3, 2020 6:21 PM
> To: 'Dimitris Zacharopoulos (HARICA)'; servercert-wg at cabforum.org
> Cc: 外部送信
> Subject: RE: [Servercert-wg] Critical Name Constraints (Was: Re:Question
> on BR 3.2.2.6)
>
> Hi Demitris
>
> I do not have experience, but I believe, validator of Certificates would
> check every critical value
> (then may ignore nameConstraints extension, since that value do not
> affected validation).
> However, some validator may not able to process name constraints correctly
> (since that logic is complicated).
>
> Regards Tadahiko Ito
>
> -----Original Message-----
> From: Dimitris Zacharopoulos (HARICA) [mailto:dzacharo at harica.gr]
> Sent: Tuesday, March 3, 2020 6:13 PM
> To: Tadahiko Ito; servercert-wg at cabforum.org
> Subject: Re: [Servercert-wg] Critical Name Constraints (Was: Re:Question
> on BR 3.2.2.6)
>
> On 3/3/2020 10:46 π.μ., Tadahiko Ito wrote:
> > I was not aware of that thread, but I agree Dimitris that we need to
> treat that issue carefully.
> >
> > First of all, I personally know existence of IoT devices which access
> webserver.
> >   # they are not our customer nor my acquaintance. I am not sure such
> usage exist for our customer or not.
> > I am not sure if those devices can handle that" critical" (or even
> firmware update), because of constraint resource.
> > I feel such practices should not done with webPKI, but they just exist,
> so I believe we need to care influences.
> >
> > In the other hand, many intermediate cert has EKU of client-auth and
> server-auth.
> > don't we need to check certificate consumer of client-auth?
> >
> > Regards Tadahiko Ito
>
> Hello Tadahiko,
>
> Did you have any experience that clientAuth Certificates are affected by
> dNSName values in the nameConstraints extension? I may be
> misunderstanding your last statement.
>
>
> Dimitris.
>
> >
> > -----------------------------------------------------------------------
> >
> > Date: Tue, 3 Mar 2020 09:19:38 +0200
> > From: "Dimitris Zacharopoulos (HARICA)" <dzacharo at harica.gr>
> > To: Ryan Sleevi <sleevi at google.com>
> > Cc: CA/B Forum Server Certificate WG Public Discussion List
> >       <servercert-wg at cabforum.org>
> > Subject: Re: [Servercert-wg] Critical Name Constraints (Was: Re:
> >       Question on BR 3.2.2.6)
> > Message-ID: <af175960-5fdc-f107-8e04-e9ad650e8b17 at harica.gr>
> > Content-Type: text/plain; charset="utf-8"; Format="flowed"
> >
> >
> >
> > On 2020-02-29 12:30 ?.?., Ryan Sleevi wrote:
> >> I see. That was answered on the original thread. The short answer: No,
> >> it does not, except where it's explicitly designed to break (i.e. why
> >> you make them critical).
> >>
> >> If you have data to believe otherwise, different from that shared on
> >> the thread from last year, that would be great to share to be mindful
> of.
> > I'd first like to remind people about the previous thread
> > (https://cabforum.org/pipermail/servercert-wg/2019-October/001196.html).
> > It was a rather short thread, comparing to other much longer discussions
> > :-) Most Members have been silent on this topic and I'm still trying to
> > figure out which of the following is true:
> >
> >   1. CAs are just not using name constraints so they don't care about the
> >      outcome
> >   2. CAs are using name constraints and are ok with forcing the extension
> >      to be "critical".
> >
> > Having been involved with name constraints for years, I find it very
> > difficult to see the latter being true.
> >
> > HARICA uses name constraints for several subCAs. Over the years we have
> > seen implementations in opensource tools/applications/services that
> > would break if the extension was critical. We still see legacy systems
> > and unsupported software using TLS Certificates. Some of our Subscribers
> > complain that certain Relying Parties with old and unsupported devices
> > can't browse sites. These are all cases that would have availability
> > issues with TLS.
> >
> > 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?
> >
> >
> > Dimitris.
> >
> >
>
> _______________________________________________
> Servercert-wg mailing list
> Servercert-wg at cabforum.org
> http://cabforum.org/mailman/listinfo/servercert-wg
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/servercert-wg/attachments/20200303/b9f4b10e/attachment-0001.html>