Re: [lamps] WG Last call: draft-ietf-lamps-hash-of-root-key-cert-extn

Russ Housley <housley@vigilsec.com> Tue, 06 November 2018 03:59 UTC

Return-Path: <housley@vigilsec.com>
X-Original-To: spasm@ietfa.amsl.com
Delivered-To: spasm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D50E130DCC for <spasm@ietfa.amsl.com>; Mon, 5 Nov 2018 19:59:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bdlc_3knxr3a for <spasm@ietfa.amsl.com>; Mon, 5 Nov 2018 19:59:10 -0800 (PST)
Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9C9D5127333 for <spasm@ietf.org>; Mon, 5 Nov 2018 19:59:10 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 5B587300AA6 for <spasm@ietf.org>; Mon, 5 Nov 2018 22:59:08 -0500 (EST)
X-Virus-Scanned: amavisd-new at mail.smeinc.net
Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id KOL0j1MH4jys for <spasm@ietf.org>; Mon, 5 Nov 2018 22:59:07 -0500 (EST)
Received: from dhcp-9bbe.meeting.ietf.org (dhcp-9bbe.meeting.ietf.org [31.133.155.190]) by mail.smeinc.net (Postfix) with ESMTPSA id 50E9D300523; Mon, 5 Nov 2018 22:59:06 -0500 (EST)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
From: Russ Housley <housley@vigilsec.com>
In-Reply-To: <014401d47581$5fe919d0$1fbb4d70$@augustcellars.com>
Date: Mon, 5 Nov 2018 22:59:03 -0500
Cc: SPASM <spasm@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <7104A92B-DC98-4E58-A50A-D470E8E4A0B9@vigilsec.com>
References: <BN6PR14MB1106CF89BEC31A9D837A3A5383F30@BN6PR14MB1106.namprd14.prod.outlook.com> <014401d47581$5fe919d0$1fbb4d70$@augustcellars.com>
To: Jim Schaad <ietf@augustcellars.com>
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/spasm/zCIB1Uxuhz6QWcfl_9gQbUy_QcE>
Subject: Re: [lamps] WG Last call: draft-ietf-lamps-hash-of-root-key-cert-extn
X-BeenThere: spasm@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." <spasm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/spasm>, <mailto:spasm-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/spasm/>
List-Post: <mailto:spasm@ietf.org>
List-Help: <mailto:spasm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/spasm>, <mailto:spasm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 06 Nov 2018 03:59:12 -0000

Jim:
> 
> * Abstract - I think it would be worth while to add to the last sentence 'by
> the trust anchor, it does not indicate when that trust anchor will be used.'

How about this?

   This document specifies the Hash Of Root Key certificate extension.
   This certificate extension is carried in the self-signed certificate
   for a trust anchor, which is often called a Root Certification
   Authority (CA) certificate.  This certificate extension unambiguously
   identifies the next public key that will be used by the trust anchor
   at some point in the future.

> * Section 1.2 - I hope that certificates are only generated using DER.
> Using BER is not supposed to happen.

   Certificates [RFC5280] are generated using ASN.1 [X680]; certificates
   are always encoded with the Distinguished Encoding Rules (DER)
   [X690].

> * Section 2 - I don't like the concept of saying that the new potential Root
> CA chains back to the previous CA.  The term is highly overloaded in the
> world of certificates.  I think links would be a better term.

Okay.  Changed.

> * Section 2 - What operational considerations are there for when to retire
> the old Root CA certificate when a new one has been discovered and is to be
> used?

I'm not sure what you are requesting.  Install the new one, and remove the old one?

> * Section 5? - I think that a discussion of the difference between signature
> and public key algorithms might be needed here and that in order to do the
> roll over the signature on the new self-signed cert needs to be
> "acceptable".  It might even be necessary to have a discussion of why you
> are not fixing the signature algorithm at the same time that you are fixing
> the public key value.  - Think an ECDSA new key, but it comes with an
> ECDSA-with-md5 signature algorithm (and yes I know that is not real).

A trust anchor public key is always a digital signature key.  I assume that all CAs know that.

The CA needs to ensure that the new key is as strong or stronger than the key that it is replacing.  Is there really anything more to say?

> * Section 5 - Need a discussion on what happens if the hash algorithm is
> sufficiently weakened to be able to do a second pre-image attack.  Unlikely
> but completist.

Okay.  I'll work on some text for that.

> * Section 4 - If the document makes no requests of IANA - where is the TBD
> in the OID in section 3 being resolved?

TBD = 51483

I fixed it in the ASN.1 module, but I missed it in Section 3.  I'll fix it.

> * ASN.1 module - if you don't believe that this document is going to be
> extended then making CertExtensions is redundant.

You are talking about:

   CertExtensions EXTENSION ::= {
      ext-HashOfRootKey, ... }

This is just a way of saying that the certificate extensions list in [RFC5912] has one more member.

Is there a reason to remove it?

Russ