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

[Carl Wallace <[e-mail]>]

Replies inline. As a reminder, Tim sent a note to the list on 12/18 introducing the changes: https://mailarchive.ietf.org/arch/msg/spasm/HH3XBz0lDhreqwZnnmJ-G_KnmEE/.

 

From: Mike Ounsworth <[e-mail]>
Date: Thursday, February 12, 2026 at 7:40 PM
To: "Salz, Rich" <[e-mail]>
Cc: Carl Wallace <[e-mail]>, Michael StJohns <[e-mail]>, LAMPS WG <[e-mail]>
Subject: Re: [lamps] Re: About MSJ's proposal for the new Attestation OID Registry in draft-ietf-lamps-csr-attestation

 

Hi Carl,

 

<snip>

 

... just ... this seems overly complicated to me:

 

AttestationStatement ::= SEQUENCE {
   type   ATTESTATION-STATEMENT.&id({AttestationStatementSet}),
   bindsPublicKey [0] BOOLEAN DEFAULT TRUE,
   stmt   ATTESTATION-STATEMENT.&Type(
              {AttestationStatementSet}{@type}),
   attrs  [1] Attributes {{AttestAttrSet}} OPTIONAL
}

 

[CW] I think it is helpful to contrast the above with what preceded it (shown below), as much of the complexity is shared.

 

EvidenceStatement ::= SEQUENCE {

   type   EVIDENCE-STATEMENT.&id({EvidenceStatementSet}),

   stmt   EVIDENCE-STATEMENT.&Type({EvidenceStatementSet}{@type}),

   hint   IA5String OPTIONAL

}

 

where we have two CLASSes: AttestationStatementSet and AttestAttrSet.

We also have a field that is optional, but if absent MUST be considered to be True, which smells like a footgun for anyone implementing a custom parser for this.

 

[CW] Default values are a standard ASN.1 feature even in the older syntax. Anyone implementing a parser will need to be able to deal with defaults. 

 

This is not a simple struct; there are a lot of moving parts here.

 

Also where `Attributes` is defined in RFC 5912 as `SET OF Attribute{{ IOSet }}` where `Attribute` itself is a big complex definition meant to handle all the complexity of X.509 and CMS. That's a heavy definition to import. What are the concrete use cases for Attributes? 

 

[CW] This was included to allow a spot for the much-discussed validator “hint” to land once validators and corresponding protocols and data structures are more defined.

 

As I understood MSJ's use case; he has attestation data that comes with one core statement and a few bits of ancillary data (other than a cert chain) required to validate the core statement. One way or another the people producing that data need to define a way to serialize it; either specify a standalone serialization (which is probably what they want), or define a CSR-specific serialization for how you pack their various bits into CSR.AttestationStatement.attrs. The latter (the option represented in the current ASN.1 defn) requires every other implementer to bear the complexity cost of that (via having to support a more complex AttestationStatement structure) for, I believe, no complexity savings for even the people who need it.

 

[CW] The attrs are not intended to be attestation-specific and would contain something general purpose, like a hint or AIA-like construction if/when validators are defined.

 

So this is not really about 1988 vs 2002 syntax, but rather about why there is so much machinery here.

 

[CW] The source document contained basically the same machinery. The previous structure supported a list of attestations, not all of which would be key attestations as I understood it. The Boolean aimed to highlight which were bound to the key. The attributes was an alternative to an oddly specified “hint”. 

 

I'm also not entirely sure I understand the purpose of `bindsPublicKey`, or the text currently in the document about it. Under what conditions is that to be set to True / False? What is the CA supposed to do with that information? Like, what problem is this field trying to solve? What failure mode exists if this field isn't there?

 

[CW] It is indicating which attestation of a possible multitude is bound to the key that is the subject of the CSR (vs traversing the list). It could be dropped if list traversal is preferred. The failure mode is unchanged by the presence of that indicator. It’s not clear to me that a sequence of evidence statements is needed (but we left that as it was).

 

In general, the entity bundling together the CSR could be an openssl script or ACME bot that may not actually know the semantics of the attestation data that it's bundling, so I think if we're gonna add this `bindsPublicKey` field, we need some pretty clear implementation guidance for it. 

 

[CW] One might say the same thing about the “SEQUENCE SIZE (1..MAX) OF EvidenceStatement” in -21 and below. The key attestations I am familiar with do not need this, but if folks want platform attestations alongside key attestations that makes sense (hence the flag to single out the key attestations). One could require some ordering of the list but that’s not simpler. In any case, I don’t view the bindsPublicKey value as some critical element (and I doubt Tim or Steve would). If the consensus is that an indicator like this is unnecessary, then delete it.

 

And then I think we need to ask whether this implementation guidance is going to be possible to follow for all clients, or if we've created something that's unimplementable. 

 

[CW] I can’t see how the addition of a bool and refashioning a hint as Attributes changes much in terms of “unimplementability”, but that may be a good question to ask in general.

 

Also, do we need to specify any rules for the entity parsing the CSR based on whether this field is True or False? In summary: I don't understand the purpose of this, and the text currently in the document does not clear it up.

 

[CW] Maybe it should be described as a hint for verifiers only interested in key attestations and not platform attestations, etc.

 

Also, where did the Hint go? We had a real-world need for that. I assume that content should go into an Attribute now? The current document says:

"This specification does not define any Attribute instances."

... but shouldn't it? Shouldn't you have lifted our Hint stuff into an Attribute? Why is it gone? Was there a justified reason that the Design Team deleted all that?

 

[CW] As discussed during the interim in November, hint was underspecified and did not have consensus in -21 or before. We replaced it with an extensibility mechanism you could use to incorporate a hint attribute when verifier protocols and data structures are better defined.

 

Do we have a volunteer to generate samples that exercise this new functionality? Maybe seeing real-world examples of bindsPublicKey: True / False, and of Attributes would help me to understand their purpose?

 

[CW] I am not aware of a volunteer to generate samples.

 

Sorry it's taken me so long to formulate a response to the Design Team's work here, but I think my response is:

"I appreciate the effort that the Design Team has put into this, but I don't understand the changes that the Design Team made. Can they please do a presentation explaining the changes?".

Probably, we should have organized a presentation when the DT delivered their report, cause I honestly got a bit overwhelmed by the scope of the proposed changes.

Maybe the DT should take the speaking slot for this draft at 125?

 

[CW] I cannot attend. I have CC’ed Tim and Steve to see if they can attend. The bulk of the changes were subtractions.  None of those have been noted here, so that’s good. If the primary issues are with the bindsPublicKey and attrs fields we ought to be able to resolve that without a presentation.

 

I certainly don't feel like I can present this draft at 125 given that I don't understand it.

 

[CW] OK, though at the ASN.1 level the changes for “evidence” are minimal: a new Boolean field and an Attributes bucket where the hint used to be. As noted in the note to the list, “attestations the design team is currently aware of would all set the bindsPublicKey indicator to true and would not require the optional attributes.” Instances of that sort would look like the old struct without the optional hint. The changes were more about future proofing for when things like hints or evidence other than key attestations are desired.

 

 

 

On Thu, 12 Feb 2026 at 15:19, Salz, Rich <[e-mail]> wrote:

I will accept that 1988 syntax is no longer feasible, thanks for the semi-references :)

 

I still think this is way too complicated. Have any CAs said they want this or intend to implement it? The one notable party, Entrust, is no longer in that business, And I don’t mean just the WebPKI CAs, but even things like BouncyCastle, etc.