Re: [Rats] UJCS standardization (relates to UCCS WG last call)

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

> (EAT allows nesting of a UCCS EAT in a JWT-format EAT or a UJCS EAT in a CWT-format EAT, but that is whole-token nesting defined by EAT and a different thing).
But I think it's worth some discussion since CWT/JWT RFCs didn't (apparently) anticipate use cases for embedding tokens within tokens and whether doing so constitutes violation of the normative language they contain. 

UCCS contains this:
"Effectively, the COSE envelope of a CWT (or a nested EAT) shields the CWT Claims Set from the endorsement of the secure channel. (Note that EAT might add a nested UCCS Claim, and this statement does not apply to UCCS nested into UCCS, only to fully formed CWTs.)"

This text seems to say that its incorrect to ascribe counter-signing semantics to nested tokens. 
The parenthetical seems to say that unsigned nested tokens remain unsigned - which seems obvious.
But I wonder if more semantics are implied, namely, that the content requirements of a top level token somehow don't apply if the nested token isn't signed?

I struggle to find the use case context to help ground the nesting possibilities. Superficially, UCCS is saying if the CWT isn't a CWT simply because the surrounding signature block is replaced by channel security, then it still should be treated like a valid CWT. If a UCCS contains another UCCS (due to recursion or whatever) is this object just one token (since the issuer of the inner UCCS is effectively the same signer as the outer UCCS) or is there meaning in a "token" that is truly unsigned?

The EAT draft says "An EAT is either a CBOR Web Token (CWT) or JSON Web Token (JWT) with
   attestation-oriented claims." which implies the goal of EAT isn't to modify the content requirements laid down by CWT and JWT. If a CWT is instead expressed in terms of a channel protected UCCS (or JWT in terms of a channel protected UJCS), would anyone expect to find a UCCS inside a UJCS or UJCS inside a UCCS based on the language of CWT/JWT?

I think these are interesting questions that I wonder if others have considered and if there is consensus over their answers.
-Ned

On 9/13/23, 11:57 AM, "RATS on behalf of lgl island-resort.com" <[e-mail] <mailto:[e-mail]> on behalf of [e-mail] <mailto:[e-mail]>> wrote:






> On Sep 13, 2023, at 11:41 AM, Smith, Ned <[e-mail] <mailto:[e-mail]>> wrote:
> 
> Note also that draft-ietf-rats-eat-media-type mentions "UJCS" but doesn't reference the spec that defines it. 
> 
> Additionally, RFC8392 requires the contents of a CWT to contain CBOR. I don't think UCCS (which defines both CBOR and JSON) clearly explains whether it modifies the RFC8392 content requirements. In other words, is a UCCS (not UJCS) the same as a CWT minus the signature?
> 
> RFC7519 places similar constraints on the JWT payload (that it contains JSON). Does a UJCS expect to preserve the JWT content requirements minus the signature?


Ahh, now your previous comments make sense to me, Ned.


I don’t think we want to use COSE to sign JSON-format claims sets or use JOSE to sign CBOR-format claim sets even though I we could. That seems like unnecessary complexity and flexibility to me and I don’t think anyone is asking for that. Definitely not me!


(EAT allows nesting of a UCCS EAT in a JWT-format EAT or a UJCS EAT in a CWT-format EAT, but that is whole-token nesting defined by EAT and a different thing).


> 
> If draft-ietf-rats-uccs is intended to define "UJCS" then it probably is not named properly.
> 


Yes, I’m using UCCS to refer to an unsigned CBOR-format claims set and UJCS to refer to an unsigned JSON-format claims set. If the draft covered both we’d have to rename the draft to UCS or UTCS or such.


LL






> -Ned
> 
> On 9/13/23, 11:03 AM, "RATS on behalf of lgl island-resort.com" <[e-mail] <mailto:[e-mail]> <mailto:[e-mail] <mailto:[e-mail]>> on behalf of [e-mail] <mailto:[e-mail]> <mailto:[e-mail] <mailto:[e-mail]>>> wrote:
> 
> 
> It was noticed during WG last call that UCCS does standardize an unsigned claims set in JSON format, only CBOR (even though it provides a CDDL definition for JSON).
> 
> 
> Here’s a few comments/reasons for standardizing UJCS:
> 
> 
> - EATs carrying attestation results are often B2B/server-server interactions where JSON+TLS is very common and the JWT signing overhead would be redundant.
> 
> 
> - Lack of UJCS standard sticks out a a missing piece in the document set of EAT, UCCS and EAT media types. It’s like we painted all the doors and windows of a house a pretty color except one. It’s a gap in the set of EAT, EAT Nesting, EAT Bundles and EAT collections.
> 
> 
> - It’s true that the original motivating use cases were only for UCCS, but EAT grew up and filled in to support JSON.
> 
> 
> - Beyond attestation, sending JSON claim sets secured with TLS seems like it would get a lot of use. Not my area, but I suspect lots are doing it in some form now and there might be some broader benefit.
> 
> 
> - JWT does have the NULL-cipher option, but its use is awkward, discouraged, a bit complex and wasteful.
> 
> 
> 
> 
> Here’s the document options I can see for UJCS:
> - Add it to UCCS now.
> - A new RATS standards track document. It will be a small document, but it will have to go through the whole process.
> 
> 
> I haven’t heard anyone opposing UJCS, just a preference that we get UCCS done soon. If we don’t put it in the UCCS draft, I will probably write up new document myself and push it through RATS. I feel like EAT is not done without it.
> 
> 
> I feel for the reader of the complicated document set of JWT, CWT, EAT, EAT media types and UCCS (plus COSE and CBOR). One more document adds to this.
> 
> 
> I did look at what it would take to add it to the UCCS raft and it doesn’t seem too difficult. The biggest disruption is seems like the name change. The CDDL is already there. I will try to help with the authorship in UCCS.
> 
> 
> Also, sorry I didn’t notice until now. I had years.
> 
> 
> LL
> 
> 
> _______________________________________________
> RATS mailing list
> [e-mail] <mailto:[e-mail]> <mailto:[e-mail] <mailto:[e-mail]>>
> https://www.ietf.org/mailman/listinfo/rats <https://www.ietf.org/mailman/listinfo/rats> <https://www.ietf.org/mailman/listinfo/rats> <https://www.ietf.org/mailman/listinfo/rats&gt;>
> 
> 
> 


_______________________________________________
RATS mailing list
[e-mail] <mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/rats <https://www.ietf.org/mailman/listinfo/rats>