Steve Wirth wrote:
>
> Hello,
>
> I ran into a particularity of OpenSSL's way to DER-encode certificate extensions
>that makes me curious
> and I would like to hear your opinion about it. According to the X.509
>specifications, unmarked tags
> (i.e. tags that are not explicitly stated as "IMPLICIT" or "EXPLICIT") in the
>certificate extensions
> module should be encoded as "IMPLICIT". OpenSSL however encodes some of these tags
>as "EXPLICIT" tags, as
> the following example shows:
> This short excerpt from the hexdump of a DER-coded OpenSSL certificate shows the
>code for the
> "authorityCertIssuer" field of the "AuthorityKeyIdentifier" extension:
>
> 3078 Tag & length for AuthorityKeyIdentifier (=SEQUENCE)
> A176 Tag & length for authorityCertIssuer [1]
> A474 Tag & length for directoryName [4] option of GeneralName,
>Type: RDNSequence
> 3072 Tag & length for RDNSequence (=SEQUENCE OF
>RelativeDistinguishedName)
> 310b30090603550406 Encoding of first RelativeDistinguishedName
>component (=SET OF)
> ....
> Since there is an "A4" tag for the directoryName[4] option of the GeneralName as
>well as an "30" tag to
> encode the underlying type (SEQUENCE OF), the "A4" tag is to be considered as an
>EXPLICIT (=outer) tag.
>
> However, default tagging mode in the X.509-certificate extensions module should be
>"IMPLICIT" (see the
> corresponding ASN.1-specifications, or am I wrong here?). I ran across other
>certificates and certificate
> handling software (including our own), where the DER-code excerpt for the same
>certificate looks like
> this:
> 3076
> A174
> A472
> 310b30090603550406
> ....
> which means that the explicit "A4" tag is transformed into an implicit tag by
>kicking the "30"-Sequence
> tag out.
>
> What I'd like to know is if OpenSSL's way of doing things here is
>standard-conforming and I just have to
> cope with two different representations of the same certificate (this can cause
>problems when verifying
> the certificate's digital signature with other software than OpenSSL) or if this can
>be considered a bug
> in OpenSSL's encoding functions.
>
The reason for this is due to DER encoding rules of ASN1 and various
specifications.
It all boils down to the CHOICE type. You determine which of the CHOICE
options is in use by the tag used. If however the CHOICE type itself
were IMPLICITly tagged then you'd lose the tag of the underlying type
and you've no way of finding out the CHOICE option. So if you tag a
CHOICE type it has to be EXPLICIT no matter what the default tagging of
the module is.
Now we come to GeneralName. Its definition from RFC2459 is:
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}
In this case its 'Name' we are interested in:
Name ::= CHOICE {
RDNSequence }
So the [4] tag has to be EXPLICIT because its a CHOICE type, even though
there's only one option.
Steve.
--
Dr Stephen N. Henson. http://www.drh-consultancy.demon.co.uk/
Personal Email: [EMAIL PROTECTED]
Senior crypto engineer, Celo Communications: http://www.celocom.com/
Core developer of the OpenSSL project: http://www.openssl.org/
Business Email: [EMAIL PROTECTED] PGP key: via homepage.
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
