Re: [Gen-art] [lamps] Genart last call review of draft-ietf-lamps-hash-of-root-key-cert-extn-03

"Joel M. Halpern" <jmh@joelhalpern.com> Sat, 05 January 2019 03:10 UTC

Return-Path: <jmh@joelhalpern.com>
X-Original-To: gen-art@ietfa.amsl.com
Delivered-To: gen-art@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C4840130DD1; Fri, 4 Jan 2019 19:10:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.701
X-Spam-Level:
X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.com
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 hxFNwSzyW6N0; Fri, 4 Jan 2019 19:10:17 -0800 (PST)
Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 78DAB130DCD; Fri, 4 Jan 2019 19:10:17 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 43WmqY1dP8z27fjx; Fri, 4 Jan 2019 19:10:17 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1546657817; bh=VO3P+fkz+6gtNA7oOGLEuvYpWYO1oPpnfQZkIpXPreA=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=nBdmH1XRnNb+7CSi5S3FeM0uWs8LxRLrML0He6HOxMHdzRAZXWDah6n0maMKiWZZ1 +VrMzI7e874BUopITYYMnehugiVcowr6hLxxyribJrkfsr5CMQPUmpx/kKANn5Ar6M OAO2UN4H2N3j3iX1RLEebKubsCK530v9QMVATGXY=
X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net
Received: from Joels-MacBook-Pro.local (209-255-163-147.ip.mcleodusa.net [209.255.163.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id 43WmqX2qncz27fjG; Fri, 4 Jan 2019 19:10:16 -0800 (PST)
To: Russ Housley <housley@vigilsec.com>
Cc: LAMPS WG <spasm@ietf.org>, IETF Gen-ART <gen-art@ietf.org>, draft-ietf-lamps-hash-of-root-key-cert-extn.all@ietf.org, IETF <ietf@ietf.org>
References: <20190105000017.C97DF130EA8@ietfa.amsl.com> <19CF295C-85C1-4692-896F-D89C7DD58581@vigilsec.com>
From: "Joel M. Halpern" <jmh@joelhalpern.com>
Message-ID: <838a234a-d069-7f0a-4d3d-2dadb0f651ff@joelhalpern.com>
Date: Fri, 4 Jan 2019 22:10:14 -0500
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.3.3
MIME-Version: 1.0
In-Reply-To: <19CF295C-85C1-4692-896F-D89C7DD58581@vigilsec.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/gen-art/bMS19kmfrBq-BjXvtoAMVbytkRU>
Subject: Re: [Gen-art] [lamps] Genart last call review of draft-ietf-lamps-hash-of-root-key-cert-extn-03
X-BeenThere: gen-art@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "GEN-ART: General Area Review Team" <gen-art.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/gen-art>, <mailto:gen-art-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/gen-art/>
List-Post: <mailto:gen-art@ietf.org>
List-Help: <mailto:gen-art-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/gen-art>, <mailto:gen-art-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 05 Jan 2019 03:10:20 -0000

I understand that the issuer has no choice.
What I can't see is how any validator will accept the new certificate.
The new cert will fail the validation check required by the field in the 
existing certificate.
So it seems that the only remedy is to wait until the exist certificate 
expires, so that the hash is no longer valid, and then a new cleann cert 
can be issued that will be accepted.

But there is no reference in the "remedy" to waiting for the expiration.
In fact, it is only imiplictly stated that the hash expectation is no 
longer valid once the certificate is expired.

Another possibility is that I am completely missing the point of the new 
field.  If the new clean unexpected cert will be accepted, what behavior 
is improved by having the hash in the current cert.

Yours,
Joel

On 1/4/19 9:41 PM, Russ Housley wrote:
> Joel:
> 
> If access to the key is lost, the commitment is broken, so the Root CA 
> must make a fresh start using a completely unrelated key.  Maybe the 
> word "remedy" is creating the wrong impression for you.
> 
> Russ
> 
> 
>> On Jan 4, 2019, at 6:42 PM, jmh.direct@joelhalpern.com 
>> <mailto:jmh.direct@joelhalpern.com> wrote:
>>
>> If the new self-signed cert uses a new key, wouldn't that be rejected 
>> as violating the promise in the current cert?  I am missing something.
>>
>> Thanks,
>> Joel
>>
>>
>>
>> Sent via the Samsung Galaxy S7, an AT&T 4G LTE smartphone
>>
>> -------- Original message --------
>> From: Russ Housley <housley@vigilsec.com <mailto:housley@vigilsec.com>>
>> Date: 1/4/19 17:57 (GMT-05:00)
>> To: Joel Halpern <jmh@joelhalpern.com <mailto:jmh@joelhalpern.com>>
>> Cc: IETF Gen-ART <gen-art@ietf.org <mailto:gen-art@ietf.org>>, 
>> spasm@ietf.org <mailto:spasm@ietf.org>, 
>> draft-ietf-lamps-hash-of-root-key-cert-extn.all@ietf.org 
>> <mailto:draft-ietf-lamps-hash-of-root-key-cert-extn.all@ietf.org>, 
>> IETF <ietf@ietf.org <mailto:ietf@ietf.org>>
>> Subject: Re: Genart last call review of   
>> draft-ietf-lamps-hash-of-root-key-cert-extn-03
>>
>> Joel:
>>
>> Thanks for the review.
>>
>> > Document: draft-ietf-lamps-hash-of-root-key-cert-extn-03
>> > Reviewer: Joel Halpern
>> > Review Date: 2019-01-04
>> > IETF LC End Date: 2019-01-10
>> > IESG Telechat date: Not scheduled for a telechat
>> >
>> > Summary: This draft is nearly ready for publication as an 
>> Informational RFC.
>> >
>> > Major issues: N/A
>> >
>> > Minor issues:
>> >    The explanation at the end of section 5 about the remedy for 
>> losing access
>> >    to the new root key left me confused.
>> > It looks like the situation is that there is a certificate out 
>> there, with the
>> > hash of root key extensions. The certificate owner loses access to 
>> the new key
>> > pair underlying the hash. The certificate owner clearly has to issue 
>> a new key
>> > pair.  So far, so good.
>> >
>> > What the text seems to say is to simply issue a new self-signed 
>> certificate.
>> > There are two possibilities for what is intended. I think the idea 
>> is that the
>> > new certificate will use the existing key pair (not the promised 
>> one, nor
>> > another new one) for its own signature, and include a new hash of 
>> root key for
>> > the newly generated pair.  If the certificate owner can do that (I 
>> have not
>> > dived into the rest of the certificate operations to figure out if 
>> that is
>> > legal) then it works.  Please add some words explaining that better. 
>> If the
>> > certificate owner can not simply issue a new self-signed certificate 
>> with the
>> > existing key pair, then I am lost.  It appears that the text says 
>> that the
>> > certificate owner issues a new self-signed certificate using a new 
>> key pair.
>> > But that will fail the check against the previous certificate hash 
>> of root key.
>> > I am hoping that it is the first of these alternatives, and all that 
>> is needed
>> > is clearer explanatory text stating that the new cert uses the 
>> existing key
>> > pair, and includes a new hash of root key promise.
>>
>> Joel, the Root CA want to start using a different key par, but they 
>> have lost access to the one that was previously generated for that 
>> purpose.  So, the remedy is to create a new self-signed certificate 
>> with a newly generated key.
>>
>> Does that help?  If so, what would make the paragraph more clear?
>>
>> Russ
>>
>> _______________________________________________
>> Spasm mailing list
>> Spasm@ietf.org <mailto:Spasm@ietf.org>
>> https://www.ietf.org/mailman/listinfo/spasm
>