[lamps] Re: [EXTERNAL] Re: WG Last Call for draft-ietf-lamps-csr-attestation-09

[Russ Housley <[e-mail]>]

Mike:

> In my case, I deal with both ASN1 SIGNED objects and flat signed objects of various flavors.   If I see the [0] tag, I know I can continue the parsing of the structure without first looking up the meaning of the OID and figuring out what the meaning of the various bits are (Syntax parsing vs semantic assignment).  I can pass a parsed ASN1 tree structure to the validator/object creator associated with the OID rather than stopping after parsing the top level.

The ASN.1 tools that I use do not allow processing as you describe.  The look up of the OID is required before parsing can continue.  In pyasn1, you can provide a map of the supported OIDs and the associated types.  Doing this just lets the library do the lookup.  Otherwise, the lookup is done by the application, and then a separate call to the parser is needed to handle the open type (a.k.a. ANY in the old ASN.1 syntax).

With Carl's suggestion, the OTHER-CERT-FMT defined in RFC 5911 handles the cases where the certificate has an ASN.1.  It is identical to the TypedCert in the existing document (with slightly different field names).

With Carl's suggestion, non-ASN.1 encoded certificates as given an ASN.1 type of OCTET STRING, and then decoding will just provide the octets to the application, which is exactly what TypedFlatCert does.

When the early versions of this document were posted, I observed that TypedCert and TypedFlatCert could be merged in this way.  I still think that they should be merged.

Russ