Re: DNS and X.501 DistinguishedName

In your original note, you questioned the use of RFC 2247 naming scheme, as organizations might choose to use some other naming scheme in their directory.  Greg's suggestion allows you to accomodate any organization's naming scheme, with the data of interest to the devices/applications in question being located elsewhere than the DN (it may be there also, but devices/applications need not depend on being there). 

A device's certificate will contain its IP address or hostname in the subjectAltName extension, and may contain its DN in the subject field.  If these certificates are written to and retrieved from the directory, they will (likely) be in the entry whose DN is the subject DN in the certificate.

You're right that if you are using a directory and expecting to be able to store/retrieve certificates in/from it, you will need to generate DNs for your routers.  The subjectAltName extension allows you do so within the bounds of your existing naming scheme/preferences, while retaining in the certificate information most likely to be useful for network devices.  In general, extensions such as subjectAltName are a very useful place to put such data.

Note too that the subject and issuer fields in X.509 certificates can be empty.  The PKIX group has profiled the use of empty issuer and subject names to allow for those cases where directories are not involved.

pww

Peter Whittaker
Entrust Technologies
http://www.entrust.com



> -----Original Message-----
> From: Eric Bomarsi [mailto:[email protected]]
> Sent: Wednesday, June 10, 1998 2:16 PM
> To: Greg Carter
> Cc: [email protected]; [email protected]; [email protected]
> Subject: Re: DNS and X.501 DistinguishedName
> 
> 
> Thanks Greg,
> 
> I see. 
> 
> So I can generate an X.509 certificate request from
> the system's domain name or one of it's IP addresses,
> (and I should make that user selectable.)
> 
> However, the subjectAltName is specific to an X.509
> certificate request and so I believe I still need
> a way to enter an X.500 distinguished name into the
> system for LDAP services, unless there is a similar
> alternate name construct for LDAP?
> 
> /Eric Bomarsi
> 
> Greg Carter wrote:
> > 
> > Hi Eric,
> > 
> > For X.509 (PKCS10 requests or PKIX requests) you should look at the
> > subjectAltName extension.  It allows the certification 
> authority to list a
> > number of alternative names which the entity is associated 
> with.  This list
> > can include name types such as IP Address, DNS, and rfc822 
> names.  Therefore
> > the network device can have it's DNS and/or IP Address stored in the
> > certificate, while having an X.500 DN that fits the 
> organizations directory
> > structure.
> > 
> > >From X.509
> > 12.3.2.1        Subject alternative name field
> > This field contains one or more alternative names, using 
> any of a variety of
> > name forms, for the entity that is bound by the CA to the 
> certified public
> > key. This field is defined as follows:
> > subjectAltName EXTENSION ::= {
> >         SYNTAX  GeneralNames
> >         IDENTIFIED BY id-ce-subjectAltName }
> > 
> > GeneralNames ::= SEQUENCE SIZE (1..MAX) OF GeneralName
> > 
> > GeneralName ::= CHOICE {
> >         otherName                       [0]     INSTANCE OF 
> OTHER-NAME,
> >         rfc822Name                      [1]     IA5String,
> >         dNSName                 [2]     IA5String,
> >         x400Address             [3]     ORAddress,
> >         directoryName           [4]     Name,
> >         ediPartyName            [5]     EDIPartyName,
> >         uniformResourceIdentifier       [6]     IA5String,
> >         iPAddress                       [7]     OCTET STRING,
> >         registeredID                    [8]     OBJECT IDENTIFIER }
> > 
> > OTHER-NAME ::= TYPE-IDENTIFIER
> > 
> > EDIPartyName ::= SEQUENCE {
> >         nameAssigner            [0]     DirectoryString 
> {ub-name} OPTIONAL,
> >         partyName               [1]     DirectoryString {ub-name} }
> > The values in the alternatives of the GeneralName type are 
> names of various
> > forms as follows:
> >         -       otherName is a name of any form defined as 
> an instance of
> > the OTHER-NAME information object class;
> >         -       rfc822Name is an Internet electronic mail 
> address defined in
> > accordance with Internet RFC 822;
> >         -       dNSName is an Internet domain name defined 
> in accordance
> > with Internet RFC 1035;
> >         -       x400Address is an O/R address defined in 
> accordance with
> > ITU-T Rec. X.411 | ISO/IEC 10021-4;
> >         -       directoryName is a directory name defined 
> in accordance with
> > ITU-T Rec. X.501 | ISO/IEC 9594-2;
> >         -       ediPartyName is a name of a form agreed between
> > communicating Electronic Data Interchange partners; the nameAssigner
> > component identifies an authority that assigns unique 
> values of names in the
> > partyName component;
> >         -       uniformResourceIdentifier is a Uniform 
> Resource Identifier
> > for the World-Wide Web defined in accordance with Internet RFC 1630;
> >         -       iPAddress is an Internet Protocol address defined in
> > accordance with Internet RFC 791, represented as a binary string.
> >         -       registeredID is an identifier of any 
> registered object
> > assigned in accordance with ITU-T Rec. X.660 | ISO/IEC 9834-1.
> > For every name form used in the GeneralName type, there 
> shall be a name
> > registration system that ensures that any name used 
> unambiguously identifies
> > one entity to both certificate issuer and certificate users.
> > This extension may, at the option of the certificate 
> issuer, be either
> > critical or non-critical. An implementation which supports 
> this extension is
> > not required to be able to process all name forms. If the 
> extension is
> > flagged critical, at least one of the name forms that is 
> present shall be
> > recognized and processed, otherwise the certificate shall 
> be considered
> > invalid. Apart from the preceding restriction, a 
> certificate-using system is
> > permitted to ignore any name with an unrecognized or 
> unsupported name form.
> > It is recommended that, provided the subject field of the 
> certificate
> > contains a directory name that unambiguously identifies the 
> subject, this
> > field be flagged non-critical.
> > 
> > ----
> > Greg Carter, Entrust Technologies
> > [email protected]
> > 
> > > ----------
> > > From:         Eric Bomarsi[SMTP:[email protected]]
> > > Sent:         Tuesday, June 09, 1998 5:39 PM
> > > To:   [email protected]; [email protected]; [email protected]
> > > Subject:      DNS and X.501 DistinguishedName
> > >
> > > A network entity such as a router may require
> > > an X.501 DistinguishedName to utilize LDAP
> > > directory serices or generate PKCS certificate
> > > requests.
> > >
> > > It's possible that the network entity can
> > > use it's domain name to create an X.500
> > > Distinguished Name as specified in RFC2247.
> > > However, I'm concerned that this might be too
> > > inflexible since many organizations may
> > > implement an internal X.500 naming convention
> > > unrelated to their Internet domain naming.
> > >
> > > Has any MIB work been done to support
> > > distinguished name configuration?
> > >
> > > Thanks in advance,
> > > Eric Bomarsi
> > >
>