----- 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
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
