Re: [Rats] Verifier Input instead of Endorsement?

[Henk Birkholz <[e-mail]>]

Hi Laurence,

at first, I thought I get your line of thought, but now I am confused 
again. Sorry! Comments in-line.

On 07.07.20 16:51, Laurence Lundblade wrote:
> 
> 
>> On Jul 4, 2020, at 4:18 PM, Michael Richardson <[e-mail] 
>> <mailto:[e-mail]>> wrote:
>>
>>
>> Laurence Lundblade <[e-mail] 
>> <mailto:[e-mail]>> wrote:
>>>> Laurence Lundblade <[e-mail] 
>>>> <mailto:[e-mail]>> 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...
>>
>>> If that’s the approach, then Endorsements should be removed from the
>>> document, both in the text and diagram.
>>
>> That makes no sense to me.
>>
>> It is perfectly reasonable to define something just well enough in 
>> order to make it
>> clear what is out of scope for standardization.
>>
>> We can come up with many different ways to standardize Endorsements (or
>> Verifier Inputs), and it shouldn't matter at all to the protocol between
>> Attester and Verifier.
>>
>> That's what makes it seperable.
>> Do you agree?
> 
> Sorry, didn’t say that right.
> 
> If we’re going to minimize description of what is above the Verifier, 
> then the term “Endorsement” should be replaced with a more general term 
> like “Verifier Input” or “Attester Trust Criteria” or other.
> 
> I think there are three problems with the term “Endorsement":
> - It implies a specific style of input (a signed document) that is too 
> narrow for a general architecture

If that is what a reader gets from the document we have to do better. An 
endorsement does not have to be signed in the way that a UCCS does not 
have to be signed. It has to be tamper-evident though, because the 
Verifier relies on its integrity. That's the point and I think that is 
not too narrow.

> - It is ambiguous and/or not clear it is even correct. The room in 
> Berlin of experts agreed that Endorsement can’t have keys in them, but 
> there must be a key input to the Verifier.

Well, my recollection of that room of experts does not include any 
opinions on key material for Endorsements as defined for IETF RATS. The 
TCG defines (I just looked that up) four specific terms around and 
"Endorsement Key", so I am relatively sure that key material is involved 
in all cases, as these are the only terms that make use of the phrase 
endorsement.

> - It is TCG-specific. The term is not used in FIDO, Android and 
> TEE-based projects that I’ve worked on.

And this confuses me. I'll do a self-quote here: "Endorsements as 
defined for IETF RATS". We are defining that term here in the RATS 
architecture. The TCG does not define it in any document that I could 
google just now. Maybe I have missed something there. But that is beside 
the point anyways. The point is that we are defining it here.


Viele Grüße,

Henk

> 
> 
> Some text like this?
> 
>     Verifier Input
> 
>     Inputs used by the Verifier to establish trust in Attester, evaluate
>     Attestation Evidence and produce Attestation results. It may include
>     cryptographic keys, known-good/reference values, static implicit
>     claims and policy configuration.
> 
> 
> LL
> 
> _______________________________________________
> RATS mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/rats
>