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

[Carsten Bormann <[e-mail]>]

Hi Roman,

apologies for the slow reply, and even more so for replying on July 4.

We created a -10 from the input we received on -09:

HTML:     https://www.ietf.org/archive/id/draft-ietf-rats-uccs-10.html
Diff:     https://author-tools.ietf.org/iddiff?url2=draft-ietf-rats-uccs-10

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.  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.

You didn’t cite the rest of that sentence, "beyond the information the Secure Channel authentication provides.”.
The objective here can be that this authentication be ephemeral.
So the receiver can authenticate (an identity of) the sender, but cannot stash away a third-party verifiable representation of a signed statement that the sender has made.  Avoiding the creation of such a representation may be the main point of doing authentication in a Secure Channel as opposed to via object security (i.e., in a CWT).

> [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.

I don’t think we want to discuss the example I gave in the email, authentication via group keys, in the document; such an application probably should come with its own, more specific, instruction leaflet (as should other examples, such as batch-endorsed single-use keys).
But CWT also can use group keys (or single-use keys), so the situation is not that fundamentally different, except that the authentication with these on a Secure Channel can be ephemeral.
(E.g., while it is already possible to use a group key or some kind of "DAA issued certificate" to establish a Secure Channel, such a procedure is out-of-scope of this document as it implies the issuance of endorsed keys of this kind in the first place. With a future specification that builds on, say, the RATS DAA I-D when it becomes an RFC, an additional document addressing the use of such endorsed keys could become a thing.  It seems pretty clear that the particulars of using group keys or similar to authenticate any end of a Secure Channel are out-of-scope of this specification.)

> ** 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..

The text introducing Figure 1 now reads:

>> In Figure 1, this specification shows how to use CDDL for defining the CWT Claims Set defined in [RFC8392]. Note that these CDDL rules have been built such that they also can describe [RFC7519] Claims sets by disabling feature "cbor" and enabling feature "json", but this flexibility is not the subject of the present specification.

We added “This appendix is informative”, as it does not preempt the definitions in RFC 8392, but provides a directly usable CDDL form of them.
And while it is doing that, it does the same for RFC 7519 Claims Sets, as that is easy to include.

Grüße, Carsten