Subject: [pkix] PKCS #8? Re: Updated EdDSA/Ed25519 PKIX document

From: Anders Rundgren <[email-masked]>
Date: Wed, 11 Nov 2015 11:24:31 +0100

On 2015-09-23 10:33, Simon Josefsson wrote:
> Hi all,

Hi Simon,

It would be awfully nice with a PKCS #8 specification to complement
the already existing one for private keys in PEM format.

Anders

>
> I have pushed out a new version of the document describing EdDSA public
> keys, signatures and certificates for PKIX.  The change in -03 include
> the addition of the prehash mode, test vectors generated by GnuTLS, and
> a section recommending certain human readable names.
>
> https://tools.ietf.org/html/draft-josefsson-pkix-eddsa-03
>
> I've started a thread to discuss whether it is wortwhile to be able to
> use the same Ed25519 key for both PureEdDSA mode and HashEdDSA signing,
> and I'd appreciate feedback on whether people are interested in this and
> generally if it is a good idea or not.  The complexity involved make me
> shy away a bit from it, but it is fun to consider.  The thread is here:
> https://moderncrypto.org/mail-archive/curves/2015/000630.html
>
> /Simon
>
>
>
> _______________________________________________
> pkix mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pkix
>

---

From: Simon Josefsson <[email-masked]>
Date: Wed, 11 Nov 2015 13:23:26 +0100

> the already existing one for private keys in PEM format.

Right -- there is an example of such a key in section 8.3 but no text
discussing it.  I agree this would be useful to include text clarifying
this aspect.  PKCS#8 has been obsoleted by "Asymmetric Key
Packages" (RFC 5958) so the reference should probably be to that
document rather than PKCS#8 directly.  Right now we are re-using the
EdDSA public key OID for the private key OID too.

One alternative to the approach we've taken is to re-use the RFC 5915 EC
private key format.  Then everything is covered by the combination of
RFC 5915 and the NamedCurve registration in:
https://tools.ietf.org/html/draft-josefsson-pkix-newcurves-01

Does anyone have thoughts on which approach to use?

Thanks,
/Simon

---

From: Anders Rundgren <[email-masked]>
Date: Wed, 11 Nov 2015 15:56:50 +0100

On 2015-11-11 13:23, Simon Josefsson wrote:
> document rather than PKCS#8 directly.

That's sounds fine to me.

> Right now we are re-using the

I think this should be harmonized with JOSE who essentially have the following
alternatives for describing public keys:

jwk:
   {
     "kty": "EC",
     "crv": "ED25519",
     "x": "8dymopMICY76wfnqdpX0JDpCRYke0-Jp1p7lKPQIIRg",
   }

The above departs from the current JWK standard which requires an "y" as well
making the the following approach a viable alternative:

jwk:
  {
   "kty": "ED",
   "crv": "ED25519",
   "x": "8dymopMICY76wfnqdpX0JDpCRYke0-Jp1p7lKPQIIRg",
}

 From what I can deduct, this latter scheme is more in line with your PKIX
SPKI solution.

This would also be great for Android and Java.  In fact the only solution
I have found for Java indeed defines a new provider key class:
https://github.com/str4d/ed25519-java/blob/master/test/net/i2p/crypto/eddsa/EdDSAEngineTest.java#L36

Of course this choice won't shatter the earth but having different solutions
for PKIX and JOSE would IMO be quite unfortunate.

Anders

---

From: Peter Gutmann <[email-masked]>
Date: Wed, 11 Nov 2015 22:59:50 +0000

>Does anyone have thoughts on which approach to use?

Why not use the PKCS #15 format?  PKCS #8 was created for one and only one
algorithm type, RSA.  Since then it's been hacked around repeatedly to support
other algorithms that it was never designed for, and will probably need lots
more hacking around in the future.  The PKCS #15 format OTOH was designed to
support pretty much every known key type out of the box.

PKCS #15 support for EdDSA would consist of adding a new OID to an encoding
table.

Peter.

---

From: Anders Rundgren <[email-masked]>
Date: Thu, 12 Nov 2015 06:46:30 +0100

> support pretty much every known key type out of the box.

I'm primarily concerned about PKCS #12 since this is together with PEM the most
common way transporting certificates + private keys.

> PKCS #15 support for EdDSA would consist of adding a new OID to an encoding

Is PKCS #15 used by anybody except for some European eID-card vendors?

My guess was that updating PKCS #8 (RFC 5958) would be of similar complicity as
for the public key and that it should borrow the same OID and ENUMERATION.

Introducing support for Ed25519 in a crypto library would typically involve
updating a bunch of modules and tools but it would be pretty much a copy
of what was required for ECDSA/ECDH.

Anders

---

From: Simon Josefsson <[email-masked]>
Date: Thu, 12 Nov 2015 08:46:15 +0100

Peter Gutmann <[email-masked]> writes:

> Why not use the PKCS #15 format?

Because PKCS#15 is too complex for the purpose of private-key protection
in the majority of real-world applications.  Heck, even the RFC 5915 EC
PKCS#8 format was considered too complex, I assume, since Nikos
implemented a simpler format for it instead.

> PKCS #15 support for EdDSA would consist of adding a new OID to an encoding

I'm not against doing PKCS#15 support for EdDSA for those who are
interested, it seems like a useful addition.  However, I cannot
recommend it to anyone who hasn't already consumed the PKCS#15 kool-aid.

/Simon

---

From: Simon Josefsson <[email-masked]>
Date: Thu, 12 Nov 2015 08:49:33 +0100

> From what I can deduct, this latter scheme is more in line with your PKIX

No, https://tools.ietf.org/html/draft-josefsson-pkix-eddsa-03 only
encodes the x parameter.  So this appears consistent.

> for PKIX and JOSE would IMO be quite unfortunate.

I don't believe there is sufficient overlap in implementation to matter
in practice, however the fundamental principles should be the same for
both protocols, so it would indeed be surprising if they ended up
differently.

/Simon

---

From: Peter Gutmann <[email-masked]>
Date: Thu, 12 Nov 2015 08:04:15 +0000

Simon Josefsson <[email-masked]> writes:

>Because PKCS#15 is too complex for the purpose of private-key protection in
>the majority of real-world applications.

Uhh, I didn't mean using all all of PKCS #15, just the private-key format.

>However, I cannot recommend it to anyone who hasn't already consumed the
>PKCS#15 kool-aid.

"Pay me now or pay me later": The initial implementation was a pain, but I did
it once 15 years ago and apart from minor tweaks haven't had to update it
since (and that's not just covering the emergence of new algorithms like the
ECC ones, but different formats like PGP/OpenPGP).  PKCS #8 is a lifetime
project since it needs updating for any new algorithm type, and I don't know
how you'd make it work with PGP.

Peter.

---

From: Anders Rundgren <[email-masked]>
Date: Thu, 12 Nov 2015 09:27:41 +0100

> encodes the x parameter.  So this appears consistent.

Pardon me for being somewhat unclear, I meant the distinction of EC versus ED.

> both protocols, so it would indeed be surprising if they ended up differently.

Essentially the question is weather you extend EC or create a new type.

Anders

---

From: Simon Josefsson <[email-masked]>
Date: Thu, 12 Nov 2015 09:37:51 +0100

> Pardon me for being somewhat unclear, I meant the distinction of EC versus ED.
...
> Essentially the question is weather you extend EC or create a new type.

Ah, now I understand.

Well, the situation is that GnuTLS implements a new key type (see [1]
but it should have more text) and there is ALSO the possibility of using
the RFC 5915 ECPrivateKey together with the NamedCurve defined in [2]
but it is a bit underspecified (see below).  I'm not negative about
doing a PKCS#15 format in addition to this.

The problem with re-using RFC 5915 is that has a number of references in
it that doesn't make a lot of sense for EdDSA (e.g., it uses I2OSP from
RSA for encoding!).  So it is not really clear how you would actually
re-use the existing EC type for EdDSA since it is so tailored around how
ECDSA works.  I assume this was the reason Nikos didn't re-use it but
created a new simpler private key format for EdDSA.

To have more alignment, we could describe an ECPrivateKey structure for
EdDSA keys that would be ASN.1-compatible but have different semantics
that would work for EdDSA.  I'm not convinced that is worth the effort,
as it will create implementation complexity and confusion.

/Simon

[1] https://tools.ietf.org/html/draft-josefsson-pkix-eddsa-04#section-8.3
[2] https://tools.ietf.org/html/draft-josefsson-pkix-newcurves-01

---

From: Anders Rundgren <[email-masked]>
Date: Thu, 12 Nov 2015 09:42:33 +0100

> created a new simpler private key format for EdDSA.

This was (IMO) the right approach.

> as it will create implementation complexity and confusion.

Indeed.

Anders