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

[Roman Danyliw <[e-mail]>]

Hi!

I'm checking on the next steps on draft-ietf-rats-uccs.  Could the feedback below please be addressed.

Roman

> -----Original Message-----
> From: Roman Danyliw
> Sent: Monday, March 18, 2024 7:49 PM
> To: [e-mail]
> Subject: AD follow-up review of draft-ietf-rats-uccs-09
> 
> 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.  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.”
> 
> [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.
> 
> 
> ** 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..
> 
> Roman