[lamps] Re: WGLC for draft-ietf-lamps-csr-attestation-18

[Carl Wallace <[e-mail]>]

Not worth nuking to my eye. 

On May 9, 2025, at 2:56 PM, Mike Ounsworth <[e-mail]> wrote:



Just for completeness of this thread, here are the CMS definitions we’re discussing:

 

      ContentInfo ::= SEQUENCE {

        contentType ContentType,

        content [0] EXPLICIT ANY DEFINED BY contentType }

 

      EncapsulatedContentInfo ::= SEQUENCE {

        eContentType ContentType,

        eContent [0] EXPLICIT OCTET STRING OPTIONAL }

 

 

I see your point. Designing it like that might have been a better idea. But this draft is in WGLC, that change would require re-doing all the reference implementations and samples, which will put this behind all the PQC drafts in terms of author availability (me). So is this a big enough deal to be worth nuking the WGLC over? (if the answer is Yes, then so be it).

 

 

HOWEVER, I thought we already had a suitable abstraction layer via the EvidenceStatementSet; define the types that you want to be able to parse. If your code doesn’t recognize the OID then even if you can unpack it, you’re not going to know what to do with it anyway.

 

---

Mike Ounsworth

 

From: Carl Wallace <[e-mail]>
Sent: Friday, May 9, 2025 1:31 PM
To: Mike Ounsworth <[e-mail]>; StJohns, Michael <[e-mail]>
Cc: Russ Housley <[e-mail]>; [e-mail]
Subject: [EXTERNAL] Re: [lamps] Re: WGLC for draft-ietf-lamps-csr-attestation-18

 

I thought there was an OCTET STRING for the evidence already and that the hint was what was introducing the variable type (which I what I get for jumping into a thread without having read the draft lately, so sorry about that). Defining this

I thought there was an OCTET STRING for the evidence already and that the hint was what was introducing the variable type (which I what I get for jumping into a thread without having read the draft lately, so sorry about that). Defining this essentially as an EncapsulatedContentInfo with a hint stuck on seems about right to me (though if the hint type needs to vary, I’d add an abstraction layer there too via Attribute(s)). What you say can work, obviously, a la ContentInfo but you have to know the types up front to parse the outer structure. Top level CMS types changes rarely, though, and it’s not clear to me that evidence types are that well established.

 

From: Mike Ounsworth <Mike.Ounsworth=[e-mail]>
Date: Friday, May 9, 2025 at 2:16 PM
To: Carl Wallace <[e-mail]>, "StJohns, Michael" <[e-mail]>
Cc: Russ Housley <[e-mail]>, "[e-mail]" <[e-mail]>
Subject: [lamps] Re: WGLC for draft-ietf-lamps-csr-attestation-18

 

Counter-argument:

 

Some evidence statement types will come with ASN.1 definitions, so we should be able to use those. I suppose (OCTET STRING CONTAINING …) is a reasonably elegant way to do that?

 

But you can also (and probably should) define non-ASN.1 formats as:

 

id: id-pe-cmw

type: OCTET STRING

 

 

But if you think there’s a more natural way to express that, I’m open to suggestions.

 

Note that we’re in WGLC, so I’m not a huge fan of re-doing all the reference implementations and samples unless there’s a concrete problem with the definitions as-is.

 

---

Mike Ounsworth

 

From: Carl Wallace <[e-mail]>
Sent: Friday, May 9, 2025 1:02 PM
To: StJohns, Michael <[e-mail]>
Cc: Russ Housley <[e-mail]>; [e-mail]
Subject: [EXTERNAL] [lamps] Re: WGLC for draft-ietf-lamps-csr-attestation-18

 

Yep, I was wrong in that I’d missed that we already can’t have a generic EvidenceStatement because that second field is also a type (not an OCTET STRING a la CMS). I don’t like that either. I think it’d be best to have an abstraction level there

 

Yep, I was wrong in that I’d missed that we already can’t have a generic EvidenceStatement because that second field is also a type (not an OCTET STRING a la CMS). I don’t like that either. I think it’d be best to have an abstraction level there so you could parse and dispatch it without knowing every structure (let alone two different structures).

 

From: "StJohns, Michael" <[e-mail]>
Date: Friday, May 9, 2025 at 11:18 AM
To: Carl Wallace <[e-mail]>
Cc: Russ Housley <[e-mail]>, <[e-mail]>
Subject: Re: [lamps] Re: WGLC for draft-ietf-lamps-csr-attestation-18

 

Hi Carl - this is basically wrong.   For a given type of statement - say TPM - I will have a fixed auxiliary type that goes with it.  Doing it the way you suggest means that any given EVIDENCE-STATEMENT  type can have multiple different types of auxiliary data attached to it (one at a time).  I’d call that - to reuse a phrase - an interop nightmare.   

 

Later, Mike

 

On Fri, May 9, 2025 at 10:29 Carl Wallace <[e-mail]> wrote:

To try a different point of view, why do we want to break parsing for an optional hint field? Putting this in an Attribute would avoid that (the attribute could parse with the value ignored).

 

From: Carl Wallace <[e-mail]>
Date: Friday, May 9, 2025 at 10:22 AM
To: Michael StJohns <[e-mail]>, Russ Housley <[e-mail]>
Cc: <[e-mail]>
Subject: Re: [lamps] Re: WGLC for draft-ietf-lamps-csr-attestation-18

 

Inline…

 

From: Michael StJohns <[e-mail]>
Date: Friday, May 9, 2025 at 9:35 AM
To: Carl Wallace <[e-mail]>, Russ Housley <[e-mail]>
Cc: <[e-mail]>
Subject: Re: [lamps] Re: WGLC for draft-ietf-lamps-csr-attestation-18

 

Hi -

 

I think you're confused about ASN1 syntax as it applies to classes.  I was for a long time.   Let me try this again, stealing the stuff the edits Russ did and editing a few field names to make things a bit more clear.

 

[CW] I don’t think so, as my comment was and is about what appears in the encoding.

 

EVIDENCE-STATEMENT ::= CLASS {

  &esTypeId          OBJECT IDENTIFIER UNIQUE,

  &ESStmtType,

  &auxPresent ParamOptions DEFAULT absent,

  &AuxType    OPTIONAL

} WITH SYNTAX {

  &ESStmtType IDENTIFIED BY &esTypeId

  [AUX TYPE &AuxType IS &auxPresent]

}

 

EvidenceStatement ::= SEQUENCE {

   oid  EVIDENCE-STATEMENT.&esTypeId({EvidenceStatementSet}),

   stmt EVIDENCE-STATEMENT.&ESStmtType({EvidenceStatementSet}{@oid}), -- type is chosen from the &ESStmtType in

                                                                      -- the EVIDENCE-STATMENT containing the object identifier in the oid field

   aux  EVIDENCE-STATEMENT.&AuxType({EvidenceStatementSet}{@oid}) OPTIONAL } -- ditto for &AuxType - from the same EVIDENCE-STATEMENT used for stmt

 

The above compiles.  I edited the various names so there was no confusion between things like &Type and type.

[CW] Lots of things compile (or at least pass syntax checks) that we probably ought not to do. I am saying that having the type vary in this way is unusual, in my recollection anyway. My first note included a question asking if there were any similar structures already in the toolbox. Do you know of any?

 

The &AuxType *does* appear in the encoding... optionally.   EVIDENCE-STATEMENT.&AuxType.  The specific type chosen is from the EvidenceStatementSet indexed by the value of the oid field.

[CW] Mea culpa. I meant that an identifier for AuxType does not appear in the encoding (and yes, I understand there is an OID expressed in the encoding).

 

[CW] I still think this is prone to be an interop problem should this spec catch on and would prefer to see an aux type identifier present in the encoding to stave that off or ditch the flexible type for hint and settle on something that can be used for different evidence types. I’ll defer further comments until the authors weigh in.

 

Later, Mike

 

 

 

On 5/9/2025 8:22 AM, Carl Wallace wrote:

I think you have amended your example to make my point. The StmtType value appears in the encoding and the AuxType does not. I am suggesting it should if we need flexibility for the hint type.

 

From: Michael StJohns <[e-mail]>
Date: Friday, May 9, 2025 at 7:53 AM
To: Carl Wallace <[e-mail]>, Russ Housley <[e-mail]>
Cc: <[e-mail]>
Subject: Re: [lamps] Re: WGLC for draft-ietf-lamps-csr-attestation-18

 

Oops s/&Aux/&AuxType/ and s/EvidenceStatmentSet.aux/EvidenceStatementSet.auxType/ or something like that.   Note that &Type could be changed to &StmtType for clarity and to be clear that its not the same item as @type or type.

 

On 5/9/2025 7:46 AM, Michael StJohns wrote:

Hi Carl -

 

It's actually 

 

EvidenceStatement ::= SEQUENCE {

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

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

  aux  EVIDENCE-STATEMENT.&Aux ({EvidenceStatementSet){@type}) OPTIONAL

}

 

or in old-speak

 

EvidenceStatement ::= SEQUENCE {

  type OBJECT IDENTIFIER,

  stmt ANY IDENTIFIED BY type,

  aux  ANY IDENTIFIED BY type OPTIONAL

}

 

In other words, the object identifier provides the lookup index - type -  into two different tables - the  EvidenceStatementSet.stmt table and the EvidenceStatementSet.aux table to choose the types for two different fields.  The variable type of the aux field is indicated by the type, just like the variable type of the stmt field.

 

So

 

MikesStatement EVIDENCE-STATMENT ::= {

    MikesEvidence IDENTIFIED BY MikesId AUX TYPE MikesAux IS present }

 

is a concise way of defining an evidence statement as

 

MikesStatement ::= SEQUENCE {

   type OBJECT IDENTIFIER (MikesId),

   stmt MikesEvidence,

   aux MikesAux

}

 

For the folks that want to use hint - just specify "IA5String" (or one of the more specific versions I provided for the hint definition) where I specified "MikesAux" as there's no default type currently defined in the CLASS definition.

 

Seems pretty clear to me.

 

So lets just avoid the fear mongering phrases like "interop nightmare" please?

 

Later, Mike

 

 

 

On 5/9/2025 6:06 AM, Carl Wallace wrote:

I may have missed a turn or two in this thread, but I think it’s the case that we went from this

 

EvidenceStatement ::= SEQUENCE {

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

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

   hint   IA5String OPTIONAL

}

 

To

 

EvidenceStatement ::= SEQUENCE {

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

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

   hint   <type as defined in the class definition> OPTIONAL

}

 

Are there any structures current in the (large) LAMPS toolbox that allow the type of a field to vary in this way? It seems like an interop nightmare. If that kind of flexibility is required, why not use something more common like Attribute(s) where the variable type is indicated in the encoding?

 

 

From: Michael StJohns <[e-mail]>
Date: Monday, May 5, 2025 at 4:02 PM
To: Russ Housley <[e-mail]>
Cc: <[e-mail]>
Subject: [lamps] Re: WGLC for draft-ietf-lamps-csr-attestation-18

 

The silly mistakes are partially avoided by the default setting of &auxPresence to "absent".

 

Looking at RFC5912, I'm slightly confused as it's possible to do (for MESSAGE-DIGEST) a "PARAMS ARE required" (vice "PARAMS TYPE OCTET STRING ARE required") without specifying a type for &Params.  Which doesn't break anything exactly in the compile...  but .. it's weird not to have a default for the &Params type in that case.

 

That said, I think I'm fine with the change.  E.g. &AuxType OPTIONAL in the CLASS section  and no internal option brackets around [TYPE &AuxType] in the SYNTAX section.   I have no problem with requiring a complete specification without defaults for all of the various EVIDENCE-STATEMENT definitions.

 

Thanks - Mike

 

ps - I keep confusing "present" for "required" too....

 

On 5/5/2025 3:31 PM, Russ Housley wrote:

I think it would be better to have the party that is defining an evidence statement to ALWAYS specify the aux information if it exists.  The DEFAULT OCTET STRING can lead to a silly mistake.  It seems trivial to say:

 

                AUX TYPE OCTET STRING IS present

 

to avoid the silly mistakes.

 

Russ

 

On May 5, 2025, at 3:00 PM, Michael StJohns <[e-mail]> wrote:

 

Aux(illary) works.

 

I'd based the EVIDENCE-STATEMENT class on how some of the definitions were written in RFC5912, (see DIGEST-ALGORITHM for one) especially with respect to the &AuxType/aux field.   E.g. would changes

s/&AuxType OPTIONAL/&AuxType OCTET STRING OPTIONAL/ 

and 

s/[AUX TYPE &AuxType IS &auxPresent]/[AUX [TYPE &AuxType] IS &auxPresent]/  

to restore the original intent be useful?

 

AFAICT, ParamOptions  for &auxPresent is just a way to carry implementation information, but can't actually be applied to the EvidenceStatement SEQUENCE definition.  But it makes me twitchy that &AuxType might not be set when instantiating the EvidenceStatement....  I'm actually surprised it compiled as is.

 

Thanks - Mike

 

On 5/5/2025 1:55 PM, Russ Housley wrote:

This compiles:

 

FooBarModule

DEFINITIONS IMPLICIT TAGS ::= BEGIN

 

EVIDENCE-STATEMENT ::= CLASS {

  &id          OBJECT IDENTIFIER UNIQUE,

  &Type,

  &auxPresent ParamOptions DEFAULT absent,

  &AuxType    OPTIONAL

} WITH SYNTAX {

  &Type IDENTIFIED BY &id

  [AUX TYPE &AuxType IS &auxPresent]

}

 

EvidenceStatementSet EVIDENCE-STATEMENT ::= {

   mikesEvidenceStatement | otherEvidenceStatement | tcgDiceAttestTPMCertify,

   ... }

 

EvidenceStatements ::= SEQUENCE SIZE (1..MAX) OF EvidenceStatement

 

EvidenceStatement ::= SEQUENCE {

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

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

   aux EVIDENCE-STATEMENT.&AuxType({EvidenceStatementSet}{@type}) OPTIONAL }

 

ParamOptions ::= ENUMERATED {

   required,         -- Parameters MUST be encoded in structure

   preferredPresent, -- Parameters SHOULD be encoded in structure

   preferredAbsent,  -- Parameters SHOULD NOT be encoded in structure

   absent,           -- Parameters MUST NOT be encoded in structure

   inheritable,      -- Parameters are inherited if not present

   optional,         -- Parameters MAY be encoded in the structure

   ... }

 

mikesEvidenceStatement EVIDENCE-STATEMENT ::= {

   MikesASN1Structure IDENTIFIED BY id-mikes-statement

   AUX TYPE MikesHint IS required }

 

id-mikes-statement OBJECT IDENTIFIER ::= { 1 1 1 1 1 1 }

 

MikesASN1Structure ::= OCTET STRING

 

MikesHint ::= IA5String

 

otherEvidenceStatement EVIDENCE-STATEMENT ::= {

   PrintableString IDENTIFIED BY id-other-statement }

 

id-other-statement OBJECT IDENTIFIER ::= { 2 2 2 2 2 2 }

 

tcgDiceAttestTPMCertify EVIDENCE-STATEMENT ::= {

   Tcg-attest-tpm-certify IDENTIFIED BY tcg-attest-tpm-certify 

   AUX TYPE Hint IS preferredPresent }

     

tcg OBJECT IDENTIFIER ::= { 2 23 133 }

 

tcg-kp-AIKCertificate OBJECT IDENTIFIER ::= { tcg 8 3 }

 

tcg-attest OBJECT IDENTIFIER ::= { tcg 20 }

 

tcg-attest-tpm-certify OBJECT IDENTIFIER ::= { tcg-attest 1 }

 

Tcg-attest-tpm-certify ::= SEQUENCE {

   tpmSAttest   OCTET STRING,

   signature    OCTET STRING,

   tpmTPublic   OCTET STRING OPTIONAL }

 

Hint ::= IA5String (FROM ("a".."z" | "A".."Z" | "0".."9" | ".:"))

 

END

 

 

 

Note: there are several problems in the TCG example that are correctesd in the above, including these typos:

 

s/id-tcg/tcg/

 

s/Tcg-csr-tpm-certify/Tcg-attest-tpm-certify/

 

Russ

 

 

_______________________________________________ Spasm mailing list -- [e-mail] To unsubscribe send an email to [e-mail]

 

 

 

Any email and files/attachments transmitted with it are intended solely for the use of the individual or entity to whom they are addressed. If this message has been sent to you in error, you must not copy, distribute or disclose of the information it contains. Please notify Entrust immediately and delete the message from your system.

_______________________________________________ Spasm mailing list -- [e-mail] To unsubscribe send an email to [e-mail]