On Tue, May 20, 2025 at 03:46:10PM -0400, Phillip Hallam-Baker wrote:
> > > Browser does TLS client side auth presenting the cert it was issued.
> >
> > With TLSA 3 1 X records, this could be just a raw public key.
> >
>
> That isn't going to work because users have multiple devices. It isn't
> worth building out anything for the single device use case.
Nothing about a raw public key makes it "single device". The
"certificate" content (name binding) is in the TLSA record, and
so everything else in the certificate is often redundant.
> Each device should have its own key. Much easier to make that work
> correctly...
Of course, and its own "3 1 1" record (separate DNS name, separate
"3 1 1" payload binding the key for that device).
> I did also consider the LetsEncrypt/ACME route but what does that buy
> us? The relying party in this case has just as much opportunity to
> perform an unspoofed DNS lookup as a CA. Not sure what WebPKI is
> buying us.
Not much at all for client certificates.
> > I may be able to do add the relevant support in OpenSSL, DANE for server
> > certs is already implemented, the main obstacle is that there isn't a
> > ubiquitous API for authenticating client-provided DNSSEC chains. So
> > validation of the client chain or fetching it on demand would be up to
> > the application via its preferred DNS library, and not directly
> > performed by OpenSSL. Once the server provides the relevant TLSA
> > records to the library, the certificate verification can proceed using
> > existing DANE support which is essentially direction agnostic.
> >
>
> Perhaps a side meeting in MADRID, maybe some of the browser folk could
> provide input...
I'm yet to make travel plans, but may well attend. If so, sure let's
meet. Indeed we last met in person at a Berlin IETF circa 2014, where
this topic may even have come up. Shumon was there too.
> There are multiple issues here.
>
> 1) Client to server signalling.
> 2) Server to client signalling.
> 3) Issue of the certificate signing certificates.
> 4) Issue of the end entity certificates.
> 5) Signalling enrollment for TCSA
Yes, all of the above. My SMTP server supports and sees some
connections with clients that use the DANE TLSA "3 1 [012]"
records to validate the negotiated raw public key.
--
Viktor.
_______________________________________________
dane mailing list -- [email protected]
To unsubscribe send an email to [email protected]