[Rats] Re: AD follow-up review of draft-ietf-rats-uccs-09

[Carsten Bormann <[e-mail]>]

Hi Roman,

thank you for the reminder, and apologies for losing track of this in the post-119 shuffle.

We prepared an PR #29 [29] [29f] for the changes we think are needed.

[29]: https://github.com/ietf-rats-wg/draft-ietf-rats-uccs/pull/29
[29f]: https://github.com/ietf-rats-wg/draft-ietf-rats-uccs/pull/29/files

On 2024-03-19, at 00:49, Roman Danyliw <[e-mail]> wrote:
> 
> Hi!
> 
> I previously performed an AD review on draft-ietf-rats-uccs-08.  See https://mailarchive.ietf.org/arch/msg/rats/HU2eIC7AevBSBHGk5tqXSR8wMco/.  Thanks for -09.  For ease of tracking issues, this new email summaries the remaining issues from AD Review.
> 
> 
> ** Section 6.
>  The security
>  considerations of [RFC8392] need to be applied analogously, replacing
>  the function of COSE with that of the Secure Channel. 
> 
> [per -08] 
> If all of the Security Considerations of RFC8392 apply, then there is an authenticity requirement for the Secure Channel.  

Indeed, and -09 makes this much more explicit now.

> RFC8392 says “it is not only important to protect the CWT in transit but also to ensure that the recipient can authenticate the party that assembled the claims and created the CWT.”  

This is a great sentence that we decided to add as a quote in line 359/360.

> [per -08] the Privacy Preserving channel of Section 4.3 (Section 5.3 in -09) seems to explicitly suggest that there “receiver cannot correlate the message with the senders of other received UCCS messages “ which seems to be the opposite of authenticity.
> 
> [response]
>> The objective of 4.3 (now 5.2) is to discuss how authenticity does not 
>> necessarily lead to linkability.
>> It does not relax the authenticity requirement.
>> (E.g., DAA replaces the attester key with a group key, and something 
>> similar could be a use case for secure channels as well.)
> 
> [Roman] Can this nuance please be explained in the prose.  This seems to be a very different situation than authenticity in the CWT sense.

We added "beyond the information the secure channel authentication provides” (Line 320..323) — if the authentication only pertains to a group, the information will be limited to be about membership of that group.

> ** Appendix A.  Excuse my rough understanding of CDDL.  
> 
> -- [per -08] My read of this CDDL is that there is JSON hooks included with the JC<> construct.  This JSON binding isn’t explained any place else.
> 
>> Yes.
>> Parts about JSON bindings do not use normative language, 
>> because UCCS is 
>> about CBOR claim sets.
>> This CDDL is designed to be useful in a mixed environment, based on 
>> requirements from EAT.
> 
> I don’t understand.  This CDDL in Appendix A is normative, and so is the flexibility in its design to support JSON.  Otherwise, it would be “C< ...>” and not “JC<...>”.  I don’t take exception with providing a JSON binding but please explain this in the prose and in the introduction..

We now made it explicit that this is there as “CDDL you can use” — a normative intent when actually using this is desirable but the CDDL itself is not changing the specifications in any way, hence it is an informative appendix.  Line 462..465.

Grüße, Carsten