Hi Thomas, The EAT CDDL distinguishes between a detached claim set and a nested token. Since UCCS is defined as a token, it’s not a detached claims set. A detached claim set is entirely an internal EAT thing.
Nested Tokens can be signed EATs (CBOR or JSON) or UCCS (or UJCS someday). A UCCS comes into EAT through the sockets $EAT-CBOR-Tagged-Token or $EAT-CBOR-Untagged-Token. EAT indirectly discusses the security of an externally defined nested token. It says it is bound into the surrounding token by being a nested token (section 4.2.18.3.) which is what applies here. It also says "i.e., it has keys distinct from the attester producing the surrounding token” which doesn’t apply here. I’m OK with it as is, but also open to changes in EAT or UCCS. LL > On Aug 29, 2023, at 10:13 AM, Thomas Fossati <[email protected]> wrote: > > Hi UCCS authors, > > It looks that the assumption is that since UCCS drops the COSE > envelope there must be a semantically equivalent "secure channel" > provided via a transport / object security primitive that replaces > COSE's services. > > I'd like to point out another possible use of UCCS is to implement > what EAT calls a "detached claims-set". > > We are experimenting with that for confidential compute workload > attestation (see [1]). But the mechanism is generally applicable when > stacking claims-sets in hierarchical attesters. > > For example, we use UCCS as a "sidecar token" that is coupled (using > an EAT collection [2] rather than a DEB) to a "main," signed EAT that > contains the UCCS's digest in one of its claims. Note that this is > not in contradiction with EAT, in fact §4.2.18.2 of -21 has: > > [...] EAT, however, doesn't require use of a detached > EAT bundle. Any other protocols may be used to convey detached > claims sets and the EAT containing the corresponding detached > digests. > > It looks like this case is not discussed in the current draft. > So my question is: should it? Or should a different draft document > such practice? > > I read §3 of UCCS: > > [...] As UCCS were initially created for use in RATS Secure Channels, the > following section provides a discussion of their use in these > channels. Where other environments are intended to be used to convey > UCCS, similar considerations need to be documented before UCCS can be > used. > > to support the latter, and that's OK, but then I reckon we should be a > bit more precise in the scoping parts of the doc (abstract, intro, > title) to be explicit about this "pre-existing secure channel" > assumption. > > For example, this sentence in the abstract "[…] discusses conditions > for its proper use" could be "discusses its use over pre-established > secure channels". There are a few other places where this kind of > surgery could be made as well. > > Other than that, I think the document is in very good shape and ready to ship. > > cheers, thanks > > [1] > https://github.com/CCC-Attestation/attested-tls-poc/blob/main/doc/parsec-evidence-cca.md > [2] https://datatracker.ietf.org/doc/draft-frost-rats-eat-collection/ > > On Sat, Aug 26, 2023 at 1:44 PM Kathleen Moriarty > <[email protected]> wrote: >> >> Greetings! >> >> The working group last call for >> https://datatracker.ietf.org/doc/draft-ietf-rats-uccs/ >> begins now and will run for 4 weeks per discussion at the IETF 117 meeting. >> Review requests are also requested from COSE working group members. Last >> call ends 9/23/2023. >> >> There are a few remaining questions that I need assistance from authors on >> prior to IETF last call. Could each author and others with knowledge of IPR >> please disclose any at this time as well. >> >> Thank you! >> >> -- >> >> Best regards, >> Kathleen >> _______________________________________________ >> RATS mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/rats > > > > -- > Thomas > > _______________________________________________ > COSE mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/cose _______________________________________________ COSE mailing list [email protected] https://www.ietf.org/mailman/listinfo/cose
