Re: [Rats] Requesting a Nonce from a Verifier

["Smith, Ned" <[e-mail]>]

>> [Hannes] How do you solve the following problem: Image a device wants to transmit a CSR with attestation evidence to the CA. The device needs a nonce to demonstrate freshness. There is more than one Verifier.
>>
>> How does the exchange look like such that a Verifier is selected, which fulfills two properties:
>> * it needs to support the attestation technology of the attester, and
>> * the attester's signing key of the evidence is trusted by the verifier.
>
>Well, Epoch Markers are one solution to the scenario, of course. In that case, if you trust an Epoch Bell, you would not have to worry about the number of Verifiers.
>
>In your scenario of Verifier and Capability Detection/Negotiation, MUD, for example, could help you with that. Minimally, MUD could help you to identify Verifiers, but it could also help you to identify Capabilities.
>
>Establishing trust in the Attester's Identity Document is not the Attester's duty, IMHO. You can burden it with that duty and can compose a very specific system of solutions here. But how do you imagine to enable evolution this very specific setup that would scale and retain interoperability?

I'm not sure I understand Hanne's use case. Is the CA doubling as the RATS Verifier? If so, why would there be multiple CAs sharing the same CSR? If not, why does one CA need attestation results from multiple Verifiers (would their responses be different)?

Specific to ">> * the attester's signing key of the evidence is trusted by the verifier." - A RATS Verifier doesn't trust the Attester's signing key. Rather, it trusts the CA key that issued the Attester's signing key. Trust in the Attester's signing key might be established with a Relying Party after evaluating Attestation Results. The Verifier trusts the Attester's CA using a Trust Anchor policy (presumably provisioned by the Verifier Owner). 

BTW: I'm not sure how the above question ties back to the discussion on freshness / recentness.

-Ned