Question about ASN1 Tag types used in CRMF

[Taowyoo]

From source code, such as CertTemplate, tag type used for some fields are EXPLICIT, why they are inconsistent?

From RFC: https://datatracker.ietf.org/doc/html/rfc4211#appendix-B
All tags seem default to IMPLICIT in CRMF types, see:

DEFINITIONS IMPLICIT TAGS ::=
BEGIN

[Taowyoo]

CC: @carl-wallace
I saw you mentioned you was working on these part, so CC you.

[tarcieri]

It looks like the issuer and subject fields are marked as EXPLICIT. I'm not sure why.

Looking at RFC4211 § 5 I don't see anything to indicate these fields should be EXPLICIT. I agree they are probably supposed to be IMPLICIT.

[Taowyoo]

Also I am not very familiar with ASN1 Tag DER decode/encode, I am using yasna for decode/encode and found EXPLICIT and IMPLICIT tag are not compatible to each other (at least from code not sure if they should be compatible in binary format). So I create this issue for clarification.

Appropriate if anyone could help ask my confusion above.

If they supposed to be IMPLICIT, i could help to make the PR.

[carl-wallace]

The reason is that Name is defined as a CHOICE. It looks weird but I am fairly certain you are not going to get the desired result if you change it. There are tests again OpenSSL generated requests and I have interoperated with a CA using this crate as currently defined.

[tarcieri]

It might be good to add some documentation to that effect

[carl-wallace]

OK. I will look up the appropriate ASN.1 reference on tagged CHOICES and push a comment later this week.

[xinyufort]

Jumping into the convo here...

I took a closer peek at the latest X.680 spec. And in rule 31.2.7, I found this:

The tagging construction specifies explicit tagging if any of the following holds:
a) the "Tag EXPLICIT Type" alternative is used;
b) the "Tag Type" alternative is used and the value of "TagDefault" for the module is either EXPLICIT
TAGS or is empty;
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).
The tagging construction specifies implicit tagging otherwise.

This matches what Carl was saying about Name being a choice type -- and in this case, Name is an untagged choice type:

Name ::= CHOICE { -- only one possibility for now --
      rdnSequence  RDNSequence }

(copied from RFC 5912)

And in fact, rule 31.2.9 further solidifies this:

The IMPLICIT alternative shall not be used if the type defined by "Type" is an untagged choice type or an
untagged open type or an untagged "DummyReference" (see Rec. ITU-T X.683 | ISO/IEC 8824-4, 8.3).

I know @carl-wallace has already created PR #1226 to address this issue, and it's been merged. I'd figured I'd still comment here though, to inform others and (more importantly) myself. I suppose I could open a new PR to update the comment that Carl made (since he only referenced rule 31.2.6 in his comment), but that's probably overkill 😉

EDIT: this isn't to say that rule 31.2.6 doesn't apply. I just personally found rules 31.2.7 and 31.2.9 to be more explicit in describing why we need explicit tagging for the issuer and subject fields

[xinyufort]

On a side note, we can probably close this issue now :)

[carl-wallace]

I opted not to use those words on purpose. I don't find the "untagged choice" verbiage to be helpful and find "not needed during transfer" to be more helpful, if still vague. To each his own.

[xinyufort]

I don't find the "untagged choice" verbiage to be helpful

You do have a point; after writing my last comment, I spent another 30 minutes or so trying to figure out what a "untagged choice" was to begin with 🤡