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

[Mike Ounsworth <[e-mail]>]

Hi Mike,


> *The allocation of an OID is not sufficient to declare an
ATTESTATION-STATEMENT binding*

Yeah, full agreement. When you pointed that out several months ago, the
authors went "oops -- of course the registry needs to list what the
structure is, not just its OID", and we added it in -21.

The ASN.1 module in draft-ietf-rats-msg-wrap-23 is:

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 ::= CHOICE {
    json UTF8String,
    cbor OCTET STRING
}


To me, that is a perfectly well-defined pair of OID and wire encoding.
Maybe I'm bad at ASN.1, but to me that is a perfectly unambiguous ASN.1
specification of what the bits on the wire will be. If the ASN.1 structures
in draft-csr-attest are not capable of ingesting that definition as a valid
payload, then that's a problem with our ASN.1 being too complicated. I
understand the difference between a concrete ASN.1 Type, and an ASN.1
CLASS. I understand that the ASN.1 mod in draft-ietf-rats-msg-wrap-23 is
not sufficient to instantiate the CLASS stuff currently in
draft-csr-attest, and I don't think it should have to.

I like analogies: if someone is providing you an XML document, it is
reasonable to expect them to also provide an XML Schema for it. If you
choose to use a C++ XML parser that requires the schema as a C++ header
file; cool, but don't expect the authors of the format to provide that
header file for your chosen parser. The world doesn't run on ASN.1 anymore.
CMW is fundamentally a CBOR or JSON encoded object. The fact that CMW
authors provided us with a definition for a DER wrapper is great and now
it's on us to figure out how to carry that (and other DER structs defined
in similar ways which I'm sure there will be more of in the future), not to
declare it uncarryable because it didn't also provide compiler abstractions
for your chosen compiler.

Also, the CMW payload, and the CSR-Attest transport should be separate
layers. Requiring the CMW specification to even be aware of the CSR-Attest
semantics seems to me like a crazy layer violation; that would be like
saying that that XML Schema is incomplete if it doesn't also specify HTTP
headers and TLS cipher suites. Why?

I see two possible ways forward here:

1. We decide that the difference between the CMW CHOICE def
in draft-ietf-rats-msg-wrap-23, and the AttestationStatement
in draft-ietf-lamps-csr-attestation are compatible enough that an
implementer should be able to bridge them.

or

2. We decide that the AttestationStatement definition
in draft-ietf-lamps-csr-attestation is too complex and needs to be
simplified.

I do not accept the position that we've made the CSR attribute definition
so complex that every DER-encoded payload that we want to carry will now
require its own spec telling you how to set all the CSR attribute metadata.

On Tue, 10 Feb 2026 at 16:16, Michael StJohns <[e-mail]>
wrote:

> On 2/10/2026 15:50, Mike Ounsworth wrote:
>
> Hi MSJ,
>
> Sorry I had to leave the meeting at the top of the hour yesterday, so I
> did not hear your explanation about your proposed change.
>
> The commit and line number in question is here:
>
>
> https://github.com/lamps-wg/csr-attestation/pull/232/changes#diff-0f9c8dc6ee2ac6d331a3fdf2859e38c90e83c56ad6b667bfd79bb44877b43820L360
>
>
> Let me take a step back to make sure we're level-set on the purpose of
> this registry: it is to collect a list of OID - ASN.1 Type pairs that
> implementers may encounter inside CSRs in the wild. Informative, not
> Normative.
>
> A while back you suggested that this registry had a column for OID but not
> a column for the corresponding ASN.1 type. The authors agreed with you and
> we added this in --21. At the same time we deleted from the Initial
> Registry Contents all of the TCG stuff since we (the authors) could find
> published OIDs for them but not published ASN.1 defs, which means they did
> not meet the criteria for inclusion in this registry at the current time.
> That left CMW, which is the only thing we are aware of at present which is
> a valid payload for an attested CSR, and has a published OID, and has a
> published ASN.1 type (all in draft-ietf-rats-msg-wrap-23).
>
> You have now proposed a PR to the draft which removes the "Initial
> Registry Contents" section, removes this:
>
>
> * CMW
>   * OID: 1 3 6 1 5 5 7 1 35
>   * Type: CMW
>   * Description: id-pe-cmw
>   * Reference(s): {{I-D.ietf-rats-msg-wrap}}
>   * Change Controller: IETF
>
> and replaces it with
>
>
> - OID: 1.2.3.4.5
> - Name: exampleAttest
> - Type: ExampleStruct
> - Description:  This is an example template for registering
> ATTESTATATION-STATEMENT declarations
> - Reference: Provided by [e-mail], no specification provided.
>
>
> Can you please explain your thinking behind this proposed change? Surely
> you agree that CMW as specified in draft-ietf-rats-msg-wrap-23 meets the
> criteria for inclusion in this registry (and in fact, is currently the only
> standardized thing that does).
>
> Sure.  This will be pedantic because ASN.1 CLASS and open type stuff is
> complicated.  This is all assuming modern ASN.1 not ASN.1 1988 stuff.
>
> *The allocation of an OID is not sufficient to declare an
> ATTESTATION-STATEMENT binding*. Or for that matter an ATTRIBUTE or
> EXTENSION binding.
>
> For example, ATTRIBUTE, EXTENSION and ATTESTATION-STATEMENT are
> TYPE-IDENTIFIER like declarations.  You can bind an OID to pretty much any
> structure, but the actual underlying class declaration may give you more
> options for your declaration:
>
>   attr-cmw ATTRIBUTE ::= { TYPE CMW IDENTIFIED BY id-pe-cmw }
>
>   ext-cmw EXTENSION ::= { SYNTAX CMW IDENTIFIED BY id-pe-cmw }
>
>   attest-cmw ATTESTATION-STATEMENT ::= {  CMW IDENTIFIED BY id-pe-cmw }
>
> All of these are legal declarations, and we sometime omit actually making
> them explicitly - e.g. by stealing an OID for an extension and just
> plugging it in to use for an ATTRIBUTE.  But this is also legal for an
> ATTRIBUTE:
>
>
>
>   attr-cmw ATTRIBUTE ::= { TYPE CMW
>                            COUNTS MAX 1
>                            EQUALITY MATCHING RULE
> id-someoid-for-matchingrule
>                            IDENTIFIED BY id-pe-cmw }
>
> Note that this still assigns the CMW to an OID, but also provides some
> additional rules specific to use with ATTRIBUTE.  This turns out to be the
> usual way we do this assignment.
>
> Declaring the CMW structure by itself does not meet the criteria for
> inclusion, nor does declaring the oid, or merely stating the OID/structure
> combo.  What you want is an actual ATTESTATION-STATEMENT declaration you
> can reference:
>
>      attest-cmw ATTESTATION-STATEMENT ::= { CMW IDENTIFIED BY id-pe-cmw }
>
> and around that declaration you need some text explaining things like "The
> Attributes field is optional, but when present at least one
> ATTRIBUTE/Attribute that will usually be present is the 'attr-hint' defined
> as "attr-hint ATTRIBUTE ::= { TYPE IA5String IDENTIFIED by id-at-hint }"
>
> The side effect of creating the declaration is to populate declaration
> into the "..." part of the "AttestationStatementSet ATTESTATION-STATEMENT
> ::= { ... }" table.  That is the table referenced by the
> "AttestationStatement" structure declaration.
>
> We also pair a name for the declaration so the declaration can be used
> later in other things - like the set of attributes or set of types of
> attestation statements. Example using FAKE TPM-like attestation
> declarations:
>
> attest-tpm-set ATTESTATION-STATEMENT ::= { attest-tpm-key |
> attest-tpm-chip | ... }
>
> Fake related text: " An Extension containing an AttestationBundle for TPM
> attestations will generally include the Attestation(s) listed in
> 'attest-tpm-set', but may contain additional Attestation types "
>
> So the registry table is not simply OID/Structure, but Name/OID/Structure
> to match the declaration.
>
> As for not including it here - this is a cross reference rather than a
> registry per se.  Declaring this in the CMW document, or even just
> declaring it later and providing text related to say the actual
> implementation is a more appropriate way of doing things especially with my
> suggested change to "Expert Review" from "Specification Required".
>  Otherwise declaring it here would mean that the ASN.1 module would have to
> import the CMW module, CMW structure and the CMW OID from the CMW document
> and would lead this document dependent on that one.
>
> *TL;DR - The declaration of an OID and a structure is necessary, but not
> sufficient to create a CLASS instantiation of any type.  *
>
>
> Mike
>
>
>
> Post script:
>
> At the last F2F meeting, I had a brief discussion with the IANA folks of
> creating a single cross-ref registry-like table:
>
> Name:  The declaration name - the left most part of a class instance
> declaration.
> *Declaration Type:* The class type - e.g. EXTENSION, ATTRIBUTE,
> ATTESTATION-STATEMENT *Identifier:*  The OID.  Note that the same OID may
> be used for multiple CLASS declarations, but only a single declaration
> within a given type.  So there may be multiple entries with the same OID,
> but there may not be multiple entries with the same OID/Declaration Type
> pair. *Structure Type:*  The main  or first field type in the
> declaration.  If there are multiple open type fields, list only the first
> one here. *Description:* yada yada *Reference:*  The requester or Ideally
> a URL or stable reference to figure out what the declaration actually meant.
>
> If the group thinks the stuff immediately above is a better approach, then
> the right answer is to remove the "registry" from the draft document and
> I'll write a request/draft  for the creation of a "ASN.1 Class declaration
> cross reference registry".
>
> Personally, I'm getting a bit tired of having to figure out from an OID
> where to find a declaration in various certificates, attributes and other
> random ASN1 structures I've encountered.  Having a curated list would
> help.  However, it might be a lot of work.
>
> Later, Mike
>
>
>
>