[Rats] Re: Freshness with Nonces

[Carl Wallace <[e-mail]>]

Inline…

 

From: "Tschofenig, Hannes" <hannes.tschofenig=[e-mail]>
Date: Monday, June 17, 2024 at 8:33 AM
To: "[e-mail]" <[e-mail]>, rats <[e-mail]>
Subject: [Rats] Freshness with Nonces

 

Hi all,

 

In the RATS architecture the Evidence is processed by the Verifier. For a given Verifier to check for replays timestamps, nonces, and epochs have been introduced. I only talk about nonces here.

 

The nature of nonces is that they are randomly selected by the party that checks against replays, the verifier in our case. Section 10.2 of RFC 9334 talks about nonce-based freshness.

 

No problem so far. However, when we integrate CSR attestation (which carries the evidence) into a certificate management protocol like EST or CMP we must request the nonce in advance before the attester is able to include the nonce in the signed evidence. 

 

[CW] I don’t think this “we must request the nonce” is correct, at least where “we” includes the attester. In some cases, the attester is acting upon instructions provided to it. Those instructions may include a nonce. An example of this arrangement is a SCEP payload in the iOS OTA protocol. How the MDM (or whatever prepared the instructions) obtained the nonce is irrelevant to the attester and, in my experience, need not be signaled in the subsequent request.

 

This raises questions about how the relying party (in the background check model) obtains that nonce without conveying any extra information from the attester to the relying party about which verifier to select.

 

What information should be used by the attester and subsequently by the relying party to determine the verifier before transmitting the evidence?

 

[CW] Your question raises questions about how the attester knows where to obtain that nonce without having been provided any extra information.

 

Ideally, the RATS architecture should have provided an answer to this question but unfortunately it does not.

 

[CW] I think this discussion is hinting at a desire for some attestation verification protocol. It may be that sticking an extensible field where the hint is now is the thing to do, to facilitate the relatively abstract current hint mechanism or a future, more concrete, link to a verification service.

 

Ciao
Hannes

 

PS: We (Hendrik and I) thought that the hint introduced in the CSR attestation would have been a good candidate for this determination. In our mental model the hint would be something like an FQDN because in the passport model of the RATS architecture the attester also needs to have the FQDN (or even a URL) of the verifier to get the communication working.

 

_______________________________________________ RATS mailing list -- [e-mail] To unsubscribe send an email to [e-mail]