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

Russ Housley <housley@vigilsec.com> Tue, 06 November 2018 09:44 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 63051130F4D for <spasm@ietfa.amsl.com>; Tue, 6 Nov 2018 01:44:52 -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 VTS5aJOQTzMS for <spasm@ietfa.amsl.com>; Tue, 6 Nov 2018 01:44:50 -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 D254B130F99 for <spasm@ietf.org>; Tue, 6 Nov 2018 01:44:49 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 2CA29300AA6 for <spasm@ietf.org>; Tue, 6 Nov 2018 04:44:47 -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 XyNn72dknZ_s for <spasm@ietf.org>; Tue, 6 Nov 2018 04:44:45 -0500 (EST)
Received: from dhcp-8a9b.meeting.ietf.org (dhcp-8a9b.meeting.ietf.org [31.133.138.155]) by mail.smeinc.net (Postfix) with ESMTPSA id E0C6E300A11; Tue, 6 Nov 2018 04:44:44 -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: <016001d4758c$67daa2c0$378fe840$@augustcellars.com>
Date: Tue, 6 Nov 2018 04:43:52 -0500
Cc: SPASM <spasm@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <0871B813-F7BE-470D-AE97-6F5B62CDA7C3@vigilsec.com>
References: <BN6PR14MB1106CF89BEC31A9D837A3A5383F30@BN6PR14MB1106.namprd14.prod.outlook.com> <014401d47581$5fe919d0$1fbb4d70$@augustcellars.com> <7104A92B-DC98-4E58-A50A-D470E8E4A0B9@vigilsec.com> <016001d4758c$67daa2c0$378fe840$@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/1XTzvC9SeNPfn7kG0-aWG2ZYoSU>
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 09:44:59 -0000

Jim:
>>> 
>>> * 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?
> 
> When you install the new one, I don't believe that you are going to remove
> the old one.  There are still going to be valid certificates running around
> that will chain to the old root until you have done all of the issuing of
> certificates to the new root.  This is going to take time.  Additionally, if
> you are looking at something like the mail case you want to keep the old
> root but mark it as being "expired" so that you can validate the chain of
> certificates. 

If one follows the old-with-new and new-with-old advice in RFC 2510, then the replacement should not cause any disruption.  If you think it is useful, an operational consideration about this can be added.

> This means that it might be some time before the old one is removed.  

It should not need to linger...

> 
>> 
>>> * 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?
> 
> But why are you not making the determination of the signature algorithm that
> is going to be used by the new key at the same time that you are generating
> it. 

The hash is computed on the SubjectPublicKeyInfo, so it includes the algorithm identifier.

> The new key could be an ECDSA key of a longer length than the previous key.
> This would be appropriately reflected and checked.  The issue is that the CA
> does not say what the signature algorithm is.  This means that I might be
> able to attack by using a signature algorithm that is weaker than what the
> CA intended it to be.  For algorithm where the signature OID and the public
> key OID are the same, this is not possible.  However for algorithms where
> that is not the case it is a possible way for an attack to be pushed
> forward.

Right, the algorithm identifier of the public key is nailed down, but other details are not.  I do not see a way to exploit this without the private key being compromised.  Such a compromise would, of course, have many more issues to sort out.

> 
>>> * 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?
> 
> Actually it does not say what you think it says.  What it does is define a
> new item in this document which contains a list of extensions with one item
> in it.  It does not modify the version of CertExtensions in RFC5912 in any
> way.  If that is what is desired then this item has to be imported into RFC
> 5912 and added to the CertExtensions variable in that module.

I realize that, which is the reason for the comment in the ASN.1.

> No there is no reason to remove it, it is just some slight cruft.

Would it help an implementer to add the IMPORT?  My experience is that sucks in a whole bunch of other ASN.1 modules that are not necessarily helpful to the guy writing code.

Russ