On Jul 10, 2023, at 4:44 PM, Michael Richardson <m...@sandelman.ca> wrote: > Alan DeKok <al...@deployingradius.com> wrote: >> * CAs should validate (somehow) any CSR they receive, to check that the >> contents are reasonable > > I guess this is the new section 3.2.8.
Yes. > There are quite a number of subtlies here. > First, the CSR is not really that complex :-) > > more importantly, there are not really any standard ways to communicate with > CAs about exceptions, about things that in the CSR that need to be added or > ignored. I don't think there's a possibility for such negotiation. I'm not even sure such negotiation would be a good idea. > The CAs do what they want, and the TEAP/EAP-peer is pretty much left with, > either fail the CSR after examining it, or just trust. Or use an integrated > CA or a proprietary API. Frankly, this is what I recommend: run your own CA. I agree. That doesn't solve the issue of what the EAP peer does, though. Mostly it could be "have a GUI / API to expose a few fields for configuring the CSR", and that's about it. The only thing this document can do is to suggest "here be dragons", and then move on to other subjects. It may take operational experience to fully understand what are the best options here. > Probably some reference to the 4.2.18. CSR-Attributes TLV section. > And I see that you have dealt with the Base64 goof (RFC8951), and the new > format. I would welcome your comments on the latest document, and to David > van Oheim's proposal that is coming up in some slides at the next meeting. > TEAP is likely a good greenfield for his simplified view. I'll take a look. Alan DeKok. _______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
