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

Jim Schaad <ietf@augustcellars.com> Tue, 06 November 2018 03:32 UTC

Return-Path: <ietf@augustcellars.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 52B4B130DD1; Mon, 5 Nov 2018 19:32:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] 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 AT86fNNmZXDi; Mon, 5 Nov 2018 19:32:52 -0800 (PST)
Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EEFE1130E1C; Mon, 5 Nov 2018 19:32:48 -0800 (PST)
Received: from Jude (31.133.136.100) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Mon, 5 Nov 2018 19:27:54 -0800
From: Jim Schaad <ietf@augustcellars.com>
To: <spasm@ietf.org>
CC: <draft-ietf-lamps-hash-of-root-key-cert-extn@ietf.org>
References: <BN6PR14MB1106CF89BEC31A9D837A3A5383F30@BN6PR14MB1106.namprd14.prod.outlook.com>
In-Reply-To: <BN6PR14MB1106CF89BEC31A9D837A3A5383F30@BN6PR14MB1106.namprd14.prod.outlook.com>
Date: Tue, 6 Nov 2018 10:32:37 +0700
Message-ID: <014401d47581$5fe919d0$1fbb4d70$@augustcellars.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AQJLwZVoNyKH0k+Ca89z5ljDodd25aRTYgQg
Content-Language: en-us
X-Originating-IP: [31.133.136.100]
Archived-At: <https://mailarchive.ietf.org/arch/msg/spasm/7t9e5bASFwGDo2x2JhlXYnPZHFw>
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:32:55 -0000

* 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.'

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

* 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.

* 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?

* 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).

* 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.

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

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

Jim