Subject: [pkix] Strawman on EdDSA/Ed25519 for PKIX Certificate/CRLs

From: Simon Josefsson <[email-masked]>
Date: Mon, 1 Jun 2015 14:22:06 +0200

Hi,

There has been discussion on the TLS list about supporting EdDSA as a
new public-key digital signature algorithm.  To do that you need X.509
certificates with EdDSA public keys in them.  To get the ball rolling on
what it would involve to make this happen, I have started working on a
document on this:

https://tools.ietf.org/html/draft-josefsson-tls-ed25519-00

What I'm looking for here is review from PKIX experts to identify what
is missing from this document to make it implementable.

Please consider this an experiment to see what kind of specification
activity it would require to make EdDSA certs a reality.

If anyone wants to provide feedback in the form of merge requests or
issues in a bug tracker, please see the repository I created around
this document:

https://gitlab.com/jas/ietf-pkix-eddsa

Thanks,
/Simon

---

From: Simon Josefsson <[email-masked]>
Date: Mon, 15 Jun 2015 22:10:09 +0200

Hi,

I have updated the document a bit.  It appears likely that EdDSA will be
usable with other parameters than Ed25519, so I made the EdDSA
parameters an algorithm parameter rather than implied from the OID.

https://tools.ietf.org/html/draft-josefsson-pkix-eddsa-01

An (already outdated) example of an EdDSA X.509 certificate and EdDSA
public-key is also included, so you can throw it at your ASN.1 parsers.

/Simon

---

From: Erwann Abalea <[email-masked]>
Date: Tue, 23 Jun 2015 16:38:43 +0200

Bonjour,

Section 5: EdDSAParameters is an ENUMERATED with (for now) only one value:
"ed25519", which designates a signature algorithm and not a set of public
key parameters. I guess one might want to find "curve25519" and "curve448"
here. Since this type is used with a public key algorithm, naming it with a
signature algorithm might not be suited.

Section 5: the subjectPublicKey BIT STRING seems to contain an additional
OCTET STRING, which isn't necessary at this moment (however, since point
encoding hasn't been decided yet at CFRG, it may change).

Section 6: what is the rationale to define keyUsage values here? I'd drop
this section.

Section 7: signature parameters will be necessary and will be declared
either within the algorithm OID (as is done with ECDSA-with-*), within the
parameters data element, or both (as is done with RSASSA-PSS); right now,
Ed25519 is hardcoded to use SHA512, but you'll have to consider EdDSA with
other hash functions, or different curves (it's not yet decided which hash
function to use with curve448).
Section 7: signature encoding itself must also be defined (or referenced);
for ECDSA, it's a SEQUENCE of 2 INTEGERs; here, it seems that r and s are
concatenated, but it's stated nowhere (maybe draft-josefsson-eddsa-ed25519?)

Section 8: the example certificate doesn't use the EdDSAParameters type to
indicate the curve used.
Section 8: the example certificate doesn't follow section 7 (parameters
MUST be absent)

2015-06-15 22:10 GMT+02:00 Simon Josefsson <[email-masked]>:

> _______________________________________________
> pkix mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pkix
>
>

-- 
Erwann.

---

From: Simon Josefsson <[email-masked]>
Date: Mon, 29 Jun 2015 22:38:55 +0200

> Bonjour,

Hello.  Thank you for the feedback!

> signature algorithm might not be suited.

Actually "ed25519" designates the EdDSA parameters.  They have an impact
on how the public key looks -- EdDSA public keys are not compatible
across hash functions.  Ed25519 implies SHA-512, which implies how the
public key is derived.  I tried to clarify this point by adding the
following sentence:

      The value "ed25519" means the set of EdDSA parameters
      associated with Ed25519, including hash function and curve.

Saying "curve25519" does not feel right to me since it only describes
the curve.  To know the encoding the public key encoding for EdDSA you
also need to know the hash function.

Do you agree?

> encoding hasn't been decided yet at CFRG, it may change).

I don't know if you looked at -00 or -01.  In -00 there was an
additional OCTET STRING step.  People suggested that it just waste
space, so I removed it for -01.  I have now added another sentence
clarifying that it is not there:

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

> Section 6: what is the rationale to define keyUsage values here? I'd drop

I copied this from RFC 5480.  I'm not sure what value there is in having
it, but it looks harmless and potentially useful to me.  I could remove
it too.

> function to use with curve448).

My intention is that the signature parameters follow from the public key
parameters.  The document says:

      <t>This document identify an AlgorithmIdentifier OID for EdDSA
      signatures.  No parameters are defined.  The EdDSA parameters
      follow from the public-key parameters.</t>

Is there any value in repeating the parameter for the signature?  To
validate the signature, you need the public key anyway.

> concatenated, but it's stated nowhere (maybe draft-josefsson-eddsa-ed25519?)

Yes, I'm hoping draft-josefsson-eddsa-ed25519 takes care of that, see
section 4.3 of it.  I added some text pointing this out:

      This value is the opaque value ENC(R) || ENC'(S) described in
      section 4.3 of <xref target="I-D.josefsson-eddsa-ed25519"/>.

> Section 8: the example certificate doesn't follow section 7 (parameters

Yep, the test vector needs to be update -- will work on that.

Thanks,
/Simon