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

[Kathleen Moriarty <[e-mail]>]

Hey Roman,

I am bringing this message back to the top of your inbox.

Thank you!
Kathleen
(Shepherd)

On Thu, Jul 4, 2024 at 3:11 AM Carsten Bormann <[e-mail]> wrote:

> 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
>
> _______________________________________________
> RATS mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
>


-- 

Best regards,
Kathleen