On Fri, Apr 21, 2006 at 11:55:46AM -0700, Heikki Toivonen wrote:
> > On Fri, Apr 21, 2006 at 12:24:10PM -0400, Victor Duchovni wrote:
> >> in X.500 DNs as candidate DNS names is a transitional hack. When DNS
> >> names are present in the SubjectAlternativeName extension, these (with RFC
> >> blessing) are taken to represent *ALL* the valid DNS names of the subject.
> >
> > Here we go: RFC 2818 section 3.1:
> >
> > If a subjectAltName extension of type dNSName is present, that MUST
> > be used as the identity. Otherwise, the (most specific) Common Name
> > field in the Subject field of the certificate MUST be used. Although
> > the use of the Common Name is existing practice, it is deprecated and
> > Certification Authorities are encouraged to use the dNSName instead.
>
> I don't think the RFC wording is totally clear, although I lean on your
> interpretation a little bit.
>
> I have based my code on "Network Security with OpenSSL" book samples,
> which first check dNSName but happily continue to check commonName if no
> match was found in dNSName. Perhaps an errata to the book would be in
> order? See page 136 (June 2002 First Edition).
Sadly edge-case behaviour in X.509 peername verification is far from
uniform. The most common case: single US-ASCII CN and no alternative
names is handled reasonably consistently by all implementations. More
exotic certificates are likely to trigger implementation specific
behaviour:
- Failure to convert multi-byte encoded CNs to UTF-8 before
matching.
Many existing implementations just use the raw ASN.1 string data.
- Disagreement about which of multiple CN values in the subject
DN is applicable (first, last, most specific, what does "most
specific" mean anyway?).
Many implementations just use the first CN. Even though this
may not be strictly correct, Postfix is staying with "use first"
approach, because there are no reports of problems, and we don't
know whether changing this will break valid certs.
- Disagreement about the semantics of the DN in the presence of
subjectAltNames. Use both if present, or just the altNames?
There may be other ways to mess up. Both books and time-tested
implementations sometimes get the subtle details wrong. Still, I think the
(HTTPS) RFC is rather clear. The X.509 Internet profile RFCs are as far as
I can tell silent on the last issue.
The RFC recommends that one leave out the subject DN, and add a critical
extension with altNames. This does not really explain how matching
should work when the subject DN is present. HTTPS is not necessarily
normative for STARTTLS with SMTP, but in the absence of other guidance,
the HTTPS recommendations have been adopted in other application areas.
--
Viktor.
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users@openssl.org
Automated List Manager [EMAIL PROTECTED]
