On Fri, Apr 21, 2006 at 02:11:39PM -0500, Vijay K. Gurbani wrote:
> Victor Duchovni wrote:
> >The usual interpretation seems to be not an alternative in the sense
> >of "one more of the same", but rather "one more and possibly better
> >*representation* of the same".
> >
> >The subject name in the certificate is an X.500 DN. What Internet
> >applications that want to authenticate a connection to a given host are
> >trying to verify is a DNS name. The convention for overloading CommonName
> >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.
> >
> >I don't have an RFC reference for such an interpretation. Anyone have
> >a handy reference?
>
> RFC 3280, Section 4.2.1.7.
I read this, but it was far less clear than the HTTPS language:
4.2.1.7 Subject Alternative Name
The subject alternative names extension allows additional identities
to be bound to the subject of the certificate. Defined options
include an Internet electronic mail address, a DNS name, an IP
address, and a uniform resource identifier (URI). Other options
exist, including completely local definitions. Multiple name forms,
and multiple instances of each name form, MAY be included. Whenever
such identities are to be bound into a certificate, the subject
alternative name (or issuer alternative name) extension MUST be used;
however, a DNS name MAY be represented in the subject field using the
domainComponent attribute as described in section 4.1.2.4.
Because the subject alternative name is considered to be definitively
bound to the public key, all parts of the subject alternative name
MUST be verified by the CA.
Further, if the only subject identity included in the certificate is
an alternative name form (e.g., an electronic mail address), then the
subject distinguished name MUST be empty (an empty sequence), and the
subjectAltName extension MUST be present. If the subject field
contains an empty sequence, the subjectAltName extension MUST be
marked critical.
The text:
Whenever such identities are to be bound into a certificate, the subject
alternative name (or issuer alternative name) extension MUST be used;
however, a DNS name MAY be represented in the subject field using the
domainComponent attribute as described in section 4.1.2.4.
is rather muddy... Used by whom? For what? In addition? Instead? So
perhaps the HTTPS RFC elaborates the intent of a rather poorly worded
base RFC.
--
Viktor.
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users@openssl.org
Automated List Manager [EMAIL PROTECTED]
