[lamps] Re: [EXTERNAL] Re: WG Last Call for draft-ietf-lamps-csr-attestation-09

Michael StJohns <msj@nthpermutation.com> Thu, 23 May 2024 20:13 UTC

Return-Path: <msj@nthpermutation.com>
X-Original-To: spasm@ietfa.amsl.com
Delivered-To: spasm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F958C169439 for <spasm@ietfa.amsl.com>; Thu, 23 May 2024 13:13:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Level:
X-Spam-Status: No, score=-1.896 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, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=nthpermutation-com.20230601.gappssmtp.com
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KBh0iI2UFeqe for <spasm@ietfa.amsl.com>; Thu, 23 May 2024 13:12:54 -0700 (PDT)
Received: from mail-qk1-x734.google.com (mail-qk1-x734.google.com [IPv6:2607:f8b0:4864:20::734]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A634FC151995 for <spasm@ietf.org>; Thu, 23 May 2024 13:12:54 -0700 (PDT)
Received: by mail-qk1-x734.google.com with SMTP id af79cd13be357-792ce7a2025so120389585a.0 for <spasm@ietf.org>; Thu, 23 May 2024 13:12:54 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nthpermutation-com.20230601.gappssmtp.com; s=20230601; t=1716495173; x=1717099973; darn=ietf.org; h=in-reply-to:from:references:cc:to:content-language:subject :user-agent:mime-version:date:message-id:from:to:cc:subject:date :message-id:reply-to; bh=crBa/5pX2abLXkYTpGaUNTzcgKa/pZqpG6J3FOKpI0k=; b=xS1ysyzqjl25dKfw3xXYxtEaOmVbjb39bidwLT6KpJ6r3pKaF00lFIKPho6QehYMDW sIG9gN7cy+YKpF4z/DnaUDGgoZn8fB9nJCJ1vNYvF9winSidve42pDOBb0wyWjAFSsny eLp4wkKdl+smmrtkRyUGWv+1OoOlWfMAfYpb14IrCDxpLOLk10vAgQh78qr7zrUKgfka 2iN9hYlQNhrfl/Zgg/dG5lcGuQhwcqt1J3t6jr834vEAWHt3hFsQTl6iXrxm/wPXHF1O byWusrJCfjRhdboy3xQqNteVuNHG2j6V4z7fsZC2c7Dy6xfuV3Q7amKo1touf5L62xBP KSFw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1716495173; x=1717099973; h=in-reply-to:from:references:cc:to:content-language:subject :user-agent:mime-version:date:message-id:x-gm-message-state:from:to :cc:subject:date:message-id:reply-to; bh=crBa/5pX2abLXkYTpGaUNTzcgKa/pZqpG6J3FOKpI0k=; b=LxSj6ZgVtHs6hQmKNDYfkrBvVMuyfyDoXbcZEpaAoF5DSGQWLW6njbA2MJ8S/PHFtF s4uhrKO4YGjXtfaDmyQHGJB1Ie6DHJ6HKurPZH4YhDuYsuJqUYLBasMGd3bGIOVVqlKm aw/+AwtAyiEbevOsqmdfOhUirS2ohaA8vZnbN2g24BxT3j+UeRZYY3YIsBrS76ffIQsa 5uSsv2hx2g6UYXJ9rAEp1lp2e+ZqiZJnOFAKUrfftAZMp+s3woZKy0CphoJI9ei2HY5M kPNrXWBW6ogWdQUCDPMpvgn3wOsZpdzKbIF0816kQ82+WDrqSTiEdePsDEvNn5XV6++t EIkQ==
X-Forwarded-Encrypted: i=1; AJvYcCVArUKkfTgEqQ72D41nwfdfGcYcHRSLuzCW4ad5zNGIeIN0knamW8a91bBJAhxq34gyM+ZZB6sTKkpZEu+Eeg==
X-Gm-Message-State: AOJu0YxF+swfUQUKhYVr0g8WJuwcratt27pDgXjeoeXsC52qXSMoXdMz xeLpND+k7iJV6/elPst21e7CKSJE50d0xxyVjI2bd03ty/YB0xfUWLqP8yxyzqI=
X-Google-Smtp-Source: AGHT+IHVj68NAwELy056WPY8w9R+jh6FUmy61cSkc8ohpzplNE8gXBGkJglmhZ7GJTlNqrWM3vDDZg==
X-Received: by 2002:a05:620a:284a:b0:792:c478:3201 with SMTP id af79cd13be357-794ab079b78mr35407885a.26.1716495173042; Thu, 23 May 2024 13:12:53 -0700 (PDT)
Received: from [192.168.1.23] (pool-108-31-156-76.washdc.fios.verizon.net. [108.31.156.76]) by smtp.gmail.com with ESMTPSA id af79cd13be357-792bf27f78fsm1518245985a.30.2024.05.23.13.12.52 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 23 May 2024 13:12:52 -0700 (PDT)
Content-Type: multipart/alternative; boundary="------------iaZODTEbbwa7KmTQ20gE4W0L"
Message-ID: <ba36ef95-5656-4c1f-803f-3c011e0197fc@nthpermutation.com>
Date: Thu, 23 May 2024 16:12:52 -0400
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Content-Language: en-US
To: Russ Housley <housley@vigilsec.com>
References: <d83723fe-6033-43d4-b2c5-9dd9f5989893@nthpermutation.com> <9F6362A6-FB58-48A7-8AD6-9132758604D3@redhoundsoftware.com> <47e2986d-dcfe-4acc-aa18-a253c230ee49@nthpermutation.com> <BEDB38D1-0C5E-4EF9-A6EF-717747837F67@vigilsec.com>
From: Michael StJohns <msj@nthpermutation.com>
In-Reply-To: <BEDB38D1-0C5E-4EF9-A6EF-717747837F67@vigilsec.com>
Message-ID-Hash: JEYFB2S7NJD7NPLDYEWB4BXJYZGZXAFY
X-Message-ID-Hash: JEYFB2S7NJD7NPLDYEWB4BXJYZGZXAFY
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: Carl Wallace <carl@redhoundsoftware.com>, spasm@ietf.org
X-Mailman-Version: 3.3.9rc4
Precedence: list
Subject: [lamps] Re: [EXTERNAL] Re: WG Last Call for draft-ietf-lamps-csr-attestation-09
List-Id: This is the mail list for the LAMPS Working Group <spasm.ietf.org>
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>

On 5/23/2024 3:59 PM, Russ Housley wrote:
> Mike:
>
>> In my case, I deal with both ASN1 SIGNED objects and flat signed objects of various flavors.   If I see the [0] tag, I know I can continue the parsing of the structure without first looking up the meaning of the OID and figuring out what the meaning of the various bits are (Syntax parsing vs semantic assignment).  I can pass a parsed ASN1 tree structure to the validator/object creator associated with the OID rather than stopping after parsing the top level.
> The ASN.1 tools that I use do not allow processing as you describe.

Try doing this in limited memory on a smart card.  Deferring special 
processing (e.g. related to the OID) until as late as possible 
simplifies things immensely.

I've dealt with attestation from big to large over the last 10-12 years 
and mostly I don't have the opportunity to just call an external 
function to evaluate an attestation blob as seems to be the main model 
for this document. That said, I realize I've lost that argument a long 
time ago.  That had the unfortunate side effect of making this document 
mostly useless for the cases in which I've been involved.  So while I 
won't support its publication, I won't oppose it and I probably won't 
ever use it.

BTW - I think Carl and you are about a year late in bringing up this 
reformulation of CertChoices - the current form was discussed and pretty 
much agreed upon in the design team about that long ago or should have 
been changed at that point.  Either this document is ready for last call 
(and *shrug* it probably is) or its time to go back and reopen a lot 
more than just the CertChoices discussion.   Given that this was 
supposed to be done about 2 years ago... well.. obviously it's not 
really all that critical we actually issue this document anytime soon.

If instead you want to close out the design team, and move this document 
into the mainstream of Lamps for further discussion prior to doing a 
Last Call, that may actually be a better approach than continuing this 
last call.

Later, Mike