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

[Roman Danyliw <[e-mail]>]

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