[lamps] Re: About MSJ's proposal for the new Attestation OID Registry in draft-ietf-lamps-csr-attestation

[Michael StJohns <[e-mail]>]

Hi Peter -

Some comments mostly in line and trying to avoid religious comments!

On 2/16/2026 02:54, Peter Gutmann wrote:
> ASN.1 2002 is what happens when a bunch of academics spend a lot of time in a
> bubble filled with similar-minded types and decide to second-system the hell
> out of something (ASN.1 1988) that was orignally simple and (mostly) worked.

My understanding differs from you.  AFAICT, much of the 2002 syntax came 
into being to fix some of the ambiguities of the ANY construct and in 
part the MACRO model.   See for example the AlgorithmIdentifier for 
various types of public keys, and specifically the confusion over empty 
parameters vs NULL parameters.   Or the addition of the CONTAINING 
keyword to actually indicate that yes, sure that OCTET STRING really 
does contain an encoded structure.  "ANY" and open types has made having 
to wrap an ASN1 type in an OCTET STRING/BIT STRING  mostly superfluous 
for new definitions.

What's impressive is that overall, the on-the-wire encoding of a given 
AlgorithmIdentifier hasn't changed even though the definition of 
AlgorithmIdentifier has over the pre-1988, 1988, 2002 and whenever 
parameterized types were added.

> This one definitely needs some "this is what this stuff looks like when
> encoded" text added to guide implementers, but see also the final paragraph
> below.

Given that there are dozens of TYPE-IDENTIFIER-like CLASS definitions in 
RFC5911/5912 and elsewhere, as well as the various structures associated 
with given TYPE-IDENTIFIERS, (c.f. CONTENT-TYPE and 
ContentInfo/EncapsulatedContentInfo, OTHER-CERT-FORMAT and 
OtherCertificateFormat, SIGNATURE-ALGORITHM and 
SignatureAlgorithmIdentifier, etc.) why do you think this 
(ATTESTATION-STATEMENT and AttestationStatement) is any different than 
those?

I think each definer of an ATTESTATION-STATEMENT is going to want to 
talk about what goes into the Type that they bind to the Object 
Identifier, but that's not in this document.  Last, a given ASN.1 
definition can be encoded using BER, DER, OER, PER, JER (Json Encoding 
Rules), XER (XML Encoding Rules), so I would assume that you only mean 
either BER/DER?  But I can't see any ambiguity in how to encode an 
AttestationStatement given an ATTESTATION-STATEMENT declaration to pair 
with it.

Later, Mike


Later, Mike