Subject: [Curdle] Comments on draft-ietf-curdle-pkix-00

From: David Benjamin <[email-masked]>
Date: Thu, 14 Apr 2016 01:06:09 +0000

Hi folks,

I have some comments on draft-ietf-curdle-pkix-00. This is largely coming
from having recently written fresh ECPrivateKey, PrivateKeyInfo, and
SubjectPublicKeyInfo code for BoringSSL and also from thinking how this
draft might be implemented.

First, a small editorial nitpick:

   The raw binary EdDSA public key is encoded directly in the
   subjectPublicKey BIT STRING object.  Note that unlike some other
   schemes, there is no additional OCTET STRING encoding step.

This is like RFC 3279's "The DER encoded RSAPublicKey is the value of the
BIT STRING subjectPublicKey", but I think this is a type error. As far as I
know, an abstract BIT STRING has no inherent a grouping into bytes (of
course the grouping that aligns with DER is most natural). RFC 4055 instead
explicitly says like:

   To convert a signature value to a bit string, the most significant
   bit of the first octet of the signature value SHALL become the first
   bit of the bit string, and so on through the least significant bit of
   the last octet of the signature value, which SHALL become the last
   bit of the bit string.

While more verbose, I think we should be explicit about the type mismatch.
(These fields should never have been BIT STRINGs to begin with, but we've
lost that one.)

Section 3 is confusing. What is the difference between an id-ecPublicKey +
id-Curve25519ph certificate vs. id-EdDSAPublicKey + ed25519ph? There
shouldn't be two ways to spell the same thing. I think the second one is
better. X9.62 ECC is shaped very differently from curve25519/curve448 and I
think it is a mistake to try to shoehorn things here.

Even ditching X9.62, why an id-EdDSAPublicKey top-level OID with ENUMERATED
parameters? Instead, I'd suggest four separate parameter-less algorithm
OIDs for ed25519, ed25519ph, ed448, and ed448ph. (Of course, specify
whether the parameters are omitted or NULL.) Likewise, if anyone wants
X25519 or X448 certificates, allocate those too.

This aligns with presenting Ed25519 and Ed448 as distinct named algorithms
which is I think fairly common and desirable. And between Ed25519 and
Ed25519ph, the PureEdDSA and HashEdDSA versions don't even share type
signatures, so sharing an algorithm is odd. (PureEdDSA is one function and
HashEdDSA is an IUF triple.)

We only have curve25519, but as an analogy, this is BoringSSL's low-level
curve25519 API:
https://commondatastorage.googleapis.com/chromium-boringssl-docs/curve25519.h.html
Internally, X25519 and Ed25519 functions share code, but it's simplest to
present them as separate free-standing APIs. (Indeed this draft would be
slightly awkward for me to implement because there will no longer be a
clean one-to-one correspondence between signature algorithm and EVP_PKEY
type.)

More generally, I think X.509 key types going forward should follow this
pattern, without all the complex layers of extensible substructure. To
borrow a phrase: have only one joint and keep it well-oiled.

David