David Adrian <[email protected]> writes:

>History has taught us that commingling PKI use cases causes more harm than
>good. It is a consistent security problem when PKI hierarchies intended for
>public web sites get entangled in non-web use cases. As an example, such
>behavior slowed the deprecation of SHA-1 in 2018 because payment card
>terminal implementations and their corresponding root stores could not be
>updated.

So what actual problem was disallowing clientAuth intended to solve?  I can't
imagine any situation where doing this is a good thing, but as others have
pointed out there are numerous situations where it's a bad thing.

Also, for users of said certs, is the eKU in them critical or not?  Its usage
has changed over time from the original "non-critical = advisory only, used to
select the right certificate" to the more recent "both non-critical and
critical are to be treated as per the critical text".  I'm not sure if this
newer interpretation was a unilateral decision on behalf of the RFC authors (it
looks like the non-critical text portion just got dropped from the doc) but
when PKIX debated it there was, as was typical for PKIX, a 50:50 split as to
whether it was strictly enforced or advisory only.

Peter.
_______________________________________________
TLS mailing list -- [email protected]
To unsubscribe send an email to [email protected]

Reply via email to