Re: [Rats] Verifier Input instead of Endorsement?

Michael Richardson <> Thu, 02 July 2020 20:57 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9DBCD3A0B4A for <>; Thu, 2 Jul 2020 13:57:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Q_nM2bC6agXJ for <>; Thu, 2 Jul 2020 13:57:45 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 02D043A0B4B for <>; Thu, 2 Jul 2020 13:57:44 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 55DAD389D3; Thu, 2 Jul 2020 16:54:54 -0400 (EDT)
Received: from ([]) by localhost (localhost []) (amavisd-new, port 10024) with LMTP id jnMeipT7IJzY; Thu, 2 Jul 2020 16:54:53 -0400 (EDT)
Received: from ( []) by (Postfix) with ESMTP id F3847389AF; Thu, 2 Jul 2020 16:54:52 -0400 (EDT)
Received: from localhost (localhost [IPv6:::1]) by (Postfix) with ESMTP id B7C3E3DE; Thu, 2 Jul 2020 16:57:41 -0400 (EDT)
From: Michael Richardson <>
To: "rats\" <>, Laurence Lundblade <>
In-Reply-To: <>
References: <> <> <> <> <>
X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.1
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: Thu, 02 Jul 2020 16:57:41 -0400
Message-ID: <13132.1593723461@localhost>
Archived-At: <>
Subject: Re: [Rats] Verifier Input instead of Endorsement?
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, 02 Jul 2020 20:57:48 -0000

Laurence Lundblade <> wrote:
    > The problem with Endorser is that they produce Endorsements and I think there are problems with Endorsements:

    > - In Berlin you told me they don’t have keys in them. So then how do
    > keys get into the Verifier?

Well, first, I thought we agreed that the arcs above Verifier were out of
scope for the architecture.  The WG might recharter to include that, but I
thought we agreed that the concerns were seperable.  HOWEVER...

So in some cases the Verifier will be configured entirely by some proprietary
mechanism.  Those mechanisms could consist of pasting a configuration file
full of keys (trust anchors probably), along with Known Good Values.
Or, they could consist of a bunch of EATs of a semi-proprietary nature.
Semi, because we haven't standardized them yet, but conceptually they are

Maybe you want to start a personal ID that deals with an architecture for
To the extent that I think you want to use EAT for many of things, maybe it
would be a good repository of non-Evidence/non-Attestation-Result uses of


So, when you say "keys", I think you mostly mean Trust Anchors, right?
These would things like Manufacturer IDevID anchors.
These would allow a Verifiers to know that is dealing with authentic units
from Mfg X, and therefore the Manufacturer X-signed Endorsement that were
published somewhere can be applied.

    > - Endorsements seem to be small signed documents of attributes so they’re not so good for:
    > - Representing a database of millions of keys
    > - Representing HTTP access to a manufacturers database of known-good/reference values

I don't quite understand this.
The database of keys could be a single trust anchor if the keys are all
signed in some way.  That doesn't have to be PKIX if you (like me) hate that.
EAT can be used, CoID, PGP, etc.
PGP has replicating keyserver technology that could be applied here, btw.

I don't quite understand "Representing HTTP access"... part.
I guess this is more than just having a URL.
It seems that when/if we come to standardizing the Endorsement arc, that we
might need to standardizing a way of accessing the database, even if that
is just about describing how a URL fragment can be extended with a firmware
version number.
We'd need to say how that URL fragment is communicated. I can think of a few
ways, some good, some less good.

    > - One-time physical / ceremonial transfer of a root key

Please explain how this would be used.
I'm very interested.

    > - Endorsements seem like a somewhat narrowed, specific way of providing verifier input
    > - Endorsements imply signing as the security mechanism, which is too narrow.

    > Maybe we can find a term other than manufacturer?  What I want to avoid
    > is the general use of the term Endorsement for the above reasons. Using
    > the term Endorsement to me is like using the protocol-specific term EAT
    > instead of conceptual term Attestation Evidence. Use of the term
    > Endorser implies Endorsement, but maybe it is OK if we don’t use the
    > term Endorsement.

"Terms of Endorsement" <-- staring Shirley, Debra, Jack and

]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        |    IoT architect   [
]        |   ruby on rails    [

Michael Richardson <>ca>, Sandelman Software Works
 -= IPv6 IoT consulting =-