[secdir] Secdir last call review of draft-ietf-emu-eaptlscert-06

Stefan Santesson via Datatracker <noreply@ietf.org> Thu, 29 October 2020 23:13 UTC

Return-Path: <noreply@ietf.org>
X-Original-To: secdir@ietf.org
Delivered-To: secdir@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D90363A09D1; Thu, 29 Oct 2020 16:13:02 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Stefan Santesson via Datatracker <noreply@ietf.org>
To: <secdir@ietf.org>
Cc: last-call@ietf.org, draft-ietf-emu-eaptlscert.all@ietf.org, emu@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 7.21.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <160401318284.11167.6795105917637378641@ietfa.amsl.com>
Reply-To: Stefan Santesson <stefan@aaa-sec.com>
Date: Thu, 29 Oct 2020 16:13:02 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/RORLtuSIIoD9c6XOu4f2jtiLejM>
Subject: [secdir] Secdir last call review of draft-ietf-emu-eaptlscert-06
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.29
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/secdir/>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 29 Oct 2020 23:13:03 -0000

Reviewer: Stefan Santesson
Review result: Has Nits

The document in general is good and well written.

Some nits needs attention before publication as the general review also points
out. Ex in the abstract "This document looks at the this problem"

Some abbreviations needs to be spelled out at first usage, such as MTU (Maximum
Transmission Unit)

On the content itself I have two questions:

- Wouldn't it be relevant to also discuss the risks with regard to introduction
of quantum safe crypto, if that leads to significantly increased key sizes? It
could be troublesome if transition to a safer crypto is made impossible due to
size limitations. - Would it be relevant to discuss usage of AIA extension as
means of possibly excluding intermediary certs from the path as they could be
located using AIA?

Finally, I agree with the general review that this document reference quite
some work in progress. If this document is to be published before these
referenced works are concluded, are there alternatives to make the same point?