Re: [Curdle] FW: New Version Notification for draft-ietf-curdle-pkix-04.txt

Jim Schaad <> Sun, 30 April 2017 09:30 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id AF366129413 for <>; Sun, 30 Apr 2017 02:30:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 0.699
X-Spam-Status: No, score=0.699 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 7bQ2Ymea0mSy for <>; Sun, 30 Apr 2017 02:30:37 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 932E31293F9 for <>; Sun, 30 Apr 2017 02:28:36 -0700 (PDT)
Content-Type: multipart/alternative; boundary="----=_NextPart_000_006E_01D2C1A4.D2258FC0"
Content-Language: en-us
DKIM-Signature: v=1; a=rsa-sha256;; s=winery; c=simple/simple; t=1493544509; h=from:subject:to:date:message-id; bh=OyM0RKs68dV59op891ei5pGcz0mBR2qlchyRIw7W2zk=; b=GrQ5gM7JLL5am2M5hG9wb8JGTZ22sFR3KgtQEqcfw9SqI6El4kDJhcKkADUi8ajg7YqejtfVJF+ x6yV/NVQAO38suV+vTY1WQsDvXhUapn5j9khTl6qG2i+nlhXREu27tXn6ZhXqvpKvtW4or9Y0Ftk4 aDKNGbnCGMryO593dWVRQ7W8/p1wMjBA7AYTpWelL07Meh/PlwM7pbmg3ut2553zulqTblmakYNCd nUJV1SkRjDU1XlazWGxYC4OdKj8LwQWC1q9/3AMvDKhSDroS04xgzpci3extxDw+61c8/cGGLXkkx WCuP/1zRluyF+c65aKB7G5VyQWnRBA3Krzhg==
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.1263.5; Sun, 30 Apr 2017 02:28:28 -0700
Received: from Hebrews ( by ( with Microsoft SMTP Server (TLS) id 15.0.1263.5; Sun, 30 Apr 2017 02:28:21 -0700
From: Jim Schaad <>
To: 'Brian Smith' <>
CC: 'curdle' <>
References: <> <051401d2a80b$e9bdea90$bd39bfb0$> <>
In-Reply-To: <>
Date: Sun, 30 Apr 2017 11:27:55 +0200
Message-ID: <006d01d2c194$0e99b280$2bcd1780$>
MIME-Version: 1.0
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AQEf37CDGDDCSU9BXbxVbCIypDLQdwJ1Iy/iAhSOZKujHw7JsA==
X-Originating-IP: []
Archived-At: <>
Subject: Re: [Curdle] FW: New Version Notification for draft-ietf-curdle-pkix-04.txt
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "List for discussion of potential new security area wg." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sun, 30 Apr 2017 09:30:39 -0000



From: Brian Smith [] 
Sent: Sunday, April 30, 2017 3:31 AM
To: Jim Schaad <>
Cc: curdle <>
Subject: Re: [Curdle] FW: New Version Notification for draft-ietf-curdle-pkix-04.txt


Jim Schaad < <> > wrote:

Here is the promised updated draft.
> URL:  
> Status:
> Htmlized:
> Htmlized:
> Diff: 


I started implementing this this weekend and I noticed that this is the only private key format for which it is impossible to implement a useful pairwise consistency check. In one sense, a consistency check isn't necessary because the public key is computed from the private key, so there's no room for inconsistency. On the other hand, there's no way to detect corruption of the private key like you can with RSA and ecPublicKey keys, when the key is stored in the unencrypted form. I think this is really unfortunate.


[JLS] It is true that RSA has this as a built in feature, however it is not true for all of the key formats that are in common use today.  The same structure is used here as is used for traditional DH keys.  The ability to do check that the public and private keys match is something that is possible, but is frequently not done even for RSA keys.  Additionally, there are cases where it is less expensive to re-compute the public key than to transport it.  It is not always possible to detect corruption when you store in an unencrypted form.  It would also not be possible to know if it was the private key or the public key that has been corrupted, just that the two values do not match.


It is possible to use a v2 PKCS#8 encoding that adds the publicKey component, in which case one can then implement an integrity check.


However, unless this is documented in the draft one way or another as a MUST accept or a MUST NOT generate, I think it will be an interop nightmare. In particular, we should avoid the situation where some implementations produce v2 keys so they can add the publicKey field, and where other implementations reject v2 keys because they only parse v1, where the publicKey field isn't allowed.


[JLS]  I have not heard that this is an issue today with DH keys.  This makes me think that this is not going to be a big issue.  I expect that most implementations would all for parsing v2 keys even if they then ignore the public key field.


In particular, it is important for the spec to include v2 PKCS#8 examples with the publicKey field, if such encoding is allowed.


[JLS] This is a reasonable request.  I will look at adding this as part of the IETF last call comments.


I also found that, if the publicKey field is included, and one tries to do pairwise validation of the private key and public key, there are a few special cases that should be documented as test vectors.


[JLS] Please be more explicit on what you believe are the special cases that need to be highlighted.  The cases that immediately come to mind for me are the question of correct form for the values, but that is not an encoding problem but an issue with the library being used.  Are there others that you have in mind?