[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: DNS and X.501 DistinguishedName

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
>
Follow-Ups: