On Sat, Nov 20, 2021 at 6:58 AM John Mattsson <john.mattsson= [email protected]> wrote:
> - In some applications using mutually authenticated TLS, e.g., between > nodes in 5G core networks or in mesh networks there is basically no > difference between the client and the server. It would be very good if the > document states that for such use cases the recommendations apply also for > the client certificate. > How do these examples construct their set of reference identifiers? And are they using the same identifiers, or, as is common in these cases, bespoke identifiers unique / scoped to a particular community? For example, the classic "extract the name from the certificate" used in such mutual/mesh networks is something the spec explicitly disclaims in Section 6.1.1, so it's difficult to see how to unify such an approach safely? > - I think it would be good if the document made the use of IPaddress for > Naming of Application Services NOT RECOMMENDED. They should probably only > be used to reach DNS resolvers. > There's been past discussion within ACME on this point. There's no reason to believe that IP Addresses are any less useful or less secure than DNS names from a client validation point: they both have central registries (RIRs/LIRs or the IANA/ICANN TLDs, respectively), and are generally recognized legally as a form of tangible property, albeit with potential time-bounded use. The concerns around IP address certificates primarily comes down to the validation practices, and whether or not there are sufficient, and reliable, metadata channels to convey the authorization of a certificate being issued (e.g. ACME's DNS record format making an explicit protocol agreement for authorizing certificates), but from a client/UTA perspective, that seems unrelated. For that matter, for the better part of the HTTPS/TLS specifications lifetime, DNS validation as practiced by most non-internally-operated CAs was just as ill-defined, and that didn't seem to result in a NOT RECOMMENDED for DNS names. I realize I'm making assumptions about your objections in the absence of details, and so that's largely based on past IETF conversations about the merits of IP vs DNS names. However, if the above wasn't your concern, could you elaborate more on the NOT RECOMMENDED, and how that applies to concerns regarding client validation behaviours versus CA issuance practices?
_______________________________________________ Uta mailing list [email protected] https://www.ietf.org/mailman/listinfo/uta
