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

[Jim Schaad <[e-mail]>]

 

 

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

 

Jim Schaad <[e-mail] <mailto:[e-mail]> > wrote:

Here is the promised updated draft.
> URL:            https://www.ietf.org/internet-drafts/draft-ietf-curdle-pkix-04.txt
> Status:         https://datatracker.ietf.org/doc/draft-ietf-curdle-pkix/
> Htmlized:       https://tools.ietf.org/html/draft-ietf-curdle-pkix-04
> Htmlized:       https://datatracker.ietf.org/doc/html/draft-ietf-curdle-pkix-04
> Diff:           https://www.ietf.org/rfcdiff?url2=draft-ietf-curdle-pkix-04

 

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?

 

Jim

 

 

Cheers,

Brian