On Mon, 16 Jan 2023, at 13:54, Alan DeKok wrote: > And as a related note, if the PAC goes away, so does the Authority-ID > TLV, and related things like A-ID.
I was wondering what to do with A-ID[1] (and everything around PAC-Info) but starting to figure that as you can stuff anything you want into the opaque SessionTicket it really does not matter. > And just going through all of the possible corner cases, should we > also mention TLS-PSK? I don't think anyone has implemented support for > using PSK instead of client certificates, but it's possible. Perhaps > it's worth mentioning, and suggesting that TLS-PSK isn't a good idea? Not aware this has even been implemented by anyone even for RADIUS (D)TLS yet, right? Maybe time to hammer out a TLS-PSK implementation just to see what this looks and smells like? Previous RFC's have described that TLS-PSK is supported but someone here (or was it radext) pointed out that there is no mention of a PSK Identity which is needed not just the keying material. Maybe I am mis-reading it but I think TLS-PSK has effectively been given the kibosh by RFC9190 section 2.1.1: "Pre-Shared Key (PSK) authentication SHALL NOT be used except for resumption"? Cheers [1] https://github.com/emu-wg/rfc7170bis/issues/4#issuecomment-1370776188 _______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
