[lamps] Re: WGLC for draft-ietf-lamps-csr-attestation-18
Michael StJohns <msj@nthpermutation.com> Fri, 09 May 2025 11:53 UTC
Return-Path: <msj@nthpermutation.com>
X-Original-To: spasm@mail2.ietf.org
Delivered-To: spasm@mail2.ietf.org
Received: from localhost (localhost [127.0.0.1]) by mail2.ietf.org (Postfix) with ESMTP id 4B96026CBFBA for <spasm@mail2.ietf.org>; Fri, 9 May 2025 04:53:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at ietf.org
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no
Authentication-Results: mail2.ietf.org (amavisd-new); dkim=pass (2048-bit key) header.d=nthpermutation-com.20230601.gappssmtp.com
Received: from mail2.ietf.org ([166.84.6.31]) by localhost (mail2.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FwAeQq55hMeA for <spasm@mail2.ietf.org>; Fri, 9 May 2025 04:53:11 -0700 (PDT)
Received: from mail-qv1-xf32.google.com (mail-qv1-xf32.google.com [IPv6:2607:f8b0:4864:20::f32]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by mail2.ietf.org (Postfix) with ESMTPS id 8DD5026CBFB3 for <spasm@ietf.org>; Fri, 9 May 2025 04:53:11 -0700 (PDT)
Received: by mail-qv1-xf32.google.com with SMTP id 6a1803df08f44-6f54e4f2989so32331036d6.1 for <spasm@ietf.org>; Fri, 09 May 2025 04:53:11 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nthpermutation-com.20230601.gappssmtp.com; s=20230601; t=1746791591; x=1747396391; darn=ietf.org; h=in-reply-to:content-language:references:cc:to:from:subject :user-agent:mime-version:date:message-id:from:to:cc:subject:date :message-id:reply-to; bh=gdtkSNmXAAXPm3AclPhOUCemittmKVtS6UYoDc2tJmY=; b=Q2uIYIdrUjOx2ABZxu5knAAYAmNxWPDVjtWDnYQSTc7zhZrqrK/Gr07JpCagtvnrE/ yLVL+AqqXupdyolf2NlIRW7kyt+PMsJ8T2mVakxvO1DLzt8xYeIIpVTbr16XG+3Z7mBk MX2+/wh1IubmhSJ7l6077ZQvzGhhltxSVVfWubVg1rkGMcd9ZPt1rfW91kLRrI61TZzj /DOB3nIxK94TrIg0mFymKmq5fPgaS8fKs3kfB+fy6zfXrFGAFbeERzg34X+gELGMN8Pw cApXDArkDMnhGtopsqRQkJ3ndFrp4gUqFBVOXjh3juaKx4wkdm90ptBLtPAIcQ2HOwMG cQYQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1746791591; x=1747396391; h=in-reply-to:content-language:references:cc:to:from:subject :user-agent:mime-version:date:message-id:x-gm-message-state:from:to :cc:subject:date:message-id:reply-to; bh=gdtkSNmXAAXPm3AclPhOUCemittmKVtS6UYoDc2tJmY=; b=KGtYE9EbKCd58uHnv1miFLZe8AlghtSoH9elLCLNU2xra904yJtrsTCimL+jdH60K9 gV/lZeNt1hvgrjOgZxLaMfnOhkSjKi1FRFcgCwkS9jjaU05o3DD6yT3eX3c3z5g7eqGu BlamfN8955g8uOGmGi84fFhSgVz/ZO7VgX/L+vE/FiAELg5WnU2oFqIagtFicsTFQ4bo cOx/LAyyXcFcpHllz58Qo+rOUL0IeadkhDOJYW2wjuKnLBQg62igBYYfAS6YZG5A25zw VnI6QZwCxklhbamLLA3/tZiH9uIv6GRVd+pjpww+SvhJxmDT0sH7L8k4iZL6S6qvkGxC C1+w==
X-Gm-Message-State: AOJu0YyUtGLhkiU3zl3kk+0EdHszUfZiRGujp/jFyMBhUQ+o1q0T5ofx 3wBWlzb04lQ2n3CcA4zTztI0pgrfs2nSmOsG5pq0mzVMI444JuJALzck4BsE7x+DjvXIQWeLoy8 yBmQ=
X-Gm-Gg: ASbGncuY096ataysItiP+2nj94OjlbLJAceIzn1pMeiExpsqk6CmHV+5B1iuzIOsc2d X5kwzsXlqy7MZkdY+70j+qxToqpXtJNiwFZpDm+F+R0pWfRVdpxd9Yp7+8V+pcu39hH9aioQS8E j/ApVS1lvOluE3h04BWuYfJ9oq+heA3Ll00EDe1yI+fisvsAL3iWxGfEK1KXY0XdctGO+3lBugY H4C2Lh3G7IPiHJimKinXbB2pEWh0kaDsOneKzlBVs38K5R/dVW1SrBRgYcoEb/zcN6Ip09+KKUT npjF6jWZ++LEkkrSEZJhFOVIciIKg6gu6YD7wCcz/3/LcnZ0UgSXTX2U7MAevggvu9MkvrshKp0 KwoGOHw==
X-Google-Smtp-Source: AGHT+IH1GSeXMLF+D9P0isx+PsZqchrAdXv5Z7m2wsiuP4HGHd2XK0WIxwSC290C+SebJMKaQUl+Rw==
X-Received: by 2002:ad4:5ae2:0:b0:6f4:cdca:2a6e with SMTP id 6a1803df08f44-6f6e4858725mr47679936d6.45.1746791590823; Fri, 09 May 2025 04:53:10 -0700 (PDT)
Received: from [192.168.1.10] (pool-108-48-44-44.washdc.fios.verizon.net. [108.48.44.44]) by smtp.gmail.com with ESMTPSA id 6a1803df08f44-6f6e3a60eaesm12435476d6.122.2025.05.09.04.53.09 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 09 May 2025 04:53:10 -0700 (PDT)
Content-Type: multipart/alternative; boundary="------------tGv0mfV6O5Kba4O79m7Jcv66"
Message-ID: <6fc0d991-eb81-469d-af2d-f9b4f8a578fe@nthpermutation.com>
Date: Fri, 09 May 2025 07:53:08 -0400
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
From: Michael StJohns <msj@nthpermutation.com>
To: Carl Wallace <carl@redhoundsoftware.com>, Russ Housley <housley@vigilsec.com>
References: <07795EC6-BE7E-40D9-A860-B53A268D69CB@vigilsec.com> <9c438de1-bec9-4bb4-b1d0-589163cec00c@nthpermutation.com> <73616952-97F4-47A5-8C2F-55B966CE181F@vigilsec.com> <CANeU+ZCd9Gn6BTn+qFQD=-9LnLN=sdzVOrjhm3hZ-a2nV372Vg@mail.gmail.com> <be09bb1c-ea20-46ac-87e5-f1ddff20ccbf@nthpermutation.com> <61A2DB74-C4D5-43B4-A36D-F7FF60938ECA@vigilsec.com> <0f3a638c-9027-4e07-a05c-0fe694d5da8b@nthpermutation.com> <990CA506-7234-43C9-A17B-D58F172438E8@vigilsec.com> <b4070217-b202-4316-9cc6-da65a71b9b06@nthpermutation.com> <C739F158-05E2-4628-BBAC-61F2757DF268@redhoundsoftware.com> <44e208db-fbff-4b0e-b3ef-375666224a18@nthpermutation.com>
Content-Language: en-US
In-Reply-To: <44e208db-fbff-4b0e-b3ef-375666224a18@nthpermutation.com>
X-Antivirus: Norton (VPS 250505-6, 5/5/2025), Outbound message
X-Antivirus-Status: Clean
Message-ID-Hash: 7PRN7S5KSSIZZ33NAQCBLN2B7UUZU5Q4
X-Message-ID-Hash: 7PRN7S5KSSIZZ33NAQCBLN2B7UUZU5Q4
X-MailFrom: msj@nthpermutation.com
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-spasm.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
CC: spasm@ietf.org
X-Mailman-Version: 3.3.9rc6
Precedence: list
Subject: [lamps] Re: WGLC for draft-ietf-lamps-csr-attestation-18
List-Id: This is the mail list for the LAMPS Working Group <spasm.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/spasm/z-gNT2mnWN2N6u_ECkqJDpH975Y>
List-Archive: <https://mailarchive.ietf.org/arch/browse/spasm>
List-Help: <mailto:spasm-request@ietf.org?subject=help>
List-Owner: <mailto:spasm-owner@ietf.org>
List-Post: <mailto:spasm@ietf.org>
List-Subscribe: <mailto:spasm-join@ietf.org>
List-Unsubscribe: <mailto:spasm-leave@ietf.org>
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 <msj@nthpermutation.com>
>> *Date: *Monday, May 5, 2025 at 4:02 PM
>> *To: *Russ Housley <housley@vigilsec.com>
>> *Cc: *<spasm@ietf.org>
>> *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
>> <msj@nthpermutation.com> <mailto:msj@nthpermutation.com> 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 --
>> spasm@ietf.org To unsubscribe send an email to spasm-leave@ietf.org
>>
>
- [lamps] WGLC for draft-ietf-lamps-csr-attestation… Russ Housley
- [lamps] Re: WGLC for draft-ietf-lamps-csr-attesta… Michael StJohns
- [lamps] Re: WGLC for draft-ietf-lamps-csr-attesta… Russ Housley
- [lamps] Re: WGLC for draft-ietf-lamps-csr-attesta… StJohns, Michael
- [lamps] Re: WGLC for draft-ietf-lamps-csr-attesta… Michael StJohns
- [lamps] Re: WGLC for draft-ietf-lamps-csr-attesta… Russ Housley
- [lamps] Re: WGLC for draft-ietf-lamps-csr-attesta… Michael StJohns
- [lamps] Re: WGLC for draft-ietf-lamps-csr-attesta… Russ Housley
- [lamps] Re: WGLC for draft-ietf-lamps-csr-attesta… Michael StJohns
- [lamps] Re: WGLC for draft-ietf-lamps-csr-attesta… Carl Wallace
- [lamps] Re: WGLC for draft-ietf-lamps-csr-attesta… Michael StJohns
- [lamps] Re: WGLC for draft-ietf-lamps-csr-attesta… Michael StJohns
- [lamps] Re: WGLC for draft-ietf-lamps-csr-attesta… Carl Wallace
- [lamps] Re: WGLC for draft-ietf-lamps-csr-attesta… Michael StJohns
- [lamps] Re: WGLC for draft-ietf-lamps-csr-attesta… Carl Wallace
- [lamps] Re: WGLC for draft-ietf-lamps-csr-attesta… Michael StJohns
- [lamps] Re: WGLC for draft-ietf-lamps-csr-attesta… Carl Wallace
- [lamps] Re: WGLC for draft-ietf-lamps-csr-attesta… StJohns, Michael
- [lamps] Re: [EXTERNAL] Re: WGLC for draft-ietf-la… Mike Ounsworth
- [lamps] Re: WGLC for draft-ietf-lamps-csr-attesta… Carl Wallace
- [lamps] Re: WGLC for draft-ietf-lamps-csr-attesta… Mike Ounsworth
- [lamps] Re: WGLC for draft-ietf-lamps-csr-attesta… Carl Wallace
- [lamps] Re: WGLC for draft-ietf-lamps-csr-attesta… Mike Ounsworth
- [lamps] Re: WGLC for draft-ietf-lamps-csr-attesta… Carl Wallace
- [lamps] Re: WGLC for draft-ietf-lamps-csr-attesta… Michael StJohns
- [lamps] Re: WGLC for draft-ietf-lamps-csr-attesta… Michael StJohns
- [lamps] Re: WGLC for draft-ietf-lamps-csr-attesta… Michael StJohns
- [lamps] Re: WGLC for draft-ietf-lamps-csr-attesta… Russ Housley
- [lamps] Re: WGLC for draft-ietf-lamps-csr-attesta… StJohns, Michael
- [lamps] Re: WGLC for draft-ietf-lamps-csr-attesta… Russ Housley
- [lamps] Re: WGLC for draft-ietf-lamps-csr-attesta… Russ Housley