IETF Logo Mail Archive

[Rats] Re: Hint Discussion in CSR Attestation Draft

Michael Richardson <mcr+ietf@sandelman.ca> Sun, 23 June 2024 20:19 UTC

Return-Path: <mcr+ietf@sandelman.ca>
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 0907CC14F6BA; Sun, 23 Jun 2024 13:19:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.106
X-Spam-Level:
X-Spam-Status: No, score=-2.106 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, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=sandelman.ca
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 4HSjiK_UDG9i; Sun, 23 Jun 2024 13:18:58 -0700 (PDT)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B00E8C14F619; Sun, 23 Jun 2024 13:18:58 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 3BC9B3898B; Sun, 23 Jun 2024 16:18:57 -0400 (EDT)
Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id KgpwiW4m9G5J; Sun, 23 Jun 2024 16:18:52 -0400 (EDT)
Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 0223A38988; Sun, 23 Jun 2024 16:18:51 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sandelman.ca; s=mail; t=1719173932; bh=sgYiQa3xFrF9qcgtJr6+MMFfI3n6/P+t8FpSz+jpDsU=; h=From:to:Subject:In-Reply-To:References:Date:From; b=rQITqkVS7Mgrvx17UM5V8ZGpBFt8ForA26N01UgwVBdheEU8SHM+OcUc+lxinOPrb C6fX4/ki6PD8hzyIwn6I594vAesrFt5zyARrclRUo5PEQOpRuG5Qqv0yQgDmWEhUoH i1xP8PgSyPog9T9evQNjXmjW9AMc9Q/9qie3K2pnVRpD2jlPdhy9OrxK5cdW7IsCrl zf6GslakJnlrgRo2WL89Z1EWyS20ti6moGnJuY7FkAdlLqZu0pqmJldGcNcEsHDO1A rSW3aSIWYkbaqigl9m/Rs9w5Gupk8tR3GgJx9qzih0nKKcB8ve2sGGqA8oKgHmFzG6 IPSxyliAUnyOw==
Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id EF49524F; Sun, 23 Jun 2024 16:18:51 -0400 (EDT)
From: Michael Richardson <mcr+ietf@sandelman.ca>
to: Henk Birkholz <henk.birkholz@ietf.contact>, "Tschofenig, Hannes" <hannes.tschofenig=40siemens.com@dmarc.ietf.org>, "spasm@ietf.org" <spasm@ietf.org>, rats <rats@ietf.org>
In-Reply-To: <11102.1719170889@obiwan.sandelman.ca>
References: <AS8PR10MB742727BFEC71CB78468FB0E7EECD2@AS8PR10MB7427.EURPRD10.PROD.OUTLOOK.COM> <0145e095-e684-d2ee-58d5-41aee54a4b3b@ietf.contact> <2627.1718830718@obiwan.sandelman.ca> <30ebbbcc-0fe5-ff91-0fe8-f27743e2b330@ietf.contact> <11102.1719170889@obiwan.sandelman.ca>
X-Mailer: MH-E 8.6+git; nmh 1.8+dev; GNU Emacs 28.2
X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0;<'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m<nPbLgmtKK-5dC@#:k
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg="pgp-sha512"; protocol="application/pgp-signature"
Date: Sun, 23 Jun 2024 16:18:51 -0400
Message-ID: <23087.1719173931@obiwan.sandelman.ca>
Message-ID-Hash: BTL7HHB7CKAJ55EF2YI5W6PUR5OAVYBW
X-Message-ID-Hash: BTL7HHB7CKAJ55EF2YI5W6PUR5OAVYBW
X-MailFrom: mcr+ietf@sandelman.ca
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-rats.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
X-Mailman-Version: 3.3.9rc4
Precedence: list
Subject: [Rats] Re: Hint Discussion in CSR Attestation Draft
List-Id: Remote ATtestation procedureS <rats.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/rats/zMW1ncmykS6YUtlaKxddylsgrv8>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rats>
List-Help: <mailto:rats-request@ietf.org?subject=help>
List-Owner: <mailto:rats-owner@ietf.org>
List-Post: <mailto:rats@ietf.org>
List-Subscribe: <mailto:rats-join@ietf.org>
List-Unsubscribe: <mailto:rats-leave@ietf.org>

Michael Richardson <mcr+ietf@sandelman.ca> wrote:
    > And it probably could make sense for some environments where MUD is
    > already used, such as with draft-itef-suit-mud!  I feel that we are
    > lacking a few pieces on the IETF "standard" MUD/SUIT/RATS ecosystem:

To be clear: this is "normal" remote attestation, dealing the state of the
device, not CSR-Attestation of where the private key is stored.

Yeah, they could be combined, and for instance, the BRSKI (RFC8995) flow that
leads into RFC7030 EST is an example where one might want CSR attestation.
But, in that flow, the Verifier is probably also the MASA, and the hint to
the MASA is in the IDevID.  One can also have a MUD URL in the IDevID, and
that's the only case I see where a pointer to the Verifier would work.

But, that's not the case that LAMPS (and CABforum) cares about today.

I think it would be useful to perhaps plan a side-meeting on continuous
assurance of IoT devices.  Maybe that's an IETF121 activity.

--
Michael Richardson <mcr+IETF@sandelman.ca>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide

v2.27.8 | Report a Bug | By Email | System Status