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

[Michael StJohns <[e-mail]>]

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.

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.

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.

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]>
>         <mailto:[e-mail]>
>         *Date: *Monday, May 5, 2025 at 4:02 PM
>         *To: *Russ Housley <[e-mail]>
>         <mailto:[e-mail]>
>         *Cc: *<[e-mail]> <mailto:[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]>
>                 <mailto:[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]
>