[secdir] Secdir last call review of draft-ietf-lamps-hash-of-root-key-cert-extn-03

Adam Montville <adam.w.montville@gmail.com> Tue, 08 January 2019 14:16 UTC

Return-Path: <adam.w.montville@gmail.com>
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 28D931276D0; Tue, 8 Jan 2019 06:16:12 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Adam Montville <adam.w.montville@gmail.com>
To: secdir@ietf.org
Cc: spasm@ietf.org, draft-ietf-lamps-hash-of-root-key-cert-extn.all@ietf.org, ietf@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.89.2
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <154695697211.25494.5342366287090150478@ietfa.amsl.com>
Date: Tue, 08 Jan 2019 06:16:12 -0800
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/3OArPLaaHqNTLf_GtySld-UEHwM>
Subject: [secdir] Secdir last call review of draft-ietf-lamps-hash-of-root-key-cert-extn-03
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: Tue, 08 Jan 2019 14:16:12 -0000

Reviewer: Adam Montville
Review result: Ready

This draft is ready. It's a clever (though not foolproof) way to prime the pump
for root certificate updates. I'm not an ASN.1 expert, so I can't really opine
on the structure in Section 3, but from what I can tell it looks sane.
Operational considerations seems sane. Security considerations rely on those
from RFC5280, and additionally addresses: 1) analysis before the
next-generation root certificate is released, 2) key strength considerations
(equal or greater than current), 3) unforeseen cryptoanalytic advances, 4)
typical hash pre-image attacks, and 5) early release of the next-generation
public key.

One area in the security considerations that could be enhanced is the
recommended action to take in the case of an early next-generation public key
release. The language in the draft states: "The second transition occurs when
the Root CA is confident that the population of relying parties have completed
the first transition, and it takes the Root CA to the freshly generated key
pair." The question that came to mind was: What might bring about such
confidence? I'm not sure that it's possible to generalize an answer to that
question, however.

Kind regards,

Adam