Thanks, Rich. My recommendation is to state the architectural principle, much as you already you, but then to split up the recommendations, perhaps along the following lines:
Applications that make use of domain names and maybe ip addresses in certificates Others I *think* that is the right split (Victor got me thinking along these lines). For the former, we don’t have to be too polite about those not using SANs: it’s well past time. For the latter, I would couch the language just a bit, because there are likely to be non-IETF use cases tracking your work. So something like: those producing certificates that do not contain domain names MUST use a SAN. Those validating certificates not using domain names MAY reject certificates that do not contain a SAN, based on intended use case, length of certificates in play, and other specific application knowledge. That probably needs a WHOLE lot of word smithing, but it gives fair warning to the industry that unstructured subjects are naughty. I would still liaise this stuff to the IEEE. Eliot > On 15 Mar 2021, at 16:14, Salz, Rich <[email protected] > <mailto:[email protected]>> wrote: > >> I’m quite certain this is NOT what Rich had in mind when he was writing >> the document, and thus my suggestions. > > There are more things in heaven and earth, Horatio, than are covered by your > draft :) > > Happy to add some wording if anyone has suggestions. >
signature.asc
Description: Message signed with OpenPGP
_______________________________________________ Uta mailing list [email protected] https://www.ietf.org/mailman/listinfo/uta
