Re: [Rats] FW: New Version Notification for draft-shaw-rats-rear-00.txt

Kathleen Moriarty <> Mon, 06 July 2020 14:40 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A9E443A1583 for <>; Mon, 6 Jul 2020 07:40:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Status: No, score=-2.098 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, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id xpZZj_Oal5jx for <>; Mon, 6 Jul 2020 07:40:51 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::736]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 3DECB3A1572 for <>; Mon, 6 Jul 2020 07:40:51 -0700 (PDT)
Received: by with SMTP id 80so34957737qko.7 for <>; Mon, 06 Jul 2020 07:40:51 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=content-transfer-encoding:from:mime-version:subject:date:message-id :references:cc:in-reply-to:to; bh=jqiKnKBqh3PJyhGwjBTIBkIpqsLSxEg/wc7VXAuz9uo=; b=O458Z6g8muRwM//9QG8vsa003H0TCLq7tGA81gE79ceXaluTKRWx9yS5z2q5sUwsqM G9BEcaL7Ip0LwHhuqiE0UbzJnGlEsSgODK9LUIYyNaPfSmk4LL0un+xrqIf/m74O7jjP 5H3vvdRYM2GV99ElXEAEWFNew/V4z/efQTZpgCbDmfpWYy9IIDTt/XcOOIEYFSLsGGHz ytwodd9Nft8Z0pFZhepY34s1yRnmxHM4kZcA7vcpO8fNGbfH5yZ0MNlftT0+5wOl9dFW VJKXH5ZTxsENuRkr/nITw1H16QBIoSFsFq8aoeCSPrGHqUMap8qnKoShQjrCNd5o3nO2 JxhQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:content-transfer-encoding:from:mime-version :subject:date:message-id:references:cc:in-reply-to:to; bh=jqiKnKBqh3PJyhGwjBTIBkIpqsLSxEg/wc7VXAuz9uo=; b=YaTjLmJZ8wD3zXxlR9SfFg9Bs8dXNq0nkfAT54OEC1vKHwc9HMSgSfbWGOA3jtqysH dKEby0dKIu89HSJKLfY9zQlls6x4kaPXVGSNhncO3pwJIOT7X9zW3CgHuRfHroONm0sZ WdrPYxaXGiCIln0DQ1jabJrEYBM/8A/7kwN8ynd89hsMJmp124hU/OTcSZUPsLMIQ0xt yaHNWjMiU/BD2pB+vwR55bUVu1jqu99JYWR2pE1VBY7Vcyc3/nZDBQb7C+bycCDqsjx3 +txjNcIzDvORD/kcc456k9qhROAJxyyWnxS07/U3SXiw5T1EcgenrpKRlEF+uwc08iwg LW8Q==
X-Gm-Message-State: AOAM533a3fPR1MBk2urjuIsdvrSll0WsSB85mG7fL9WgsiQbqOec4RXv 3gOWal32EH8yNfpWdVJSW/kWcvKn
X-Google-Smtp-Source: ABdhPJycgrX5zz69PvlLCdtZSKVb9aLlyaX5W/2nBC3UUrgTjsJ59L2wmQ1gJuL5f3QDUuvsc6kqXQ==
X-Received: by 2002:ae9:eb15:: with SMTP id b21mr46432500qkg.25.1594046450095; Mon, 06 Jul 2020 07:40:50 -0700 (PDT)
Received: from ?IPv6:2600:380:5a37:adff:6c2f:8ed:ac31:d3c7? ([2600:380:5a37:adff:6c2f:8ed:ac31:d3c7]) by with ESMTPSA id w18sm20336000qtn.3.2020. (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 06 Jul 2020 07:40:49 -0700 (PDT)
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
From: Kathleen Moriarty <>
Mime-Version: 1.0 (1.0)
Date: Mon, 6 Jul 2020 10:40:48 -0400
Message-Id: <>
References: <>
Cc: "" <>
In-Reply-To: <>
To: Thomas Fossati <>
X-Mailer: iPhone Mail (17F80)
Archived-At: <>
Subject: Re: [Rats] FW: New Version Notification for draft-shaw-rats-rear-00.txt
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Remote ATtestation procedureS <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 06 Jul 2020 14:40:53 -0000

Thank you for your work on this document.  I read through it on a phone, so I don’t have detailed comments, but a few high level.

This sort of document was needed, good stuff!  Since we have a number of RESTful protocols in use to exchange formatted data, it would be good to explicitly state support for these protocols.  SCAPv2.0 has adopted ROLIE [RFC8322].  Since SCAP is how posture assessment is performed, it would be good to include this capability to enable a smooth transition to the use of remote attestation for simplified posture assessment as this work evolves.

Similarly, RedFish is in use for server management across several platforms.  I’ve been working with the DMTF to improve security of RedFish just in case it could be used.

There are likely other protocols that may be used, and leaving this open to accommodate various RESTful protocols may be the best approach towards enabling adoption.  This would also enable use for a shared purpose- configuration management in an IT application as well as security posture assessment.

Best regards,

Sent from my mobile device

> On Jun 12, 2020, at 1:00 PM, Thomas Fossati <> wrote:
> Hi, all,
> We have just submitted a new draft "RESTful attested resources" (details
> below).
> The main goal here is creating a mechanism to expose attested system
> state as RESTful resources (i.e., "things" that can be de-referenced by
> their URIs) together with a way to securely bind said system state with
> an EAT token.
> We define two REST interfaces: one to the Attester and one to the
> Verifier, with timestamp- and nonce-based freshness.  We show how these
> can be composed into the usual "background check", "passport" and
> "time-based unidirectional" patterns.  HTTP and CoAP instantiations are
> provided, together with the associated MIME machinery.  A discovery
> method is also discussed based on the CoRE Resource Directory.
> This proposal seems in scope with the RATS charter, in particular its
> "Standardize interoperable protocols to securely convey
> assertions/claims." bit.  We hope this provides a valid contribution on
> how the RATS architecture and basic protocol elements can be used in
> high level protocol(s), and would really appreciate any feedback with
> regards to its usefulness, correctness and completeness.
> cheers, thanks!
>> On 12/06/2020, 17:48, "" <> wrote:
>> A new version of I-D, draft-shaw-rats-rear-00.txt
>> has been successfully submitted by Thomas Fossati and posted to the
>> IETF repository.
>> Name:draft-shaw-rats-rear
>> Revision:00
>> Title:Restful Attested Resources
>> Document date:2020-06-12
>> Group:Individual Submission
>> Pages:23
>> URL:  
>> Status:
>> Htmlized:
>> Htmlized:
>> Abstract:
>>   This memo describes a REST interface based on the RATS architecture
>>   that can be used to retrieve attested system state, for example the
>>   reading of a security critical sensor.  The objective is to present a
>>   common vocabulary of data formats and basic protocol transactions
>>   that can be pieced together into a cohesive interface that is capable
>>   of serving different attestation workflows.
> 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