[Rats] Re: Hint Discussion in CSR Attestation Draft

[Henk Birkholz <[e-mail]>]

Hi MCR,

so a MUD file cannot point to feasible Verifiers?


Viele Grüße,

Henk

On 19.06.24 22:58, Michael Richardson wrote:
> 
> Henk Birkholz <[e-mail]> wrote:
>      > 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
> 
> No, I don't think *8*520 (MUD) can help here at all.
> The HSM is often really really offline.
> As in, in a safe, and almost nothing goes in, and certainly nothing comes
> out, so there isn't anything for MUD to describe.
> 
> Hannes wrote:
>      ht> Hi all, I would like to come back to the hint discussion.  As Mike
>      ht> mentioned, we want to support use cases where the relying party and
>      ht> the verifier are separate roles. Note that two roles does not imply
>      ht> separate physical devices nor does it imply the verifier and the
>      ht> relying party to be operated by different operators. We also want to
>      ht> prevent the relying party from understanding the details of the
>      ht> evidence since this is what the verifier is supposed to do.
> 
>      ht> If there
>      ht> is only a single verifier that handles all evidence types from all
>      ht> vendors then it is trivial for the relying party to make a routing
>      ht> decision. Even if two or more vendors implement TPM-based attestation
>      ht> there is no problem with routing the evidence to the verifier. (Note
>      ht> that OIDs are typically assigned to evidence formats and not to
>      ht> vendors unless they are vendor-proprietary evidence formats.)
> 
> It seems to me that the is inadequate for the job.
> Perhaps it is underspecified.  Maybe an OID would be better than a string.
> 
>      ht> If
>      ht> there is more than one verifier then the story gets more
>      ht> interesting. If remote attestation will become more common, then we
>      ht> need to have a story of how to deploy such a system in a scalable
>      ht> way. The question is: how is going to work?  Unfortunately, the RATS
>      ht> working group has not provided an answer in their architecture
>      ht> document.
> 
> I agree that the architecture does not specify something here.
> I note that it really can't be just arbitrary... even in something like
> OpenID connect (which has a similar model, but it's not remote attestation
> itself), in most cases, you can't come along and use any identity provider.
> (Alas)
> 
> For quite a number of use cases, that information about the verifier would
> have to be an outer protocol container.   Prior to 9334, these [business]
> relationships were essentially encoded as device vendor specific Evidence.
> (thinking about smartphones)
> 
>      ht> In the CSR attestation draft we suggested to use a hint,
>      ht> i.e. information that helps the relying party to select a verifier
>      ht> that can help process the evidence. Since this hint will not be used
>      ht> in all deployments, for example in deployments that only have a single
>      ht> verifier, this hint is optional. As such, those who do not want to use
>      ht> the optional hint do not need to look at it. For the other use cases
>      ht> it provides value.  Hence, I don’t really understand the objections
>      ht> and I don’t want to remove the hint!
> 
> I guess I've lost track of who and why this is being objected to.
> 
> 
> 
> --
> Michael Richardson <[e-mail]>   . o O ( IPv6 IøT consulting )
>             Sandelman Software Works Inc, Ottawa and Worldwide
> 
> 
> 
> 
> 
> _______________________________________________
> RATS mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]