Here's the paragraph in 9334 that uses 'secure channel': "Conceptual messages (see Section 8) carrying sensitive or confidential information are expected to be integrity protected (i.e., either via signing or a secure channel) and optionally might be confidentiality protected via encryption. If there isn't confidentiality protection of conceptual messages themselves, the underlying conveyance protocol should provide these protections."
The UCCS usage context should echo the above assumption that integrity and possibly confidentiality of conceptual messages is protected by some form of wrapper technology if it isn't provided as part of the conceptual message itself. A detached signature is still a form of a conceptual message. A conceptual message that is wrapped by another conceptual message is still a form of a conceptual message. A conceptual message containing a "detatched claimset" is also a form of a conceptual message. Cheers, Ned (not as co-chair) On 8/29/23, 10:17 AM, "RATS on behalf of Thomas Fossati" <[email protected] <mailto:[email protected]> on behalf of [email protected] <mailto:[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 <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/ <https://datatracker.ietf.org/doc/draft-frost-rats-eat-collection/> On Sat, Aug 26, 2023 at 1:44 PM Kathleen Moriarty <[email protected] <mailto:[email protected]>> wrote: > > Greetings! > > The working group last call for > https://datatracker.ietf.org/doc/draft-ietf-rats-uccs/ > <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] <mailto:[email protected]> > https://www.ietf.org/mailman/listinfo/rats > <https://www.ietf.org/mailman/listinfo/rats> -- Thomas _______________________________________________ RATS mailing list [email protected] <mailto:[email protected]> https://www.ietf.org/mailman/listinfo/rats <https://www.ietf.org/mailman/listinfo/rats> _______________________________________________ COSE mailing list [email protected] https://www.ietf.org/mailman/listinfo/cose
