Sent from my iPhone
> On Nov 21, 2015, at 7:11 AM, tom p. <[email protected]> wrote: > > ----- Original Message ----- > From: "Kathleen Moriarty" <[email protected]> > To: "Salz, Rich" <[email protected]> > Cc: <[email protected]>; "Stephen Farrell" <[email protected]> > Sent: Friday, November 20, 2015 3:02 PM >>> On Fri, Nov 20, 2015 at 9:56 AM, Salz, Rich <[email protected]> wrote: >>> I would say that subjectAltName is ubiquitous, and CA's are > reluctant to stop using CN because it might break someone, somewhere. >> >> Pre-caffeine, I couldn't think of the attribute for holding CNAMEs, >> thank you. Path validation, I think requires both, but if a CNAME >> shows up in subjectAltName, and everything else checks out, you are >> good to go. I think (pretty sure) validation requires a check first >> for CN though, then it goes through the alternate names. > > RFC5539 says > "If a subjectAltName extension of type dNSName is present in the > certificate, it MUST be used as the source of the server's > identity." > or from draft-ietf-pce-pceps-06 > "The following precedence applies: for DNS name > validation, subjectAltName:DNS has precedence over CN; for > IP address validation, subjectAltName:iPAddr has precedence > over CN." > which chimes with my experience. > > subjectAltName 100: CN nil I've also seen product implementations vary widely in how they implement path validation or if they do at all. So there may be justified fear in this change from the reality of operational situations. Thanks, Kathleen > > Tom Petch > > > > RFC5280 >> hasn't changed or is there an update I missed that changes proper path >> validation? I would guess things would break without CN values >> included. Anyway, I think we are good on this one now. >> >> Thanks, >> Kathleen >> >>> >>> At least in my experience at work and on OpenSSL. >> >> >> >> -- >> >> Best regards, >> Kathleen >> >> _______________________________________________ >> Uta mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/uta > _______________________________________________ Uta mailing list [email protected] https://www.ietf.org/mailman/listinfo/uta
