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

[Michael StJohns <[e-mail]>]

In line..

On 2/11/2026 12:23, Mike Ounsworth wrote:
> Hi Mike,
>
> > 1) Changing the registry requirement from "Specification Required" 
> to "Expert Review".
>
> Umm. Sure? I guess. The whole point of a cross-reference registry is 
> to point at other specifications, so it seems a bit weird to be able 
> to point at specifications that don't have a specification. To 
> correctly parse a payload, you're gonna need a proper spec that 
> specifies both structure and semantics of the payload, so I think that 
> requiring everything in this registry to have a proper published spec 
> is a good thing. But ok, if you say so, and that gets us to finally 
> stop arguing and get this stupid document published, then fine, whatever.

This isn't actually a registry, it's a cross reference list. Posting 
stuff here does not result in any actual registration of an ASN1 
entity.   After sitting through various IANA related meetings, avoiding 
"Specification Required" where not needed is probably a good thing. 
Given that I wouldn't expect a lot of folk to provide these cross 
references, and I've seen mostly resistance to a registry where the IANA 
owns the OIDs, I don't know this will get a lot of use.  Reducing the 
bar to add an entry  so the table might be useful seems like a good idea.

>
>
> > 2) Adding a "Name" column to make it easier to search for a given 
> declaration. E.g. - if the declaration is "mikes-attest 
> ATTESTATION-STATMENT ::= { MikeStruct IDENTIFIED BY id-mike-oid }, the 
> first three columns of the the row would be:
>
> Fine.
>
>
>
> > 3) Deleting any initial contents of the registry - specifically the 
> CMW binding.
>
> Alright, so now you're not reading.

Nope - I read everything,  I'm pretty sure you haven't, and most of what 
you wrote that follows the above line isn't really relevant to the 
technical issues.

in https://datatracker.ietf.org/doc/draft-ietf-rats-msg-wrap/ you've 
defined the CMW structure, and oid and an OID/CMW binding for EXTENSION, 
not for ATTRIBUTE and not for ATTESTATION-STATEMENT.  E.g. this.

>   -- CMW Extension
>
>     ext-CMW EXTENSION ::= {
>       SYNTAX CMW
>       IDENTIFIED BY id-pe-cmw }
>
>     -- CMW Extension OID
>
>     id-pe-cmw  OBJECT IDENTIFIER  ::=
>        { iso(1) identified-organization(3) dod(6) internet(1)
>          security(5) mechanisms(5) pkix(7) id-pe(1) 35 }
>
>     -- CMW Extension Syntax
>
>     CMW ::= CHOICE {
>         json UTF8String,
>         cbor OCTET STRING
>     }
That declaration of an EXTENSION is sufficient to say "If you see an 
Extension with 'id-pe-cmw' as the OID, then the body of the Extension 
(wrapped within an OCTET String) be will be encoded as a CMW 
structure".  I don't understand why you're resisting doing the same for 
ATTESTATION-STATEMENT.

If I see an Attribute structure with the 'id-pe-cmw' OID, I might assume 
that the body of the Attribute is a CMW structure, but there's nothing 
telling me that's actually the case, and in security schemes, I hate 
making assumptions.  If you want an ATTRIBUTE with id-pe-cmw indicating 
a CMW structure, then write the definition.

All you need to do to close the loop is make to a declaration for 
"attest-cmw ATTESTATION-STATEMENT" as suggested elsewhere and put it in 
the CMW document ASN.1 module , importing "ATTESTATION-STATEMENT" from 
CSR-ATTESTATION-2025.  Then ask the IANA to add the declaration 
information to the cross reference being set up by 
draft-ietf-lamps-csr-attestation.  Or do it later in an email

All of our documents have specified  explicit bindings between OID and 
structures and types - going back to the earliest use of "ANY".  The 
main change - starting about 2000 (RFC2985) and strongly reinforced 
since Jim et published RFC5911 and 5912 - has moved that specification 
of the bindings out of the surrounding text into a 
compilable/enforceable declaration in the body of the ASN.1.

>
> > For (3), simply declaring a structure and an OID is not sufficient 
> to define something that is an ATTESTATION-STATEMENT
>
> Yes. The authors fully agree with you. We made a change back in -21 in 
> October (which survived the Design Team's re-write) to add a Type column.
> It seems like, in addition to specifying the OID and wire format of 
> the payload, you also expect payload specs to provide compiler hints 
> for your favourite compiler (because at the end of the day, what's 
> what ASN.1 CLASSes are). I don't agree. *_I think that the CMW draft 
> specifying an OID and a DER-based wire encoding ought to be sufficient 
> for the payload to be carryable._*

If that (underlined statement) is true why did this 
(draft-ietf-lamps-csr-attestation) document declare both 
"ext-attestation" for EXTENSION  and "attr-attestation" for ATTRIBUTE?  
Both are using id-aa-attestation as the OID....


>
> IMO anyone who loves ASN.1 so much that they have built an application 
> that requires all the CLASS stuff is also perfectly capable of filling 
> in the gaps there. It's just wiring. Set bindsPublicKey to TRUE / 
> FALSE (which is not a global property for all CMWs; it's gonna depend 
> on what's being carried inside), and decide whether you have any aux 
> data that needs to be carried in an Attribute (which, again, will not 
> be a global property for all CMWs, but will depend on the actual payload).
>
> I am concerned that this ASN.1 module has gotten so freaking 
> complicated that it's gonna be unimplementable for its intended 
> purpose of being a completely payload-agnostic transport envelope. I 
> feel like I've completely lost track of what this draft is even trying 
> to accomplish anymore. Maybe we should just declare failure and let it 
> expire?
>
You've made a claim to "complexity" multiple times... and this is one of 
the simpler modules I've seen.   I have a hard time crediting that as a 
problem.

Later, Mike

ps - I've noted all of the other comments and they mostly echo what Mike 
has wrote.  If I've missed addressing a technical concern in one of the 
other documents, I'd appreciate a concise description of the problem and 
I'll do another reply.