Eliot Lear <l...@cisco.com> wrote: > On 21 Apr 2021, at 20:25, Brian Smith <br...@briansmith.org> wrote: > > otherName [0] OtherName, > rfc822Name [1] IA5String, > dNSName [2] IA5String, > x400Address [3] ORAddress, > directoryName [4] Name, > ediPartyName [5] EDIPartyName, > uniformResourceIdentifier [6] IA5String, > iPAddress [7] OCTET STRING, > registeredID > > The principle here is long-lived names. I can’t imagine [2] and [7] being > at issue. [1] and [4] are definitely in use in long-lived environment. I > don’t know about the rest. >
OK, [2] is dNSName, and [7] is iPAddress. Those are the primary two types of identifiers that I'm targeting: I want the spec to say that certificate verifiers must not look for IP addresses or DNS names in the Common Name sub-field of the Subject field of a certificate. Regarding [4] directoryName, I don't think anybody is encoding an entire directoryName into the Common Name field of the subject field, so that's a non-issue. Regarding [1] rfc822Name, are you saying that you are worried about certificates with a subject like : CN="f...@example.com" without an accompanying subjectAltName rfc822Name="f...@example.com"? If so, is your concern about using these certificates in email applications? I would love for us to get to the point where we say email applications also must use only email addresses (rfc822Names) in the subjectAltName extension and not look in the CN of the subject field. For non-email applications, aren't they just using the subject field as a directoryName that's somewhat incomplete? Regardless, non-email address uses of CN=f...@example.com would be (or could be made) out of scope of the revised spec. Cheers, Brian -- https://briansmith.org/
_______________________________________________ Uta mailing list Uta@ietf.org https://www.ietf.org/mailman/listinfo/uta
