Subject: [secdir] Re: [Cbor] Secdir last call review of draft-ietf-cbor-edn-literals-09
From: Carsten Bormann <[email-masked]>
To: Rifaat Shekh-Yusef <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked], [email-masked]
Date: Wed, 3 Jul 2024 22:13:52 +0200
List-Id: Security Area Directorate <secdir.ietf.org>

On 2024-05-27, at 16:10, Rifaat Shekh-Yusef via Datatracker <[email-masked]> wrote:
> 
> This document describes how to add application specific extensions to EDN. The
> security section of this draft does not discuss the implication of this
> directly, but instead points to RFC8610 and RFC8949. Because, as stated above,
> these diagnostics are not meant to be parsed, this document implies that there
> are no new security implications associated with these new extensions.
> 
> If this is the case, it would be nice to add a sentence or two to help the
> reader get to this conclusion directly, instead of just pointing the reader to
> the other documents.

Hi Rifaat,

thank you for pointing out this gap.
Extensions exercising these extension points can very well have their own security considerations, as exemplified already by the next two application-extensions in the pipeline, e’’ and ref’’ [1].

[1]: https://www.ietf.org/archive/id/draft-ietf-cbor-edn-e-ref-00.html#name-security-considerations

We added some text about this in PR #50 [50], explaining how tool implementers and operators may need to be considerate of security implementations posed by the extensions they support.

[50]: https://github.com/cbor-wg/edn-literal/pull/50/files

This PR is merged and slated to be part of the next revision draft-ietf-cbor-edn-literal-10.

Grüße, Carsten