[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: DNS and X.501 DistinguishedName
>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
There is an I-D or RFC by the LDAP working group specifying
using domain names as DNs.
John
>
>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
>> >
>