Re: DNS and X.501 DistinguishedName

Peter,

You may want to turn whatever generates RTF off.

Cheers,               ....Erik.

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