Re: [Rats] Working Group Last Call for UCCF draft

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

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" <[e-mail] <mailto:[e-mail]> on behalf of [e-mail] <mailto:[e-mail]>> 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
<[e-mail] <mailto:[e-mail]>> 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
> [e-mail] <mailto:[e-mail]>
> https://www.ietf.org/mailman/listinfo/rats <https://www.ietf.org/mailman/listinfo/rats>






-- 
Thomas


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