I don't believe so, but that would seem like a configuration issue. I guess if you really wanted you could define an extension that goes in the Certificate Request message (which the AR is based on), assuming there isn't one already, that requests a specific serial number. Although that of course makes the system completely brittle if that certificate gets revoked, expires, or even just becomes unavailable because of disk failure. It would be great to see all the potential use cases broken down so the best solutions can be considered.
Regards, Jonathan On Fri, 12 Mar 2021 at 11:00, Fries, Steffen <steffen.fr...@siemens.com> wrote: > 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
