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

[Viktor Dukhovni <[e-mail]>]

On Wed, Mar 25, 2026 at 09:42:11PM -0500, Nico Williams wrote:

> One thought that occurs is that now would be a good time to define more
> EKUs.  For example, I don't see one for MTA in the EKU registry:
> 
> https://www.iana.org/assignments/smi-numbers/smi-numbers.xhtml#smi-numbers-1.3.6.1.5.5.7.3
> 
> Sadly that registry is for a specific OID arc and does not include
> extended key purpose OIDs from other arcs.  It might be useful to extend
> these registries to allow them to include OIDs from other arcs (though
> obviously IANA should only allocate from the one arc).
> 
> 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.

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.

More EKUs would not at this juncture be useful.

-- 
    Viktor.  🇺🇦 Слава Україні!