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

Jim Schaad <> Tue, 06 November 2018 03:32 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 52B4B130DD1; Mon, 5 Nov 2018 19:32:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.901
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id AT86fNNmZXDi; Mon, 5 Nov 2018 19:32:52 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id EEFE1130E1C; Mon, 5 Nov 2018 19:32:48 -0800 (PST)
Received: from Jude ( by ( with Microsoft SMTP Server (TLS) id 15.0.1347.2; Mon, 5 Nov 2018 19:27:54 -0800
From: Jim Schaad <>
To: <>
CC: <>
References: <>
In-Reply-To: <>
Date: Tue, 6 Nov 2018 10:32:37 +0700
Message-ID: <014401d47581$5fe919d0$1fbb4d70$>
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: []
Archived-At: <>
Subject: Re: [lamps] WG Last call: draft-ietf-lamps-hash-of-root-key-cert-extn
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-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

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