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

Laurence Lundblade <> Wed, 05 August 2020 19:42 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 8907A3A0EE4 for <>; Wed, 5 Aug 2020 12:42:33 -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 8vsgmTU5cP1a for <>; Wed, 5 Aug 2020 12:42:31 -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 A8B633A0EE2 for <>; Wed, 5 Aug 2020 12:42:31 -0700 (PDT)
Received: from [] ([]) by :SMTPAUTH: with ESMTPA id 3PJ0kBiOuOuJf3PJ0kH2nW; Wed, 05 Aug 2020 12:42:31 -0700
X-CMAE-Analysis: v=2.3 cv=MuosFFSe c=1 sm=1 tr=0 a=t2DvPg6iSvRzsOFYbaV4uQ==:117 a=t2DvPg6iSvRzsOFYbaV4uQ==:17 a=IkcTkHD0fZMA:10 a=gKmFwSsBAAAA:8 a=K6EGIJCdAAAA:8 a=3j4BkbkPAAAA:8 a=vZedWt0RVwdtpxjTqWIA:9 a=o-csBJJfispoz6G8:21 a=dM9xpabJHE6P-Yp2:21 a=QEXdDO2ut3YA:10 a=nnPW6aIcBuj1ljLj_o6Q:22 a=L6pVIi0Kn1GYQfi8-iRI: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: Wed, 5 Aug 2020 12:42:30 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <>
To: Carsten Bormann <>
X-Mailer: Apple Mail (2.3445.104.11)
X-CMAE-Envelope: MS4wfJU/U831n3hX4mraTHOyuZy8vkongDk49lHCiA+6G7NoV9DtI4Sa65l8s7irICpBYpaggVPaqvIcueuqSB9zjeStFzcK/JUAOjGci4EPHZD+pqVt5daQ RdAF2E3FVoVjSEq1rfRR4zzI3FNK9Zv3j2r9moOyaUL90gJkfxYT98NHRT1e9YxJU04+AAS5mDWV2w==
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: Wed, 05 Aug 2020 19:42:34 -0000

> 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.