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

[Brian Smith <[e-mail]>]

Jim Schaad <[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.

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.

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

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.

Cheers,
Brian