Return-Path: 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 60F1126DDE20 for ; Fri, 9 May 2025 07:42:32 -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 lDvsd50jpXnT for ; Fri, 9 May 2025 07:42:30 -0700 (PDT) Received: from mail-qv1-xf2b.google.com (mail-qv1-xf2b.google.com [IPv6:2607:f8b0:4864:20::f2b]) (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 558E426DDE19 for ; Fri, 9 May 2025 07:42:30 -0700 (PDT) Received: by mail-qv1-xf2b.google.com with SMTP id 6a1803df08f44-6f53d271c4cso20430186d6.3 for ; Fri, 09 May 2025 07:42:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nthpermutation-com.20230601.gappssmtp.com; s=20230601; t=1746801750; x=1747406550; darn=ietf.org; h=in-reply-to:from:content-language:references:cc:to:subject :user-agent:mime-version:date:message-id:from:to:cc:subject:date :message-id:reply-to; bh=7NeHbbrNJLVSNBydzrepFdZeKnpw4b3E7yYdGfWLaKU=; b=vFshLJXG2ijvuaTNyecNr8UYFjTt5VX4Rwf0yhsT7+yb3T659fMdobob+vFCo8QtPv pDBBq/I7xB9aBwCFconYOvt9qATTCnjy8vQxHvioRNNnstDiLF+Jrp0Ck8MPFCfTNPad WaMpZNiojnUBxZOlBX4W5IReCjMZ5QJQF9WkheXQvAzOUbNCL+owgb3cxKe0tFl/aXP5 c6nDsIukc7w+jcUPpOSMuyXNilCTxJzwqTsZBE/vE49qvlWgI5zCr+rUu6QGYryBozzj VSWTzRpr2jwBOg/2oZTf+bFbV/p7HbOonaQeMHDnyyXwD4cM7fn2VzwmkghN0uIPfrZ7 G64g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1746801750; x=1747406550; h=in-reply-to:from:content-language:references:cc:to:subject :user-agent:mime-version:date:message-id:x-gm-message-state:from:to :cc:subject:date:message-id:reply-to; bh=7NeHbbrNJLVSNBydzrepFdZeKnpw4b3E7yYdGfWLaKU=; b=HzJKJVsX7kzqNCIhJus/c5pA2GTVKFWoHY/TCKQ05eUGpe2BORBATvhxCpRE7xRO3O 1d6BdKkRBeYJzFcMLXfZybEM2BXz53NYVb94KZt4d9IiLbJoDW99D9n3d6POG6BY6Z4S 3IrDl/qOP4ccJTEqwCvJapjpCouL0acB7AqPvBb2iHgGR099vWGcYi5VOQwT25Uud9J5 NQuVZiCoJPX0QN4CkPsDVmZo6iWhaqzl0qdpEVfa4DLyLo9lhj/9SGxGwj2C0LXFz3HN rAhViCrWXF/Gvw/6eY7u8iLx+VDYO6GVqETITunLnh9kzqxA3A683X81J0El8UgPFvD0 /HMg== X-Gm-Message-State: AOJu0Yx1WBV8pL9fRPuQe3q9mpdEmsdjHI2YDa7UqUCpt/KIZiO2sLTs BZ3U1+mHoiPJuOXADNh9L5ejBS3n/5vD+Hm5E/npxBz5HK65ZeW6nSma/tMswauG8rMmoe0p5J3 AndY= X-Gm-Gg: ASbGncsfmo3v5u//91piRpuUtGLVVlyXNKpc1W5WqouB/sglYMYw97H/WvB99PHKb3Y abpWHfzTXErHPu9UiKngKTwQryW0gdu3k9rLiGjrJltYIdzz5fUq/6okgFwwvDEKzmZ8EB7UjA7 uEVmgSJF8Fz25KZFvxvIZHonwAwAOyNmFoqv9Ep8hGyH97vLaC6pEWLIgdhSJaDi7H34txYm/pX M/X1PnyoyrvLT4b/CZyMl2hr9WmEktkzty2zH0HJ4XUK43IV4EeJoSCWOJwxC0v9DuQW9BbgcP0 XiNaaxl3tT/5Ls22a3n64wlmoZe76zx7vwgOb150D2cjVZOF5WtCx+XtT8+AnFdU/ULhQUUFY3h I+NS5Tw== X-Google-Smtp-Source: AGHT+IHaXipk3JQ4pMmKeHi23J5+lGrI8ji5dH8ELy+IfcpT6u22nE2M0iCMhCTA7e86cnNdVIeGog== X-Received: by 2002:ad4:5d63:0:b0:6eb:28e4:8518 with SMTP id 6a1803df08f44-6f6e48038e1mr61434206d6.34.1746801749627; Fri, 09 May 2025 07:42:29 -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-6f6e39f588asm14463416d6.49.2025.05.09.07.42.28 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 09 May 2025 07:42:28 -0700 (PDT) Content-Type: multipart/alternative; boundary="------------WBpmD6A24Sc1Oon9f1MtKpGe" Message-ID: Date: Fri, 9 May 2025 10:42:27 -0400 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird To: Carl Wallace , Russ Housley References: <07795EC6-BE7E-40D9-A860-B53A268D69CB@vigilsec.com> <9c438de1-bec9-4bb4-b1d0-589163cec00c@nthpermutation.com> <73616952-97F4-47A5-8C2F-55B966CE181F@vigilsec.com> <61A2DB74-C4D5-43B4-A36D-F7FF60938ECA@vigilsec.com> <0f3a638c-9027-4e07-a05c-0fe694d5da8b@nthpermutation.com> <990CA506-7234-43C9-A17B-D58F172438E8@vigilsec.com> <44e208db-fbff-4b0e-b3ef-375666224a18@nthpermutation.com> <6fc0d991-eb81-469d-af2d-f9b4f8a578fe@nthpermutation.com> <4B372042-E865-418A-A0A2-EEC68A712BF5@redhoundsoftware.com> <7F1D75DC-744F-4676-AF14-51D8836FEEBE@redhoundsoftware.com> Content-Language: en-US From: Michael StJohns In-Reply-To: <7F1D75DC-744F-4676-AF14-51D8836FEEBE@redhoundsoftware.com> X-Antivirus: Norton (VPS 250505-6, 5/5/2025), Outbound message X-Antivirus-Status: Clean Message-ID-Hash: PJLG4376EESBOWCK4JUMJ47SGAWGIHYD X-Message-ID-Hash: PJLG4376EESBOWCK4JUMJ47SGAWGIHYD 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: =?utf-8?q?=5Blamps=5D_Re=3A_WGLC_for_draft-ietf-lamps-csr-attestation-18?= List-Id: This is the mail list for the LAMPS Working Group Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: This is a multi-part message in MIME format. --------------WBpmD6A24Sc1Oon9f1MtKpGe Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Inline On 5/9/2025 10:22 AM, Carl Wallace wrote: > > Inline… > > *From: *Michael StJohns > *Date: *Friday, May 9, 2025 at 9:35 AM > *To: *Carl Wallace , Russ Housley > > *Cc: * > *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 --------------WBpmD6A24Sc1Oon9f1MtKpGe Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit
Inline

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

Inline…

 

From: Michael StJohns <msj@nthpermutation.com>
Date: Friday, May 9, 2025 at 9:35 AM
To: Carl Wallace <carl@redhoundsoftware.com>, Russ Housley <housley@vigilsec.com>
Cc: <spasm@ietf.org>
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


--------------WBpmD6A24Sc1Oon9f1MtKpGe--