Re: [Rats] draft-ounsworth-rats-x509-evidence-00

Carl Wallace <carl@redhoundsoftware.com> Thu, 09 November 2023 15:40 UTC

Return-Path: <carl@redhoundsoftware.com>
X-Original-To: rats@ietfa.amsl.com
Delivered-To: rats@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 27CEBC18E552 for <rats@ietfa.amsl.com>; Thu, 9 Nov 2023 07:40:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.606
X-Spam-Level:
X-Spam-Status: No, score=-1.606 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, GB_ABOUTYOU=0.5, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=redhoundsoftware.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 YAzHgK764GAr for <rats@ietfa.amsl.com>; Thu, 9 Nov 2023 07:40:23 -0800 (PST)
Received: from mail-vk1-xa29.google.com (mail-vk1-xa29.google.com [IPv6:2607:f8b0:4864:20::a29]) (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 D1030C17C51F for <rats@ietf.org>; Thu, 9 Nov 2023 07:40:23 -0800 (PST)
Received: by mail-vk1-xa29.google.com with SMTP id 71dfb90a1353d-4ac0d137835so414531e0c.2 for <rats@ietf.org>; Thu, 09 Nov 2023 07:40:23 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhoundsoftware.com; s=google; t=1699544422; x=1700149222; darn=ietf.org; h=content-transfer-encoding:mime-version:in-reply-to:references :thread-topic:message-id:to:from:subject:date:user-agent:from:to:cc :subject:date:message-id:reply-to; bh=eoMMSLR5vl7Yjx9MZX8SY9Ngt96KkFtr8iidqV65NXY=; b=CxbIBX9lHKCCnevTtUuaiua7mawWd3AqBD5jfE/VoeB8ZYgp6gahg2qjEqrh4uYEwQ ZxUKe+XG8xRZFZvr7MOw50BSFWT5tN1H1qK2LWWhWra34xyL+0o33abxLw7tvUwqisF9 ZcUu2PNNzZBat6X1QCdYYwxFh27zSm7VrJLpk=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1699544422; x=1700149222; h=content-transfer-encoding:mime-version:in-reply-to:references :thread-topic:message-id:to:from:subject:date:user-agent :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=eoMMSLR5vl7Yjx9MZX8SY9Ngt96KkFtr8iidqV65NXY=; b=rkRop2auaEwSnqwZHkEu2d5kry4E1AweTX6qj0A9QCMlLAJarcuax2nHgzOFIdopER 1jjBXHcYNUXekTX6cO7w23Youh3nQEQ1ad8tXw2Xoy/1ltMDYw6kuKIbQDUpwJY9MK+5 vBk+IbzgmNcAhZYj2ce8wiStDY8OBsHhTVM6xq7dOTqcV781oICS7p/xNkEqVRjn+Nyz EcMztPUoCjpY5XO+yS7kge4dasPQ/DMrfv/U/x+y3+wEDolw5zImTnphEeCELCQ7qndf mwi3cP285LG6JtGZA1GAkuBXD9Zoe9V+pgNlnPzEz3pewQj3mwHTQWyS5jkcI0UN1WFC Wv3Q==
X-Gm-Message-State: AOJu0YyurQRmWPia/Lus1X8YIoZ0GmANdbXNcjVOviCcGnqXy6ddCx5I TqNgoHy4NfQySKhHgfHd2Yz1AE1hsoqaOgsMc+s=
X-Google-Smtp-Source: AGHT+IH3X3Nn8l/O5gBbVyXNetb8fm9Js6/5C9wH99XHebMgXVJfiPJKOKuiGRN6zaD6I3WQfLFGcQ==
X-Received: by 2002:a67:e30f:0:b0:45f:2a26:aa86 with SMTP id j15-20020a67e30f000000b0045f2a26aa86mr5547763vsf.25.1699544422314; Thu, 09 Nov 2023 07:40:22 -0800 (PST)
Received: from [192.168.2.16] (pool-96-255-232-167.washdc.fios.verizon.net. [96.255.232.167]) by smtp.gmail.com with ESMTPSA id ne18-20020a056214425200b0065b21f1b687sm2159709qvb.80.2023.11.09.07.40.21 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 09 Nov 2023 07:40:21 -0800 (PST)
User-Agent: Microsoft-MacOutlook/16.78.23102801
Date: Thu, 09 Nov 2023 10:40:21 -0500
From: Carl Wallace <carl@redhoundsoftware.com>
To: hannes.tschofenig@gmx.net, 'Henk Birkholz' <henk.birkholz@sit.fraunhofer.de>, rats@ietf.org
Message-ID: <64C20740-A63E-45D0-A8C4-59F8AD5E1D09@redhoundsoftware.com>
Thread-Topic: [Rats] draft-ounsworth-rats-x509-evidence-00
References: <6FCC00F5-1FAE-4CCD-9ED2-DA2BA923E7F7@island-resort.com> <011801da130d$74579390$5d06bab0$@gmx.net> <66c6191b-c393-69da-a849-f44da369917a@sit.fraunhofer.de> <7DC2D9E1-F052-48A1-B5A8-978D52275EE5@redhoundsoftware.com> <01e001da131a$a8c7ba30$fa572e90$@gmx.net>
In-Reply-To: <01e001da131a$a8c7ba30$fa572e90$@gmx.net>
Mime-version: 1.0
Content-type: text/plain; charset="UTF-8"
Content-transfer-encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/rats/OHnCc7QClN-3Fbi5KycZ7MCR5dw>
Subject: Re: [Rats] draft-ounsworth-rats-x509-evidence-00
X-BeenThere: rats@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Remote ATtestation procedureS <rats.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rats>, <mailto:rats-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rats/>
List-Post: <mailto:rats@ietf.org>
List-Help: <mailto:rats-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rats>, <mailto:rats-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 09 Nov 2023 15:40:28 -0000

Inline...

On 11/9/23, 9:40 AM, "hannes.tschofenig@gmx.net <mailto:hannes.tschofenig@gmx.net>" <hannes.tschofenig@gmx.net <mailto:hannes.tschofenig@gmx.net>> wrote:


Hi Carl, 


A few responses below:


* The use of CBOR/COSE in SUIT: At the start of the SUIT working group the participants expressed a strong preference to use CBOR/COSE and didn't want to use ASN.1/CMS. Brendan and I had written a draft that used ASN.1, which was inspired by work Russ did. It happens that work being proposed does not align with the expectations of the group. I remember Henk and Carsten being vocal proponents of CBOR & COSE at that time. Was it a good idea to use CBOR/COSE instead of ASN.1/CMS? Now that the standardization and implementation work is almost finished it is a bit too late to ask this question again. 

[CW] The question was not whether or not to reopen that question but whether or not the ASN.1 prohibition in that case should apply here. We need to belabor this given there is broad support for doing ASN.1 here. I would not personally elect to define new ASN.1 for this particular purpose, but don't object to the adopting the draft.

* Do we want to provide claim definitions in ASN.1 format (as we do in the draft)? That was our understanding from the design team discussions.

[CW] I have provided commentary on the claims that are in the draft (and how they differ with EAT semantics). I have no new claims to contribute personally but could review/contribute ASN.1 definitions for existing claims.

* Should we keep the definition of the CBOR/COSE claim definitions in sync with the ASN.1 format? I believe there is value in doing so. There does not seem to be anything wrong with the semantics of the claims in EAT. We have received feedback already for better alignment since we have introduced a few bugs in the -00 submission.

[CW] Good.

* A question you did not ask was: Should all claims in EAT also be described in an ASN.1 format? Currently the draft only contains a subset of the claims. I have been asking myself the same question. It is somewhat likely that sooner or later all claims defined in EAT will need to be available in ASN.1 format.

[CW] I thought about that question, and it was under the (roughly). I was mostly getting more at semantics, registries, etc. There are definitely some claims in EAT that I have a hard time seeing any reason to replicate in ASN.1 (i.e., things like nested EATs). I could also see where some key-centric claims may be possible and make sense in the X.509 context that would not be general purpose. 

Ciao
Hannes


-----Original Message-----
From: RATS <rats-bounces@ietf.org <mailto:rats-bounces@ietf.org>> On Behalf Of Carl Wallace
Sent: Donnerstag, 9. November 2023 14:45
To: Henk Birkholz <henk.birkholz@sit.fraunhofer.de <mailto:henk.birkholz@sit.fraunhofer.de>>; rats@ietf.org <mailto:rats@ietf.org>
Subject: Re: [Rats] draft-ounsworth-rats-x509-evidence-00




On 11/9/23, 8:09 AM, "RATS on behalf of Henk Birkholz" <rats-bounces@ietf.org <mailto:rats-bounces@ietf.org> <mailto:rats-bounces@ietf.org <mailto:rats-bounces@ietf.org>> on behalf of henk.birkholz@sit.fraunhofer.de <mailto:henk.birkholz@sit.fraunhofer.de> <mailto:henk.birkholz@sit.fraunhofer.de <mailto:henk.birkholz@sit.fraunhofer.de>>> wrote:




I think this discussion is mood as was pointed out in the meeting already. Please see:




https://www.rfc-editor.org/rfc/rfc9334.html#figure-9 <https://www.rfc-editor.org/rfc/rfc9334.html#figure-9> <https://www.rfc-editor.org/rfc/rfc9334.html#figure-9> <https://www.rfc-editor.org/rfc/rfc9334.html#figure-9&gt;>


[CW] I don't think that diagram renders this discussion moot. X.509 certificate-based attestations have existed since before RATS (and before we called attestation evidence). There's not even much question about potential for including claims in an X.509 certificate within current RATS documents (see section C.3 of EAT). I think the questions are: 1) do we want to provide ASN.1 definitions for claims and 2) do we want to keep claim definitions (roughly) in sync across ASN.1/CBOR/JSON. Re: 1), there's seems to be general acceptance of defining claims in ASN.1 for the most part (though no one really answered Brendan's question regarding why ASN.1 was disallowed for SUIT but is allowed here). Question 2) needs some more discussion. There was an exchange between Mike and Laurence during the presentation yesterday that highlights a potential difference of opinion between I-D author(s) and participants in the working group that could impact the adoption question.


On 09.11.23 14:05, hannes.tschofenig@gmx.net <mailto:hannes.tschofenig@gmx.net> <mailto:hannes.tschofenig@gmx.net <mailto:hannes.tschofenig@gmx.net>> wrote:
> Hi Laurence,
> 
> The charter says:
> 
> “
> 
> Standardize data models that implement and secure the defined 
> information model (e.g., CBOR Web Token structures [RFC8392 
> <https://datatracker.ietf.org/doc/rfc8392/> <https://datatracker.ietf.org/doc/rfc8392/&gt;> <https://datatracker.ietf.org/doc/rfc8392/&gt;> <https://datatracker.ietf.org/doc/rfc8392/&amp;gt;&gt;>], JSON Web Token structures 
> [RFC7519 <https://datatracker.ietf.org/doc/rfc7519/> <https://datatracker.ietf.org/doc/rfc7519/&gt;> <https://datatracker.ietf.org/doc/rfc7519/&gt;> <https://datatracker.ietf.org/doc/rfc7519/&amp;gt;&gt;>]).
> 
> “
> 
> CWT and JWT are mentioned as examples. The group already works on 
> another evidence format, namely the TPM-based stuff.
> 
> I would say that the document fits nicely within the scope of the charter.
> 
> Regarding the document split. I am open to discussions about your 
> suggestion, which assumes adoption in the group.
> 
> Ciao
> 
> Hannes
> 
> *From:*RATS <rats-bounces@ietf.org <mailto:rats-bounces@ietf.org> <mailto:rats-bounces@ietf.org <mailto:rats-bounces@ietf.org>>> *On Behalf Of *lgl island-resort.com
> *Sent:* Donnerstag, 9. November 2023 13:59
> *To:* rats <rats@ietf.org <mailto:rats@ietf.org> <mailto:rats@ietf.org <mailto:rats@ietf.org>>>
> *Subject:* [Rats] draft-ounsworth-rats-x509-evidence-00
> 
> I think it might be better to split this into two drafts.
> 
> First, define how to put CWT/JWT claims into ASN.1 and make an X.509
> attestation token.
> 
> Second, define the FIPS and CC status claims for CBOR, JSON and ASN.1.
> 
> I wish we didn’t have to do the first, but understand that we might. 
> Note that the RATS charter says we work on CBOR and JSON. There was a 
> little discussion about ASN.1 back in the early days and we certainly 
> put it off back then. There was also YANG discussion. Search the RATS 
> mail archive for ASN.1.
> 
> I’m much more interested in the FIPS and CC status claims. I would like 
> to define them for CBOR, JSON and ASN.1. If they are booleans this is 
> trivial. The would get registered in the CWT and JWT IANA registries.
> 
> One of the reasons I’d like to define them for CBOR and JSON is so 
> there’s a known and accepted way to translate their ASN.1 claims into JSON.
> 
> Also, the X.509 definition should be for Attestation Results as well as 
> Evidence. There’s no reason to restrict it and there’s no work to allow 
> use as Attestation Results.
> 
> LL
> 
> (sent incorrectly the first time only to the rats-chairs; meant it for 
> the list)
> 
> 
> _______________________________________________
> RATS mailing list
> RATS@ietf.org <mailto:RATS@ietf.org> <mailto:RATS@ietf.org <mailto:RATS@ietf.org>>
> https://www.ietf.org/mailman/listinfo/rats <https://www.ietf.org/mailman/listinfo/rats> <https://www.ietf.org/mailman/listinfo/rats> <https://www.ietf.org/mailman/listinfo/rats&gt;>




_______________________________________________
RATS mailing list
RATS@ietf.org <mailto:RATS@ietf.org> <mailto:RATS@ietf.org <mailto:RATS@ietf.org>>
https://www.ietf.org/mailman/listinfo/rats <https://www.ietf.org/mailman/listinfo/rats> <https://www.ietf.org/mailman/listinfo/rats> <https://www.ietf.org/mailman/listinfo/rats&gt;>








_______________________________________________
RATS mailing list
RATS@ietf.org <mailto:RATS@ietf.org>
https://www.ietf.org/mailman/listinfo/rats <https://www.ietf.org/mailman/listinfo/rats>