Re: [Rats] Attestation of implementation vs authenticity of service

Laurence Lundblade <> Thu, 06 August 2020 19:09 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 3878A3A0E0E for <>; Thu, 6 Aug 2020 12:09:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.895
X-Spam-Status: No, score=-1.895 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ABBPXvDKH0Ll for <>; Thu, 6 Aug 2020 12:09:51 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id DD2D23A0E0B for <>; Thu, 6 Aug 2020 12:09:51 -0700 (PDT)
Received: from [] ([]) by :SMTPAUTH: with ESMTPA id 3lGwkPxI4e1cf3lGxkCFna; Thu, 06 Aug 2020 12:09:51 -0700
X-CMAE-Analysis: v=2.3 cv=U5vs8tju c=1 sm=1 tr=0 a=t2DvPg6iSvRzsOFYbaV4uQ==:117 a=t2DvPg6iSvRzsOFYbaV4uQ==:17 a=IkcTkHD0fZMA:10 a=QyXUC8HyAAAA:8 a=48vgC7mUAAAA:8 a=K6EGIJCdAAAA:8 a=gKmFwSsBAAAA:8 a=3j4BkbkPAAAA:8 a=qWX2815_JrchmU1UgoQA:9 a=t-6OkMMwBgOnfhEF:21 a=9D5VBP6m7CVHqV40:21 a=QEXdDO2ut3YA:10 a=w1C3t2QeGrPiZgrLijVG:22 a=L6pVIi0Kn1GYQfi8-iRI:22 a=nnPW6aIcBuj1ljLj_o6Q:22
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
From: Laurence Lundblade <>
In-Reply-To: <>
Date: Thu, 6 Aug 2020 12:09:50 -0700
Cc: Carsten Bormann <>, "" <>
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <> <>
To: "Smith, Ned" <>
X-Mailer: Apple Mail (2.3445.104.11)
X-CMAE-Envelope: MS4wfLD9A6/QBXnM+tNvKKZ/iXZbHDk4rP8XgbmclBvWK4hpZST5NH7Ava9KWicFq75nuDma854A2JqFFJ6QK4urTvvFte+tw6FAf1LiQxCesd3V2o82YcFb /dZUAEavYycQKx/6QACp332GEFuVhtLRz2+JZ4XuTTlHl2V7kQfgTx4UrycBj2jxzwcMul5WE32bH3o25TPIWC/YfBPeeEewJiAvOxzWEmZlgZ3Dq2O8FLyk
Archived-At: <>
Subject: Re: [Rats] Attestation of implementation vs authenticity of service
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: Thu, 06 Aug 2020 19:09:53 -0000

Yes, the RATS architecture seems highly applicable to claims-about-services (for lack of a better term). It would be dumb to have an IETF architecture for claims-about-services that didn’t re use the RATS architecture at least partially.

By my read of the charter, claims-about-services are not explicitly excluded, but also not quite in the spirit of it. Maybe the work done is done in RATS with a re charter?

The bottom line for me, is that I really don’t want to put any claims about services in EAT. There is enough work to do already :-)


> On Aug 6, 2020, at 11:38 AM, Smith, Ned <> wrote:
> The RATS charter refers to "system component" as the initial focus for definition; which includes claims definition. The architecture makes it clear that claims can originate elsewhere as well. It seems reasonable that claims about services could be defined elsewhere, but still be conveyed / appraised using RATS WG defined architecture and technology. Alternatively it could be defined in RATS, but possibly with some charter adjustments to allow "services" scope?
> -Ned
> On 8/5/20, 12:42 PM, "RATS on behalf of Laurence Lundblade" < on behalf of> wrote:
>> On Aug 5, 2020, at 4:47 AM, Carsten Bormann <> wrote:
>> On 2020-08-03, at 20:58, Laurence Lundblade <> wrote:
>>> Service Authenticity
>>> 	• Focus is on the provider of the service, not the HW or SW
>>> 	• The legal entity of interest is the service provider
>>> 	• There is no equivalent of claims, but if there was they would be about the business or person operating the service
>>> 	• Example: a web site
>>> 	• Example: an email provider (IMAP service)
>> Hi Laurence,
>> if you are talking about HTTPS, there is exactly one claim:  The service is speaking for a specific name (e.g.,  All other claims are funneled through this one very special one.  Of course, the TLS handshake could be leveraged to do more than this one claim, but that is not what happens in HTTPS.
>    Yes, agreed.
>    Any notion of trustworthiness, regulatory compliance and such for a service is implied. We make heavy use of that implication and that is mostly OK. For example, knowing that is Facebook Inc allows us to assume lots about the service from what we know of the company. 
>    The equivalent for attestation would be just to name the manufacturer of the HW or SW. However, we are going far beyond that with all the Claims in the Evidence and Results.
>    Maybe we should have Claims about services? For example, what regulatory statutes they meet. Where are they incorporated. A reference to their terms of service and privacy policy.
>    That however seems like a new WG, not RATS.
>    LL
>    _______________________________________________
>    RATS mailing list
> _______________________________________________
> RATS mailing list