[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

ASN.1

ASN.1 is no longer a language for describing data structures. It is a
language for describing information objects (see X.680, X.681, X.682,
X.683, & X.690). Of course, if you don't use an ASN.1 compiler with a
runtime capable of enforcing the rules defined in the ASN.1 definitions,
then ASN.1 would certainly appear to be overkill as a data description
language.

To illustrate my point, consider the following from X.509(v3)...

      AuthorityKeyId ::= SEQUENCE {
         keyIdentifier     [0] KeyIdentifier OPTIONAL,
         certIssuer        [1] Name OPTIONAL,
         certSerialNumber  [2] CertificateSerialNumber OPTIONAL
         -- certIssuer and certSerialNumber constitute a logical pair
         -- and if either of these is present, both must be present.
         -- Either this pair or the keyIdentifier field or all of them
         -- shall be present in the type.
      }

If you're using what I like to refer to as the "Bytes Method :-)", this
can be a difficult definition to map to a c structure. But if I redefine
it as an information object for use with an automatic encoder/decoder as...

     AuthorityKeyId ::= SEQUENCE {
        keyIdentifier     [0] KeyIdentifier OPTIONAL,
        certIssuer        [1] Name OPTIONAL,
        certSerialNumber  [2] CertificateSerialNumber OPTIONAL
     } ( WITH COMPONENTS { keyIdentifier ABSENT,
                             certIssuer  PRESENT, certSerialNumber PRESENT } |
         WITH COMPONENTS { keyIdentifier PRESENT,
                             certIssuer  ABSENT,  certSerialNumber ABSENT  } |
         WITH COMPONETS  { keyIdentifier PRESENT,
                             certIssuer  PRESENT, certSerialNumber PRESENT } )

I get the c (c++ soon) mapping performed for me, and I get the component
relation rules enforced at runtime (just what you'd expect in an OPPs
environment). But better that that, I can change the rules in my ASN.1
defintion (being careful not to code anything that affects the bits-on-
the-wire) without affecting programmers that live downstream.

When a c programmer looks at some DER data, the rules defined in the ASN.1 are
no longer present. They must be understood and enforced by the programmer.
An ASN.1 compiler remembers the rules and provides a means for them to be
enforced when encoding or decoding the raw data. If the same ASN.1 is used on
each end of a transaction, there is little chance of an interoperability
failure due to a misinterpretation by a programmer. Of course, ASN.1 is a
difficult language to learn (I'm still working on it - no end in sight), so
it's still possible to screw things up, but I'm not convinced that any
language rich and powerful enough to be useful can solve such problems.

Regards, Phil
griffin@vnet.ibm.com