Encoding of a CHOICE type when the CHOICE itself is used with an implicit tag (using the specific example: CRLDistPoints) - x509

Question

The Botan crypto library has only a very limited support for the X.509 extension CRLDistributionPoint and actually throws an exception, if any of the "advanced" attributes of the extension are set which are not expected by Botan.
Hence, I try to patch the decoding of this extension, but I have a problem to correctly determine the type of the encoded objects based on the tags. Either this is an oversight in the specification for this extension (I doubt it) or I am subject to a fundamental misunderstanding of the encoding/decoding rules.
Here are the relevant parts of the specification
CertificateExtensions {joint-iso-itu-t ds(5) module(1)
certificateExtensions(26) 5} DEFINITIONS IMPLICIT TAGS
CRLDistPointsSyntax ::= SEQUENCE SIZE (1..MAX) OF DistributionPoint
DistributionPoint ::= SEQUENCE {
distributionPoint [0] DistributionPointName OPTIONAL,
reasons [1] ReasonFlags OPTIONAL,
cRLIssuer [2] GeneralNames OPTIONAL
}
DistributionPointName ::= CHOICE {
fullName [0] GeneralNames,
nameRelativeToCRLIssuer [1] RelativeDistinguishedName
}
The modules uses implicit tagging by default. In the following this will be important. A DistributionPoint is a SEQUENCE where all attributes are optional. The first optional attribute distributionPoint has the type tag 0 and is of type DistributionPointName. In turn, DistributionPointName is a CHOICE with possible choices which are either tag 0 (if GeneralNames is chosen) or tag 1 (if RelativeDistinguishedName is chosen).
According to my understanding, in case of implicit tagging a CHOICE type is encoded using the tag of the chosen type. In other words, a CHOICE type is not "nested" somehow but encoded on the same level on which the CHOICE type is used. But DistributionPointName has already been given the tag 0.
The specific question is: How is a DistributionPoint encoded, if nameRelativeToCRLIssuer (tag 1) is chosen as the choice for DistributionPointName without triggering a clash with tag 1 of the reasons attribute?
Here is an illustration of my problem:
30 // Type tag for outer SEQUENCE, DistributionPoint starts here
ll // Length of SEQUENCE, omitted here for editorial purposes
+--> 00 vs 01 // Type tag for distributionPoint
| // At first glance, 00 according to SEQUENCE definition for OPTIONAL DistributionPointName,
| // but maybe 01 if RelativeDistinguishedName is the selected CHOICE
| kk // Length of RelativeDistinguishedName, omitted here for editorial purposes
| vv // Encoding of RelativeDistinguishedName begins
| vv
| vv // Encoding of RelativeDistinguishedName ends, accordingly to length kk
+--> 01 // Type tag for OPTIONAL ReasonsFlags
jj // Length of ReasonsFlags
ww // Encoding of ReasonsFlags begins
ww
ww // Encoding of ReasonsFlags ends, accordingly to length jj
// Encoding of DistributionPoint ends, too, accordingly to length ll
In line three, the type tag should be 00 to indicate that the OPTIONAL DistributionPointName exists. This also avoids a clash with the type tag 01 in line 8 for the OPTIONAL ReasonFlags.
However, in line three, the type tag should also indicate which type has been chosen for DistributionPointName. :-(

Answer 1

According to my understanding, in case of implicit tagging a CHOICE
type is encoded using the tag of the chosen type. In other words, a
CHOICE type is not "nested" somehow but encoded on the same level on
which the CHOICE type is used. But DistributionPointName has already
been given the tag 0.
I'm afraid this is the opposite: CHOICE tagging is always explicit whatever the default tagging ...
In the X.680 document, there is following note
The tagging construction specifies explicit tagging if any of the following holds:
c) the "Tag Type" alternative is used and the value of "TagDefault" for
the module is IMPLICIT TAGS or AUTOMATIC TAGS, but the type defined by
"Type" is an untagged choice type, an untagged open type, or an
untagged "DummyReference" (see Rec. ITU-T X.683 | ISO/IEC 8824-4,
8.3).
So, if RelativeDistinguishedName is chosen, distributionPoint component tagging will be 0 (distributionPoint) and then 1 (RelativeDistinguishedName)
The reason for this is that CHOICE does not have a UNIVERSAL tag