[Rats] Re: Hint Discussion in CSR Attestation Draft

[Michael Richardson <[e-mail]>]

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