000024178 - Understanding the proper BER encoding of the AuthorityKeyIdentifier extension when it contains a directoryName in the authorityCertIssuer field

Document created by RSA Customer Support Employee on Jun 14, 2016Last modified by RSA Customer Support Employee on Apr 22, 2017
Version 2Show Document
  • View in full screen mode

Article Content

Article Number000024178
Applies ToRSA BSAFE Cert-C
Going into more detail about why this is true, here is the definition of the AuthorityKeyIdentifier:

  AuthorityKeyIdentifier ::= SEQUENCE {
     keyIdentifier             [0] KeyIdentifier           OPTIONAL,
     authorityCertIssuer       [1] GeneralNames            OPTIONAL,
     authorityCertSerialNumber [2] CertificateSerialNumber OPTIONAL
  }

Note that this definition in RFC 2459 is contained in the implicitly tagged ASN.1 module (section A.2).  The encoding above indicates that the first element in the sequence is the authorityCertIssuer because the first element in the sequence is tagged as a context-specific constructed tag with value [1] -- the 0xA1 byte.  Note that the 0xA1 tag implicitly stands for the SEQUENCE that begins the GeneralNames.  The GeneralNames definition, which contains GeneralNames is:

 GeneralNames ::= SEQUENCE SIZE (1..MAX) OF GeneralName

 GeneralName ::= CHOICE {
   otherName                 [0] AnotherName,
   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
 }

The 0xA4 byte indicates that the first element in the GeneralNames is a directoryName, which is a Name.  The definition of Name is:

 Name ::= CHOICE {
   RDNSequence
 }
Had the directory name simply been an RDNSequence instead of a Name CHOICE, the original encoding would have been correct.  However, section 28.8 of the X.680 standard covering ASN.1 definitions states:

"The 'IMPLICIT' alternative shall not be used if the type defined by 'Type' is a choice type or an open type or a 'DummyReference'"

To get an understanding for why this is the case, suppose that we have some other type:

 NonsenseName ::= OCTET STRING

and that it was a valid Name CHOICE (we do not need context-specific tags because the RDNSequence and NonsenseName have different tags):

 Name ::= CHOICE {
   RDNSequence,
   NonsenseName
 }

This makes it clear why the CHOICE cannot be an implicitly tagged value.  If we saw:

  A1 71 --authorityCertIssuer, an IMPLICIT GeneralNames SEQUENCE
     A4 6F --directoryName
        31 0B ...

We now have no idea how to interpret the 0x31, 0x0B, ..., bytes which follow.  Are they contents of the RDNSequence SEQUENCE, or contents of the NonsenseName OCTET STRING?  There is no way to determine what type the [4] tag implicitly tags.  Therefore, the [4] tag must be followed by the explicit tag for either the RDNSequence or NonsenseName.
IssueUnderstanding the proper BER encoding of the AuthorityKeyIdentifier extension when it contains a directoryName in the authorityCertIssuer field
E_CERT_EXTENSIONS (0x72a) error code returned by C_SetCertBER
Here is an example of a problematic encoding of an authority key ID extension value in a certificate:

30 79 --AuthorityKeyIdentifier SEQUENCE
  A1 71 --authorityCertIssuer, an IMPLICIT GeneralNames SEQUENCE
     A4 6F --directoryName, an IMPLICIT Name SEQUENCE (this is wrong!)
        31 0B --RDN SET OF
           30 09 ... --AttributeTypeAndValue SEQUENCE...
CauseThe reason that this rule is specified as a restriction on ASN.1 and is not explicitly called out in the BER specification (X.690) is because it is an issue regardless of how you represent the ASN.1 data.  Remeber what happened in our hypothetical example if the Name CHOICE didn't only consist of the RDNSequence.  That is an ASN.1 issue, not a BER or DER issue.
ResolutionIn short, since the Name type is a CHOICE type, it cannot be implicitly tagged.
If a particular CA is producing certificates with the incorrect encoding, report a bug to the appropriate certificate issuer.
So the SEQUENCE in the RDNSequence (one of the Name choices) must be explicitly tagged.  The actual encoding should be like the following:

30 81 81 --AuthorityKeyIdentifier SEQUENCE
  A1 73 --authorityCertIssuer, an IMPLICIT GeneralNames SEQUENCE
     A4 71 --directoryName, a Name CHOICE
        30 6F --RDNSequence, one of the choices for Name
           31 0B --RDN SET OF
              30 09 ... --AttributeTypeAndValue SEQUENCE...


Thus, the actual encoding should be the following:

30 81 81 --AuthorityKeyIdentifier SEQUENCE
  A1 73 --authorityCertIssuer, an IMPLICIT GeneralNames SEQUENCE
     A4 71 --directoryName, a Name CHOICE
        30 6F --RDNSequence, one of the choices for Name
           31 0B --RDN SET OF
              30 09 ... --AttributeTypeAndValue SEQUENCE...
Legacy Article IDa7208

Attachments

    Outcomes