Content-Type: text/plain;
	charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.700.6.1.1\))
From: Russ Housley <housley@vigilsec.com>
In-Reply-To: <47e2986d-dcfe-4acc-aa18-a253c230ee49@nthpermutation.com>
Date: Thu, 23 May 2024 15:59:14 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <BEDB38D1-0C5E-4EF9-A6EF-717747837F67@vigilsec.com>
References: <d83723fe-6033-43d4-b2c5-9dd9f5989893@nthpermutation.com>
 <9F6362A6-FB58-48A7-8AD6-9132758604D3@redhoundsoftware.com>
 <47e2986d-dcfe-4acc-aa18-a253c230ee49@nthpermutation.com>
To: Mike StJohns <msj@nthpermutation.com>
Message-ID-Hash: A6BN4OAHBF66YBZ7P6BDGFEXTX5ZFB7O
CC: Carl Wallace <carl@redhoundsoftware.com>, spasm@ietf.org
Precedence: list
Subject: =?utf-8?q?=5Blamps=5D_Re=3A_=5BEXTERNAL=5D_Re=3A_WG_Last_Call_for_draft-ietf?=
 =?utf-8?q?-lamps-csr-attestation-09?=

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