[lamps] Re: [TLS] TLS Client Certificates; a survey

[Seo Suchan <[e-mail]>]

Wonder if allowing tls root ca to have dedicate clientauth eku only (no serverauth) subca is good stop gap. So clientauth cert can't backflow to browsers, but allowing clientauth certs to be chained to tls root cas

On 2026년 3월 26일 오후 1시 45분 16초 GMT+09:00, Nico Williams <[e-mail]> 작성함:
>On Thu, Mar 26, 2026 at 03:18:53PM +1100, Viktor Dukhovni wrote:
>> On Wed, Mar 25, 2026 at 09:42:11PM -0500, Nico Williams wrote:
>> > Even so I can find no EKUs for SMTP, LDAP, IMAP, XMPP, etc.  A bit
>> > surprising.  IMO a number of EKUs should be added.
>> 
>> I'm not conviced that'd be useful.  One would not be able to adopt these
>> until a decade or so goes by and systems with outdated TLS stacks that
>> support only "clientAuth" when validating TLS client certs are no longer
>> deployed.
>
>Except right now there are no WebPKI client certs being issued, but
>maybe after some time and with more specific EKUs the policies regarding
>those might get relaxed..  True, there are private PKI client certs, but
>still, now is the best opportunity to add new EKUs.  Also whether to
>require a more specific EKU would be a matter of configuration.
>
>> What would actually work is support for DANE-based client auth a la
>> DANCE.  The actual client credential is then just a raw public key, with
>> the name binding in DNS, and purpose encoded in an attrleaf label.  If
>> the client operator wants to reuse the same key for multipe purposes,
>> that's up to them, but it is just as simple to mint separate keys for
>> each application, to avoid big-bang multi-application key rollover
>> hassles and cross-protocol issues.
>
>That too.  What's up with DANCE?
>
>Nico
>-- 
>
>_______________________________________________
>Spasm mailing list -- [e-mail]
>To unsubscribe send an email to [e-mail]