As people have pointed out, this is now DANCE. On Tue, May 20, 2025 at 11:05 PM Viktor Dukhovni <[email protected]> wrote:
> 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] >
_______________________________________________ dane mailing list -- [email protected] To unsubscribe send an email to [email protected]
