4 Translating Existing ASN.1 Definitions

This section gives general advice on translating existing ASN.1 modules.

4.1 Translating ASN.1 Definition Order

In ASN.1 modules, definition order doesn’t matter, and ASN.1 code often takes advantage of this by ordering definitions top-down. Translating the ASN.1 module to Racket may require reordering the definitions.

For complex modules, it can be difficult to find a legal ordering that also preserves relatedness. In such cases, it may be better to split the module into three coarse sections, consisting of object identifier definitions, type definitions, and information object set definitions.

Object identifier definitions should come first, because they never depend on types or information object sets, and they are easy to locally reorder. Use OID and build-OID to preserve the mnemonic names associated with arc numbers.

Type definitions should come next. Type definitions can be made independent of ordering by defining them using define-asn1-type, which is a simple abbreviation for define with Delay. Alternatively, type definitions can be locally reordered bottom-up. Associated value definitions, such as named integers, can be left close to their associated types, or they can be moved to a different section.

Information object set definitions should come last, because they typically refer to both object identifiers and types. Occasionally they must be reordered within their section, for example when an information object set aggregates other sets.

4.2 Translating Information Classes, Objects, and Object Sets

This library does not directly support ASN.1 information classes, objects, and object sets. In general, however, only information object sets need to be represented, and they can be represented as functions, dictionaries, or association lists.

Consider the following ASN.1 code from [PKCS1]:

The definition for ALGORITHM-IDENTIFIER indicates that the class serves as a mapping from OBJECT IDENTIFIERs to types. The following information object set can be represented as an association list as follows:

(define OAEP-PSSDigestAlgorithms

(list (list id-sha1   NULL)

(list id-sha256 NULL)

(list id-sha384 NULL)

(list id-sha512 NULL)))

The following ASN.1 code defines a type parameterized by an ALGORITHM IDENTIFIER information object set, and then instantiates the type at the set defined above:

Type parameterization can be represented as a Racket function, and instantiation as application. The type lookup can be accomplished by a dependent sequence field type.

(define (AlgorithmIdentifier InfoObjectSet)

(SEQUENCE [algorithm OBJECT-IDENTIFIER]

[parameters #:dependent (cadr (assoc algorithm InfoObjectSet))]))

(define HashAlgorithm (AlgorithmIdentifier OAEP-PSSDigestAlgorithms))

4.3 Handling Unsupported Types

ASN.1 defines many additional base types that are unsupported by this library. An example is T61String, which has escape codes for changing the interpretation of following characters. It is infeasible for this library to handle the validation and interpretation of T61String, so it does not define the type at all. However, an application may define the type (or an approximation, if full validation and interpretation are not needed) using Tag with a universal implicit tag.

Here is a basic definition of T61String using Tag:

> (define T61String (TAG #:implicit #:universal 20 OCTET-STRING))

> (asn1->bytes/DER OCTET-STRING #"abc")

#"\4\3abc"

> (asn1->bytes/DER T61String #"abc") ; note different tag byte

#"\24\3abc"

> (bytes->asn1/DER T61String (asn1->bytes/DER T61String #"abc"))

#"abc"

When encoding a T61String, the same Racket values are accepted as for OCTET-STRING—that is, bytestrings (bytes?)—and the same validation is performed—that is, none. Likewise when decoding.

To change the way T61Strings are encoded and decoded, use WRAP to add encoding and decoding rules. Let us pretend for a moment that T61Strings are just Latin-1 strings. Then we could define T61String with automatic conversion to and from Racket strings as follows:

> (define T61String     (WRAP (TAG #:implicit #:universal 20 OCTET-STRING)           #:encode string->bytes/latin-1           #:decode bytes->string/latin-1))

> (asn1->bytes/DER T61String "pretend T61 is Latin-1")

#"\24\26pretend T61 is Latin-1"

> (bytes->asn1/DER T61String (asn1->bytes/DER T61String "pretend T61 is Latin-1"))

"pretend T61 is Latin-1"

The following ASN.1 pseudo-definitions may be helpful in translating ASN.1 features not directly supported by this library. (Page numbers refer to [Dubuisson2001].)