On Wed, May 15, 2002, CAMUS Sylvie FTRD/DTL/ISS wrote:
> Hi
>
> I Have read RFC 2459 about Subject Alternative Name. This "Subject
> Alternative Name" is defined in this way :
> id-ce-subjectAltName OBJECT IDENTIFIER ::= { id-ce 17 }
>
> SubjectAltName ::= GeneralNames
>
> GeneralNames ::= SEQUENCE SIZE (1..MAX) OF GeneralName
>
> GeneralName ::= CHOICE {
> otherName [0] OtherName,
> 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}
>
> OtherName ::= SEQUENCE {
> type-id OBJECT IDENTIFIER,
> value [0] EXPLICIT ANY DEFINED BY type-id }
>
> EDIPartyName ::= SEQUENCE {
> nameAssigner [0] DirectoryString OPTIONAL,
> partyName [1] DirectoryString }
>
>
> But, openssl supports (only) the following GeneralName :
> rfc822Name, dNSName, uniformResourceIdentifier, iPAddress, registeredID
>
> Why theses restrictions?
>
OpenSSL will parse and encode any of these.
It will however only display or generate the ones you mention.
This is for several reasons.
EDIPartyName, no real reason other than no one has wanted it.
OtherName is general purpose and is hard to handler generally,
though future versions of OpenSSL may handle simple string and
allow application to provide support for other forms based on
the type-id OID.
ORAddress: here be dragons!
Anyone unsure of the reason for that comment should have a look
at the definition of ORAddress...
Steve.
--
Dr. Stephen Henson [EMAIL PROTECTED]
OpenSSL Project http://www.openssl.org/~steve/
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
