Re: [Rats] CoTS and CoRIM

Carl Wallace <carl@redhoundsoftware.com> Thu, 14 December 2023 14:32 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 7B531C14F60F for <rats@ietfa.amsl.com>; Thu, 14 Dec 2023 06:32:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.104
X-Spam-Level:
X-Spam-Status: No, score=-2.104 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, HTML_MESSAGE=0.001, 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_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 (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 6Z7VVeOIr0oX for <rats@ietfa.amsl.com>; Thu, 14 Dec 2023 06:32:48 -0800 (PST)
Received: from mail-qk1-x730.google.com (mail-qk1-x730.google.com [IPv6:2607:f8b0:4864:20::730]) (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 DDC39C14F5FA for <rats@ietf.org>; Thu, 14 Dec 2023 06:32:47 -0800 (PST)
Received: by mail-qk1-x730.google.com with SMTP id af79cd13be357-77f35b70944so492742185a.0 for <rats@ietf.org>; Thu, 14 Dec 2023 06:32:47 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhoundsoftware.com; s=google; t=1702564366; x=1703169166; darn=ietf.org; h=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=XLhWTpGdvVmo5Jj7IH/WDvdqKQ0J/Z88SPFn7V1JtRo=; b=k2PH1ro9aD3hPmhKlIBBcuBdmCxoTArRN8ebqZSLTmPJ81lmWPIBtMYYGgG+6LU3CP Aq1jr7ZMi5uCh9flSpewFC5zkAO5j0tCgampTSpiHpDy1XLlrUdvQNTxqFnjvH8kmMPh r6CEAU+IiJaasdKkkcuqYf96xhpo61DBufh0M=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1702564366; x=1703169166; h=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=XLhWTpGdvVmo5Jj7IH/WDvdqKQ0J/Z88SPFn7V1JtRo=; b=sCBWY17ztg1jOhGpmHURwnqhqdpotiVD9MsIYjvZLp41c/XsPHQha6+axsl0AhMsqn ZxwK+Uwizo/+BRZW74UWkaW1NhMGGabBlT9VDHsUXkAuP9c/OUpLe0k7yx8VWfot9c2K oyZ9jTshp1j+hR/e4irmeqywQEUSZkhuN6Md8Ul0gtiV8NMY8ePWleHMj0/KzhHy6Q9q /qzPO2U1t2oHhp/yHcWjOBbz20NzFqGbWIlE1riwb+oWYLi3lVwPEGz92gtR2r8D0Pc0 5qOkl6esONqWjtn0nFgJsvs3KHn496elEIN4gephb7YxU4JxrF/2iJ2AqX1o4OXJ2wge hNMQ==
X-Gm-Message-State: AOJu0YwcH4OY0Z4INiHrUPPSSQpW1arLqVDRYY2N4ml2JpA1AEzA9k7L ZPTxehOrY2OwIH+o6AEyMgnKlHXZx4tFvQF4RMU=
X-Google-Smtp-Source: AGHT+IE8Th9LDc9v/JRXdlPZy5KX+kQWNUN82YJMML40iRg66YGlhe1LUzcENHigUiPlyl0CKfflww==
X-Received: by 2002:ae9:f715:0:b0:77f:4ca9:bc2f with SMTP id s21-20020ae9f715000000b0077f4ca9bc2fmr11029895qkg.126.1702564366242; Thu, 14 Dec 2023 06:32:46 -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 bl10-20020a05620a1a8a00b0077d8fdc7e84sm5329967qkb.5.2023.12.14.06.32.45 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 14 Dec 2023 06:32:45 -0800 (PST)
User-Agent: Microsoft-MacOutlook/16.80.23121017
Date: Thu, 14 Dec 2023 09:32:44 -0500
From: Carl Wallace <carl@redhoundsoftware.com>
To: hannes.tschofenig=40gmx.net@dmarc.ietf.org, 'Yogesh Deshpande' <Yogesh.Deshpande@arm.com>, "'muhammad_usama.sardar'" <muhammad_usama.sardar@tu-dresden.de>, rats@ietf.org
Message-ID: <738FB73C-885D-49CC-950E-953099CAA11B@redhoundsoftware.com>
Thread-Topic: [Rats] CoTS and CoRIM
References: <005701da2e02$6acec900$406c5b00$@gmx.net> <84e6047b-b87b-4053-8e5a-fb2c8347defc@tu-dresden.de> <AM6PR08MB43257B9CB8ECD1BF6768D2138E8CA@AM6PR08MB4325.eurprd08.prod.outlook.com> <013001da2e8d$bf3c08a0$3db419e0$@gmx.net>
In-Reply-To: <013001da2e8d$bf3c08a0$3db419e0$@gmx.net>
Mime-version: 1.0
Content-type: multipart/alternative; boundary="B_3785391165_3966852360"
Archived-At: <https://mailarchive.ietf.org/arch/msg/rats/npJRMjW_gWLoQlDu3ogEIVUU-QE>
Subject: Re: [Rats] CoTS and CoRIM
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, 14 Dec 2023 14:32:52 -0000

Inline…

 

From: RATS <rats-bounces@ietf.org> on behalf of <hannes.tschofenig=40gmx.net@dmarc.ietf.org>
Date: Thursday, December 14, 2023 at 8:02 AM
To: 'Yogesh Deshpande' <Yogesh.Deshpande@arm.com>, "'muhammad_usama.sardar'" <muhammad_usama.sardar@tu-dresden.de>, <rats@ietf.org>
Subject: Re: [Rats] CoTS and CoRIM

 

Thanks for the quick response, Yogesh. 

 

Two points:

 
The reason why I believe that the trust anchor functionality should be part of CoRIM is that it is a core feature rather than an extension. I understand that there is some history about how these documents came into existence but this should not prevent us from doing the “right” thing.
[CW] I agree trust anchor management is a core functionality. The reason it was written as an extension initially is that it didn’t quite fit with any of the existing CoRIM mechanisms (there were some discussions about trying to use existing means but the extension approach was elected). Merging may be OK. That CoRIMs are signed and the CoTS is used to verify it would need to be addressed but this is not a showstopper.

 
Using trust anchors under the umbrella of endorsements makes sense to me. This needs to be more clearly articulated in the documents though.
[CW] Trust anchors are used to verify endorsements but generally don’t directly “vouch for the integrity of the device's various capabilities.” I don’t think TAs are endorsements (but don’t want to debate that if that is the best label from the architecture document to use).

 

A word about the process: Decisions about the directions the document take should be made on the mailing list rather than in private meetings. The chairs should be more strict about this. 

[CW] I have no idea what you are referring to here but there has been nothing in the CoTS history to my knowledge that was not conducted on the mailing list or in the meetings w.r.t. adoption.

 

Ciao

Hannes

 

From: RATS <rats-bounces@ietf.org> On Behalf Of Yogesh Deshpande
Sent: Donnerstag, 14. Dezember 2023 12:31
To: muhammad_usama.sardar <muhammad_usama.sardar@tu-dresden.de>; rats@ietf.org
Subject: Re: [Rats] CoTS and CoRIM

 

Hi Hannes,

 

To your question:

 

I am wondering why the two documents <draft-ietf-rats-corim> and <draft-ietf-rats-concise-ta-stores> aren’t merged.

 

The work on Cots started at different point in time (by different authors) and hence the CoRIM base document does refer Cots but is not fully integrated.

 

We will discuss the possibility and implications of such in our regular CoRIM meetings.

 

Regarding Trust Anchors as per RATS document (RFC 9334) to the best of my knowledge it comes under the heading of Endorsements.

https://datatracker.ietf.org/doc/html/rfc9334#name-endorsements

 

RATS treats Trust Anchors as a type of Endorsements.

 

Hope this information is helpful.

 

Regards,

Yogesh

 

From: RATS <rats-bounces@ietf.org> On Behalf Of Muhammad Usama Sardar
Sent: Thursday, December 14, 2023 8:21 AM
To: rats@ietf.org
Subject: Re: [Rats] CoTS and CoRIM

 

Hi Hannes,

On 13.12.23 21:24, hannes.tschofenig=40gmx.net@dmarc.ietf.org wrote:

I am wondering why the two documents <draft-ietf-rats-corim> and <draft-ietf-rats-concise-ta-stores> aren’t merged. Reading through the RATS drafts I often get the impression that trust anchors have somehow been forgotten and were added later, as an afterthought. The RATS architecture RFC does not list trust anchors as an item in Figure 1. In some other document trust anchors are then portrait as belonging to reference values – somehow. That does not feel right to me either.

I think it is completely wrong to consider trust anchors as Reference Values. Can you name the document which presents this view? 

 

Ciao

Hannes

Cheers,

Usama

IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. 

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