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

[Brian Smith <[e-mail]>]

Jim Schaad <[e-mail]> wrote:
> Brian Smith wrote:
> > 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.

It seems to me that traditional DH keys are exceptional in this
respect. ECPrivateKey (for ECDSA and ECDH) is required to contain the
public key. RSAPrivateKey contains everything needed to validate it.

>  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.

Doing the consistency check vs. saving space is a safety trade-off.

> It is not always possible to detect corruption when you store in an unencrypted form.

What kind of corruption would we not be able to detect? It is possible
that somehow the private key could get corrupted and that there could
be a corresponding corruption to the public key such that they match
again, but this seems extremely unlikely unless somebody simply
replaced the key pair with another key pair.

> 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.

This is the case with any kind of cryptographic check, including HMAC
or whatnot.

> > 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.
>
> 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.

If that's the expectation then let's enshrine that in the spec by
saying that implementations MUST accept v2 keys for these types of
keys.

In particular, I have seen PKCS#8 implementations that reject any v2
PKCS#8 file instead of ignoring the extra fields.

> > In particular, it is important for the spec to include v2 PKCS#8
> > examples with the publicKey field, if such encoding is allowed.
>
> This is a reasonable request.  I will look at adding this as part of the IETF last call comments.

Thanks.

> 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?

I'll use X25519 as an example.

RFC 7748 says:
> When receiving such an array, implementations of X25519 (but
> not X448) MUST mask the most significant bit in the final byte."

Thus for every X25519 key, there will be at least two possible
encodings of the public key. We should have test vectors such
that both encodings of the same public key (for the same private
key) are included as separate vectors, to ensure that any
implementation that does do a pairwise consistency check
includes the masking step in the comparison.

Similarly, for ~19 X25519 keys, there are twice as many (4)
possible encodings of the public key:

1. High bit is 0, fully reduced.
2. High bit is 1, not fully reduced.
3. High bit is 0, fully reduced.
4. High bit is 0, not fully reduced.

We should have test vectors for all four cases, to ensure that any
implementation that does the pairwise consistency check does the
comparison on the fully-reduced value of the given and calculated
public key, instead of just doing a bytewise comparison. (Though, do
we know any of the these 19 private keys that could use to produce a
test vector?)

Cheers,
Brian
-- 
https://briansmith.org/