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

[Henk Birkholz <[e-mail]>]

Hi Roman!

Just did some other WGLC items. But after a period where a bunch of 
authors were on and off PTO, I am currently carefully optimistic to 
compose feedback starting next week.


Viele Grüße,

Henk

On 23.05.24 14:53, Roman Danyliw wrote:
> 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
> _______________________________________________
> RATS mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]