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

[Michael StJohns <[e-mail]>]

Inline

On 5/9/2025 10:22 AM, Carl Wallace wrote:
>
> 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?
>

Carl - both of these are valid:

EvidenceStatement ::= SEQUENCE {

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

    stmt EVIDENCE-STATEMENT.&ESStmtType({EvidenceStatementSet}{@oid})

  }

and

EvidenceStatement ::= SEQUENCE {

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

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

}


Why would you think that the compound version (with both aux and stmt) 
wouldn't be?  @oid is a reference to the oid field value in the 
instantiated structure - it can be used more than once.


> 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).
>
The identifier for &AuxType is the same as the identifier for 
&ESStmtType - the are both &esTypeId.  The OID value of &esTypeId is a 
lookup key to multiple tables.  Feel free to read the various X.68x 
documents for an explanation.

> [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.
>
Again - evidence?  And the AuxType *is* in the encoding as you mean it.  
It's the type of the aux field...  it's exactly as present as the type 
of the stmt field....

I can't quite figure out how you're looking at this to come to these 
conclusions, but your conclusions aren't really supported by the way 
ASN1 works.

Later, Mike