Re: [Rats] Verifier Input instead of Endorsement?

[Henk Birkholz <[e-mail]>]

On 07.07.20 20:33, Laurence Lundblade wrote:
> 
> 
>> On Jul 7, 2020, at 8:29 AM, Henk Birkholz 
>> <[e-mail] 
>> <mailto:[e-mail]>> wrote:
>>
>> 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]><mailto:[e-mail]>> wrote:
>>>>
>>>>
>>>> Laurence Lundblade <[e-mail] 
>>>> <mailto:[e-mail]><mailto:[e-mail]>> wrote:
>>>>>> Laurence Lundblade <[e-mail] 
>>>>>> <mailto:[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.
> 
> If you want to define an Endorsement as a *protocol*, not just a 
> signed/unsigned document, then the term might work.
> 
> Endorsement Protocol:
>   - A one-time transfer or a multiple requests/responses for each and 
> every Verification or anything in between
>   - Must provide integrity
>   - May have to provide confidentiality, particularly for symmetric keys

I'd think that would be a little bit too much for an architecture, but 
to generally associate attributes, such as authentic and tamper-evident, 
with conceptual messages that are endorsements sounds fine for me at 
first glance.

Solution I-Ds can build on that as is the intent of the architecture 
document.

> 
> 
>>> - 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.
> 
> My slide in Berlin said “Endorsements have key material”. You that 
> wasn’t right. I said “sorry for my mistake”. The room tacitly agreed 
> with you.

Maybe we were talking past each other? Going back to the examples I 
looked up: TCG EK-Certs, for example, can include pub-keys, of course. 
If you remember the openssl output of my screen - there were some 
pub-key structures in there. But then again, I would not focus on these 
kinds of certificates here - that seems way to niche'ish. I would rather 
like to focus on what we create here, currently (which allows for 
multiple types of Endorsements already).

> 
> This says to me that at least one of these is true:
>   - There is some pre conceived idea for what Endorsements are, 
> seemingly from the the TCG world
>   - There is confusion about what Endorsements are (you said no keys in 
> Berlin, now you say there are keys)
>   - RATS architecture is not clear about how verification key material 
> gets to the Verifier.
> 
> I don’t mind being wrong here. My trouble is the lack of clarity, common 
> understanding and gap in the RATS architecture.

I am little bit at a loss why you think that the definition here:

> https://tools.ietf.org/html/draft-ietf-rats-architecture-04#section-2

and the associated expositional text here:

> https://tools.ietf.org/html/draft-ietf-rats-architecture-04#section-8.2

is leaving any confusion to what Endorsements are?

Key Provisioning is a separate topic, I think. And I am now growing more 
certain that you are missing text about key provisioning in the RATS 
architecture document, yes?

For me that represent a tangible issue. The architecture document does 
not directly address key provisioning - that is certainly true. But I am 
not sure, if there is any intent to add text about that to a RATS 
document. Are there opinions on the list about this?

Viele Grüße,

Henk

> 
>>
>>> - 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.
> 
> Seems to me there are semantics associated with the term “Endorsement” 
> from the TCG and that seems to be of a relatively static document that 
> is transferred once. It seems like adopting a definition in RATS that is 
> beyond that is confusing (e.g., confusion between now and Berlin).  If 
> we must use the term Endorsement, then I think it should Endorsement 
> Protocol to separate from the previous.
> 
> I still think this is simple and could work:
> 
>     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
> 
> 
> 
>>
>>
>> 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] <mailto:[e-mail]>
>>> https://www.ietf.org/mailman/listinfo/rats
>>
>> _______________________________________________
>> RATS mailing list
>> [e-mail] <mailto:[e-mail]>
>> https://www.ietf.org/mailman/listinfo/rats
>