[Rats] Re: [EXTERNAL] Re: Re: Freshness with Nonces

[Mike Ounsworth <[e-mail]>]

Right. So OAUTH SD might be an example where the verifier does all the work, and the RP wants to be oblivious.

 

When we embed attestations within PKI, the nonce needs to be carried by the PKI protocol (ACME, CMP, whatever), and that’s clearly the domain of the RP (which is the PKI component), and not the Verifier (which is the Attestation component).

 

/shrug?

Maybe splitting hairs over “Verifier” vs “RP” in the abstract is not actually a helpful debate?

 

---

Mike Ounsworth

 

From: Orie Steele <[e-mail]> 
Sent: Wednesday, June 19, 2024 9:06 AM
To: Mike Ounsworth <[e-mail]>
Cc: Muhammad Usama Sardar <[e-mail]>; Tschofenig, Hannes <[e-mail]>; [e-mail]; rats <[e-mail]>
Subject: Re: [Rats] Re: [EXTERNAL] Re: Re: Freshness with Nonces

 

I'm a tourist here. See this section of OAuth SD-JWT which comments on the responsibility of the "OAuth SD-JWT Verifier" when processing a "key binding token" which is associated with a "confirmation claim" 



I'm a tourist here.

See this section of OAuth SD-JWT which comments on the responsibility of the "OAuth SD-JWT Verifier" when processing a "key binding token" which is associated with a "confirmation claim" in a JWT (COSE equivalents exist, and are modeled the same way).

https://datatracker.ietf.org/doc/html/draft-ietf-oauth-selective-disclosure-jwt-09#section-8.3 <https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/draft-ietf-oauth-selective-disclosure-jwt-09*section-8.3__;Iw!!FJ-Y8qCqXTj2!aJtwyJzZqcWKkZ8igTJnRGTUzJBAL7-qlURY-fEnQenveC_1KY2lMHqhqlmdc0NFJbmHhGLRRTWv8-PJjW3J45tyIXo$> 

In my mental model, the RP is usually not aware of such details, but is aware of media types that require special processing by a verifier, and forwards them to verifiers trusted to evaluate such media types.

Hopefully this comment is helpful.

Regards,

OS



 

On Wed, Jun 19, 2024 at 8:57 AM Mike Ounsworth <Mike.Ounsworth=[e-mail] <mailto:[e-mail]> > wrote:

Hi Usama,

 

I agree that when a nonce is involved, “something” needs to be stateful. My question is whether it’s the RP that’s stateful, or the Verifier. In my mind, the RP is the big application with smarts that’s actually communicating with the attesting device, and the Verifier is some library or utility that knows how to read attestations, that’s how we laid out the abstract architecture diagram in CSR Attest (figure 1) [1] which is based on a very similar figure in RATS Architecture Background Check Model section (figure 6) [2].

 

However, on the other hand, the overall RATS Architecture (figure 1) [3] shows the Verifier being the front-end thing that communicates with the attester, and therefore the Verifier would be the thing that tracks nonce state.

 

So maybe the answer to my question is that the division of exact labour between “verifier” and “relying party” is fairly arbitrary and depends on the implementation?

 

[1]: https://datatracker.ietf.org/doc/html/draft-ietf-lamps-csr-attestation-09#name-architecture <https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/draft-ietf-lamps-csr-attestation-09*name-architecture__;Iw!!FJ-Y8qCqXTj2!aJtwyJzZqcWKkZ8igTJnRGTUzJBAL7-qlURY-fEnQenveC_1KY2lMHqhqlmdc0NFJbmHhGLRRTWv8-PJjW3JIunxo8c$> 

[2]: https://datatracker.ietf.org/doc/html/rfc9334#name-background-check-model <https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/rfc9334*name-background-check-model__;Iw!!FJ-Y8qCqXTj2!aJtwyJzZqcWKkZ8igTJnRGTUzJBAL7-qlURY-fEnQenveC_1KY2lMHqhqlmdc0NFJbmHhGLRRTWv8-PJjW3JgnCXkNc$> 

[3]: https://datatracker.ietf.org/doc/html/rfc9334#name-architectural-overview <https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/rfc9334*name-architectural-overview__;Iw!!FJ-Y8qCqXTj2!aJtwyJzZqcWKkZ8igTJnRGTUzJBAL7-qlURY-fEnQenveC_1KY2lMHqhqlmdc0NFJbmHhGLRRTWv8-PJjW3JoKd8Sn4$> 

 

---

Mike Ounsworth

 

From: Muhammad Usama Sardar <[e-mail] <mailto:[e-mail]> > 
Sent: Tuesday, June 18, 2024 10:18 PM
To: Mike Ounsworth <[e-mail] <mailto:[e-mail]> >
Cc: Tschofenig, Hannes <[e-mail] <mailto:[e-mail]> >; [e-mail] <mailto:[e-mail]> ; rats <[e-mail] <mailto:[e-mail]> >
Subject: [EXTERNAL] Re: [Rats] Re: Freshness with Nonces

 

On 18. 06. 24 22: 13, Mike Ounsworth wrote: Are common verifier implementations stateful like that? Your description below sounds like the Verifier creates the nonce, and then needs to remember it to correlate against the Evidence that it will 

On 18.06.24 22:13, Mike Ounsworth wrote:

Are common verifier implementations stateful like that? Your description below sounds like the Verifier creates the nonce, and then needs to remember it to correlate against the Evidence that it will receive eventually. 

If simply storing the nonce makes a protocol "stateful" then almost all protocols would be stateful. In my understanding, a protocol is "stateful" only when a participant needs to store some information across multiple sessions. In the case under discussion, Verifier is randomly generating a nonce for each session, and does not need to store it across multiple sessions. Hence, I think it is not stateful. Please correct me if I am wrong. 

I would expect that the RP chooses the nonce and then hands it in to the Verifier; but I have limited hands-on experience here.

RP should generate a nonce for freshness of Attestation Results (not the Evidence).

Usama

_______________________________________________
RATS mailing list -- [e-mail] <mailto:[e-mail]> 
To unsubscribe send an email to [e-mail] <mailto:[e-mail]> 




 

-- 

 

ORIE STEELE
Chief Technology Officer
www.transmute.industries <https://urldefense.com/v3/__http:/www.transmute.industries__;!!FJ-Y8qCqXTj2!aJtwyJzZqcWKkZ8igTJnRGTUzJBAL7-qlURY-fEnQenveC_1KY2lMHqhqlmdc0NFJbmHhGLRRTWv8-PJjW3J4zcbtDk$> 

 <https://urldefense.com/v3/__https:/transmute.industries__;!!FJ-Y8qCqXTj2!aJtwyJzZqcWKkZ8igTJnRGTUzJBAL7-qlURY-fEnQenveC_1KY2lMHqhqlmdc0NFJbmHhGLRRTWv8-PJjW3Jsrz1KcM$>