Hi Jonathan, Maybe a further question to the draft you referenced (exported authenticators). Is there a way to request a distinct certificate in the AuthenticatorRequest? Can I ask for the certificates used in the initial handshake from both sides? I saw in the extension that in the ClientCertificateRequest that the server_name may be provided as extension but this may not be sufficient.
Best regards Steffen > -----Original Message----- > From: TLS <tls-boun...@ietf.org> On Behalf Of Fries, Steffen (T RDA CST) > Sent: Donnerstag, 11. März 2021 13:31 > > One option that I haven't seen mentioned in the thread is > https://tools.ietf.org/html/draft-ietf-tls-exported-authenticator-14. > Thank you for the pointer to the draft. > > > EAs let you send a certificate from either side of the connection at any > > point > after the handshake is complete. > > I'm not sure what the behaviour is if the certificate itself is expired at > > the time > the EA was sent, but valid at the time the connection was established, but I'm > sure that could be nailed down. > > Would something like the client (and equivalently the server) requesting an > > EA > every 24 hours and hard failing if it didn't get one meet your needs? > It may help here. From an integration standpoint it is important that the same > certificate would be used with EA as used in the handshake to ensure the one > used to authenticate in the first place would be verified. That may mean that > one would have to store the initially used certificate or at least the > fingerprint or > serial number and issuer to be able to request the right one in the > authenticator > request. > This would be handled on application layer if I understood it right. As the > goal > would be to have a trigger to verify the certificate against a (new) CRL, the > approach of having a timer or a trigger by the newly arrived CRL may be more > suitable. But I will have a closer look. > > Best regards > Steffen > > > Regards, > > > Jonathan > > On Tue, 9 Mar 2021 at 07:45, Viktor Dukhovni <mailto:ietf-d...@dukhovni.org> > wrote: > On Tue, Mar 09, 2021 at 07:28:26AM +0000, Fries, Steffen wrote: > > > > My take is such measures are much too complicated. Just keep the > connection > > > lifetime short, and make a new one from time to time. Also keep > > > certificate > > > lifetimes short. Where DNSSEC is an option on both ends, you can also use > > > DANE TLSA records instead of CRLs, just publish a > > > "1 1 1" (PKIX + DANE) or "3 1 1" (DANE only) record that validates the > > > server's > > > public key, and give it a short-enough TTL that it can be replaced > > > quickly. > > > Presto-magic, no need for OCSP, CRLs, ... > > > > While this may be a solution in general, it may not fit for power systems > > (like a > substation). > > The application of DNSSEC or DANE is not very common and may not be used. > Also due to > > Existing deployments, which do not feature these services (yet). > > I am not trying to suggest that DANE is currently a mainstream option > outside of SMTP (primarily in Northern and Central Europe for now, with > some signs of life in the USA, Canada and Brazil). The above was more > of an aside for the record. DANE may be a more realistic choice a few > years from now. DNSSEC adoption is starting to grow faster, and if this > continues and accelerates, DANE may become more common, time will tell. > > Early adopters can of course choose to use it now, but it is far from > mainstream today. > > -- > Viktor. > > _______________________________________________ > TLS mailing list > mailto:TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
