On Jul 10, 2023, at 8:05 PM, Michael Richardson <[email protected]> wrote: > It would be good to have an operational document that says what operators > actually need what. I think that it's mostly a question of if you give > operators options, they will just do weird things for not well understood > reasons.
I agree. > I think that the client certificate needs a SubjectAltName, probably an > rfc822Name, but MAYBE another GeneralName. > And, maybe, a DN. There is no CSRattributes that can specify the DN today. Sure. I suspect that in most cases, the only fields that the supplicant needs to fill out are the user name, email, etc. Everything else is either irrelevant, or known. i.e. the common case is a user authenticating to an organization. They both know each other. So fields like "telephone number" or "mailing address" are likely irrelevant. The organization has other ways to track such information for the user. That information doesn't need to go into a certificate. The user doesn't need to put that information into the CSR for similar reasons. So it's likely best to recommend that the CSR contain as little information as possible. That way it's easier to verify, and less likely to be wrong. > CSRattributes gives lots of power, but I don't think the end user needs any > input other than inputting their email address. (Assuming, it can't be > gotten from elsewhere on the system. I'm thinking @me.com, @live.com, > ubuntu-1 account) I agree. > It's not written up, having been discussed in detail only last Wednesday. > I'll get slides posted to LAMPS in the next week. > But, the short of it: Here is an CSR, please fill in the blanks. That seems like the best approach. Alan DeKok. _______________________________________________ Emu mailing list [email protected] https://www.ietf.org/mailman/listinfo/emu
