[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
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
> greg.carter@entrust.com
>
> > ----------
> > From: Eric Bomarsi[SMTP:ebomarsi@xedia.com]
> > Sent: Tuesday, June 09, 1998 5:39 PM
> > To: ietf-lsd@listserv.umu.se; ipsec@tis.com; spki@c2.net
> > 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
> >
References: