>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
1 at 6:34 PM
> *To: *Rich Salz
> *Cc: *"john.matts...@ericsson.com" ,
> "uta@ietf.org"
> *Subject: *Re: [Uta] High level comments on draft-ietf-uta-use-san
>
>
>
> Salz, Rich <mailto:40akamai@dmarc.ietf.org>> wrote:
>
>
FYI, I created https://github.com/richsalz/draft-ietf-uta-rfc6125bis/issues/21
for this.
From: Brian Smith
Date: Tuesday, June 1, 2021 at 6:34 PM
To: Rich Salz
Cc: "john.matts...@ericsson.com" , "uta@ietf.org"
Subject: Re: [Uta] High level comments on draft-ietf-uta
Salz, Rich 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
>
* 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 can
