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

[Brian Smith <[e-mail]>]

David Benjamin <[e-mail]> wrote:
> I don't especially object to requiring the v2 form be accepted or fixing
> BoringSSL to accept it, but if the only use is a mandatory convoluted
> checksum check, then I would rather we throw v2 away and stick with the
> simple thing.

Besides being a checksum against corruption, here are the benefits
I've found to having the public key in the file:

* It protects against the case where the producer of the private key
miscalculated the public key (i.e. the producer's math is buggy).

* It protects against the case where the consumer of the private key
miscalculates the public key (i.e. the consumer's math is buggy).

* If you have (a lot of) PKCS#8 documents, you can look up a private
key by public key without having to compute the public key from the
private key for each one.

* If an implementation presents the public key as it is stored in the
PKCS#8 file, then the public key will always be present consistently.
That is, it provides a way to avoid implementation fingerprinting,
although it doesn't mandate implementations try to avoid
fingerprinting in this way.

Note that RFC 5915 (ECPrivateKey for traditional curves) doesn't
require publicKey to be present and it doesn't require the user to
check that the private key is consistent with the public key even when
it is present. And other standards for those curves also do provide
alternatives (see, for example, NIST SP 800-56A section 5.6.3.2). So I
agree that saying that the implementation MUST do the check is
excessive, but I do think it is a really good idea.

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