[secdir] Secdir last call review of draft-ietf-cbor-edn-literals-09

Rifaat Shekh-Yusef via Datatracker <noreply@ietf.org> Mon, 27 May 2024 14:10 UTC

MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Rifaat Shekh-Yusef via Datatracker <noreply@ietf.org>
To: secdir@ietf.org
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <171681904824.4732.13257098186796399236@ietfa.amsl.com>
Message-ID-Hash: LX2HUWOJFMUD6D3ENC67B32CQWDICK43
CC: cbor@ietf.org, draft-ietf-cbor-edn-literals.all@ietf.org, last-call@ietf.org
Reply-To: Rifaat Shekh-Yusef <rifaat.s.ietf@gmail.com>
Subject: [secdir] Secdir last call review of draft-ietf-cbor-edn-literals-09
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/mJ48Y2vyRoNSnHfXR12tsz0lo7U>
Date: Tue, 28 May 2024 07:47:23 -0000

Reviewer: Rifaat Shekh-Yusef
Review result: Has Nits

In CBOR, Extended Diagnostic Notation (EDN) is a diagnostic format, that is
used to facilitate documentation and debugging.

RFC8949, section 8, explicitly states these diagnostics are not meant to be
parsed, which means that these diagnostics do not introduce any new security
issues.

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.

[secdir] Secdir last call review of draft-ietf-cb… Rifaat Shekh-Yusef via Datatracker
[secdir] Re: [Cbor] Secdir last call review of dr… Carsten Bormann