How does [0] and [3] wơrk in ASN1?

Question

I\'m decoding ASN1 (as used in X.509 for HTTPS certificates). I\'m doing pretty well, but there is a thing that I just cannot find and understandable documentation for.

Answer 1

[0] is a context-specific tagged type, meaning that to figure out what meaning it gives to the fields (if the "Constructed" flag is set) or data value (if "Constructed" flag is not set) it wraps; you have to know in what context it appears in.

In addition, you also need to know what kind of object the sender and receiver are exchanging in the DER stream, ie. the "ASN.1 module".

Let's say they're exchanging a Certificate Signing Request, and [0] appears as the 4th field inside a SEQUENCE inside the root SEQUENCE:

SEQUENCE
    SEQUENCE
        INTEGER 0
        SEQUENCE { ... }
        SEQUENCE { ... }
        [0] { ... }
    }
}

Then according to RFC2968, which defines the DER contents for Certificate Signing Request, Appendix A, which defines the ASN.1 Module, the meaning of that particular field is sneakily defined as "Attributes" and "Should have the Constructed flag set":

    attributes    [0] Attributes{{ CRIAttributes }}

You can also go the other way and see that "attributes" must be the 4th field inside the first sequence inside the root sequence and tagges as [0] by looking at the root sequence definition (section 4: "the top-level type CertificationRequest"), finding the CertificationRequestInfo placement inside that, and finding where the "attributes" item is located inside the CertificationRequestInfo, and finally seeing how it is tagged.

ASN.1 is so simple, I don't understand how more people don't get it.. "It's just a TLV format.." ;-)