Re: [lamps] WG Last call: draft-ietf-lamps-hash-of-root-key-cert-extn
Jim Schaad <ietf@augustcellars.com> Tue, 06 November 2018 10:13 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 072281277C8 for <spasm@ietfa.amsl.com>; Tue, 6 Nov 2018 02:13:30 -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 kitJsOOViRz4 for <spasm@ietfa.amsl.com>; Tue, 6 Nov 2018 02:13:27 -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 7596B129AB8 for <spasm@ietf.org>; Tue, 6 Nov 2018 02:13:27 -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; Tue, 6 Nov 2018 02:08:32 -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> <016001d4758c$67daa2c0$378fe840$@augustcellars.com> <0871B813-F7BE-470D-AE97-6F5B62CDA7C3@vigilsec.com>
In-Reply-To: <0871B813-F7BE-470D-AE97-6F5B62CDA7C3@vigilsec.com>
Date: Tue, 06 Nov 2018 17:13:15 +0700
Message-ID: <019601d475b9$578c9ea0$06a5dbe0$@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+Ca89z5ljDodd25QLXeOc8AOBEjwsBky5VHwI0uZGRpBfxJqA=
Content-Language: en-us
X-Originating-IP: [31.133.136.100]
Archived-At: <https://mailarchive.ietf.org/arch/msg/spasm/Ja72vNBwX6hqyoQP4AKLznd1seI>
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 10:13:30 -0000
> -----Original Message----- > From: Russ Housley <housley@vigilsec.com> > Sent: Tuesday, November 6, 2018 4:44 PM > 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. > > 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... Since it was not obvious to me, then yes the hint should be included. > > > > >> > >>> * 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. If I can second preimage the hash algorithm, for some signature algorithms I would be able to do the compromise. It was odd to me that this was not noted but I would not insist on 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? > > > > 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. No importing that both would not solve your problem or be useful. Jim > > Russ
- [lamps] WG Last call: draft-ietf-lamps-hash-of-ro… Tim Hollebeek
- Re: [lamps] WG Last call: draft-ietf-lamps-hash-o… Russ Housley
- Re: [lamps] WG Last call: draft-ietf-lamps-hash-o… Tim Hollebeek
- Re: [lamps] WG Last call: draft-ietf-lamps-hash-o… Salz, Rich
- Re: [lamps] WG Last call: draft-ietf-lamps-hash-o… Russ Housley
- Re: [lamps] WG Last call: draft-ietf-lamps-hash-o… Jim Schaad
- Re: [lamps] WG Last call: draft-ietf-lamps-hash-o… Jim Schaad
- Re: [lamps] WG Last call: draft-ietf-lamps-hash-o… Russ Housley
- Re: [lamps] WG Last call: draft-ietf-lamps-hash-o… Jim Schaad
- Re: [lamps] WG Last call: draft-ietf-lamps-hash-o… Russ Housley
- Re: [lamps] WG Last call: draft-ietf-lamps-hash-o… Russ Housley
- Re: [lamps] WG Last call: draft-ietf-lamps-hash-o… Jim Schaad
- Re: [lamps] WG Last call: draft-ietf-lamps-hash-o… Russ Housley
- Re: [lamps] WG Last call: draft-ietf-lamps-hash-o… Jim Schaad