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

"jmh.direct@joelhalpern.com" <jmh.direct@joelhalpern.com> Sat, 05 January 2019 00:00 UTC

Return-Path: <jmh.direct@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 53DDE130EB4; Fri, 4 Jan 2019 16:00:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level:
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, 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 5X0NDHvEfMVv; Fri, 4 Jan 2019 16:00:17 -0800 (PST)
Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) (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 C97DF130EA8; Fri, 4 Jan 2019 16:00:14 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 43WhcG2VWWzpbmd; Fri, 4 Jan 2019 16:00:14 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1546646414; bh=34302JSCjLQyPOFWNtXjo2k1dV25NOD1OBKF/EigSxE=; h=Date:Subject:In-Reply-To:From:To:Cc:From; b=m6yoCEvPeXwwcPfCpOtmN5iARplK5+gJZkRIbvHIn/b7R2fqPrEpp9w9IUN94Y1Yp IGwf0XMjgb7E6t9bd4HkoFTHL/ZTD415al3049oOj2ngIelvBnCtuP8TMOO46Zi0eB TzJw2rUtRIN6z6moVHpskGRrIdn0kjD2GA9o/ND8=
X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net
Received: from [IPv6:2600:380:1877:75b1:bcac:e14f:943e:9b2d] (unknown [IPv6:2600:380:1877:75b1:bcac:e14f:943e:9b2d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id 43Whc14jRZzpblx; Fri, 4 Jan 2019 16:00:01 -0800 (PST)
SavedFromEmail: jmh.direct@joelhalpern.com
Date: Fri, 04 Jan 2019 18:42:09 -0500
In-Reply-To: <FD1B2E3C-682E-4B2B-84EE-1B5E3A8A386E@vigilsec.com>
Importance: normal
From: "jmh.direct@joelhalpern.com" <jmh.direct@joelhalpern.com>
To: Russ Housley <housley@vigilsec.com>, Joel Halpern <jmh@joelhalpern.com>
Cc: IETF Gen-ART <gen-art@ietf.org>, spasm@ietf.org, draft-ietf-lamps-hash-of-root-key-cert-extn.all@ietf.org, IETF <ietf@ietf.org>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="--_com.samsung.android.email_532330076118780"
Message-Id: <20190105000017.C97DF130EA8@ietfa.amsl.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/gen-art/ASSLnosDgqa23ZUSvOdS9JjBDD8>
Subject: Re: [Gen-art] 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 00:00:20 -0000

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>; Date: 1/4/19  17:57  (GMT-05:00) To: Joel Halpern <jmh@joelhalpern.com>; Cc: IETF Gen-ART <gen-art@ietf.org>;, spasm@ietf.org, draft-ietf-lamps-hash-of-root-key-cert-extn.all@ietf.org, IETF <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