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

Jim Schaad <ietf@augustcellars.com> Tue, 06 November 2018 04:51 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 A3C26130F3E for <spasm@ietfa.amsl.com>; Mon, 5 Nov 2018 20:51:47 -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, SPF_PASS=-0.001, URIBL_BLOCKED=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 IJ3vvSvW_0Oy for <spasm@ietfa.amsl.com>; Mon, 5 Nov 2018 20:51:45 -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 AAA7E1294D0 for <spasm@ietf.org>; Mon, 5 Nov 2018 20:51:44 -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 20:46:51 -0800
From: Jim Schaad <ietf@augustcellars.com>
To: 'Russ Housley' <housley@vigilsec.com>
CC: 'SPASM' <spasm@ietf.org>
References: <BN6PR14MB1106CF89BEC31A9D837A3A5383F30@BN6PR14MB1106.namprd14.prod.outlook.com> <014401d47581$5fe919d0$1fbb4d70$@augustcellars.com> <7104A92B-DC98-4E58-A50A-D470E8E4A0B9@vigilsec.com>
In-Reply-To: <7104A92B-DC98-4E58-A50A-D470E8E4A0B9@vigilsec.com>
Date: Tue, 6 Nov 2018 11:51:35 +0700
Message-ID: <016001d4758c$67daa2c0$378fe840$@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+Ca89z5ljDodd25QLXeOc8AOBEjwukNdO7sA==
Content-Language: en-us
X-Originating-IP: [31.133.136.100]
Archived-At: <https://mailarchive.ietf.org/arch/msg/spasm/801ekr3pF27cw9yKsw0LE_C1vFA>
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 04:51:48 -0000


> -----Original Message-----
> From: Russ Housley <housley@vigilsec.com>
> Sent: Tuesday, November 6, 2018 10:59 AM
> To: Jim Schaad <ietf@augustcellars.com>
> Cc: SPASM <spasm@ietf.org>
> Subject: Re: [lamps] WG Last call: draft-ietf-lamps-hash-of-root-key-cert-
> extn
> 
> 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. 

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

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

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

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

Jim

> 
> Russ