[Rats] Re: Hint Discussion in CSR Attestation Draft

[Henk Birkholz <[e-mail]>]

Hi Hannes,

I am replying in the wrong order (yet again), it seems. In my previous 
response, I highlighted the use of a MUD URL and corresponding MUD file 
(RFC9520). Would that help? There is a PoC MUD file in that expired 
related individual I-D (I-D.birkholz-rats-mud) and I think that could be 
a pretty straight forward solution option (as the Verifier might also 
need more information about Endorsements and RVs, etc.)


Viele Grüße,

Henk

On 17.06.24 14:20, Tschofenig, Hannes wrote:
> Hi all,
> 
> I would like to come back to the hint discussion.
> 
> As Mike mentioned, we want to support use cases where the relying party 
> and the verifier are separate roles. Note that two roles does not imply 
> separate physical devices nor does it imply the verifier and the relying 
> party to be operated by different operators. We also want to prevent the 
> relying party from understanding the details of the evidence since this 
> is what the verifier is supposed to do.
> 
> If there is only a single verifier that handles all evidence types from 
> all vendors then it is trivial for the relying party to make a routing 
> decision. Even if two or more vendors implement TPM-based attestation 
> there is no problem with routing the evidence to the verifier. (Note 
> that OIDs are typically assigned to evidence formats and not to vendors 
> unless they are vendor-proprietary evidence formats.)
> 
> If there is more than one verifier then the story gets more interesting. 
> If remote attestation will become more common, then we need to have a 
> story of how to deploy such a system in a scalable way. The question is: 
> how is going to work?
> 
> Unfortunately, the RATS working group has not provided an answer in 
> their architecture document.
> 
> In the CSR attestation draft we suggested to use a hint, i.e. 
> information that helps the relying party to select a verifier that can 
> help process the evidence. Since this hint will not be used in all 
> deployments, for example in deployments that only have a single 
> verifier, this hint is optional. As such, those who do not want to use 
> the optional hint do not need to look at it. For the other use cases it 
> provides value.
> 
> Hence, I don’t really understand the objections and I don’t want to 
> remove the hint!
> 
> Ciao
> 
> Hannes
> 
> 
> _______________________________________________
> RATS mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]