On 9/10/21 11:48 AM, Salz, Rich wrote: > FYI, I created > https://github.com/richsalz/draft-ietf-uta-rfc6125bis/issues/21 > <https://github.com/richsalz/draft-ietf-uta-rfc6125bis/issues/21> for this. > > > > *From: *Brian Smith <br...@briansmith.org> > *Date: *Tuesday, June 1, 2021 at 6:34 PM > *To: *Rich Salz <rs...@akamai.com> > *Cc: *"john.matts...@ericsson.com" <john.matts...@ericsson.com>, > "uta@ietf.org" <uta@ietf.org> > *Subject: *Re: [Uta] High level comments on draft-ietf-uta-use-san > > > > Salz, Rich <rsalz=40akamai....@dmarc.ietf.org > <mailto:40akamai....@dmarc.ietf.org>> wrote: > > > > * Some sections mention "server" while other sections does not > state anything, therefor applying to both client and server. I > think the draft needs to be very clear on this point. > > > > * I saw that there was a discussion on client certs and that some > client certs are built with CN and cannot be easily changed. > Other uses of RFC 6125 like the Service Based Architecture in > 3GPP 5G makes little or no difference between server and client > when it comes to certificates. > > > > Thanks for reading it! The current plan is to produce a stand-alone > 6125bis, rather than the current diff/patch document. I’ll try to > make sure these issues are cleared up. > > > > I think we should avoid mentioning roles like "client" or "server" > except non-normatively to emphasize that the spec would apply to both > roles. What matters is that the entity's identity is a DNS name.
RFC 6125 was written with TLS in mind (it's even mentioned in the title), and in any given TLS interaction one entity is the client and the other is the server. The use of these terms in RFC 6125 had nothing to do with what are usually called "client certs" (e.g., a certificate associated with a particular user's web browser when TLS is used in the context of HTTP). That said, I agree that we can make things clearer. Peter _______________________________________________ Uta mailing list Uta@ietf.org https://www.ietf.org/mailman/listinfo/uta
