Subject: [pkix] Updated EdDSA/Ed25519 PKIX document

From: Simon Josefsson <[email-masked]>
Date: Wed, 23 Sep 2015 10:33:29 +0200

Hi all,

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

---

From: "Manger, James" <[email-masked]>
Date: Thu, 24 Sep 2015 13:23:45 +1000

Hi Simon, two technical typos:

The example cert in 8.2 has the wrong OID for the signature.
Cert has { 1 3 101 100 1 } [encoding 06 04 2B656401]
Text has { 1 3 101 101 }   [encoding 06 03 2B6565]   for id-EdDSASignature

OIDs use space-separated (not dot-separated) numbers in ASN.1.
Section 4:
Wrong { 1.3.101.100 }
Right { 1 3 101 100 }
Section 7
Wrong { 1.3.101.101 }
Right { 1 3 101 101 }

The cert's notBefore field is a UTCTime value (2-digit year), while the notAfter field is a GeneralizedTime value (4-digit year). I don't think I has seen that before, but it is valid.

--
James Manger

-----Original Message-----
From: pkix [mailto:[email-masked]] On Behalf Of Simon Josefsson
Sent: Wednesday, 23 September 2015 6:33 PM
To: [email-masked]; [email-masked]
Subject: [pkix] Updated EdDSA/Ed25519 PKIX document

Hi all,

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.

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

---

From: Simon Josefsson <[email-masked]>
Date: Thu, 24 Sep 2015 13:04:28 +0200

> Text has { 1 3 101 101 }   [encoding 06 03 2B6565]   for id-EdDSASignature

Hi James.  Good catch -- I believe that is a typo in the implementation.
I'll let Nikos fix that, but we'll update the examples in the document.

> OIDs use space-separated (not dot-separated) numbers in ASN.1.

Fixed, thank you.

> The cert's notBefore field is a UTCTime value (2-digit year), while
> the notAfter field is a GeneralizedTime value (4-digit year). I don't
> think I has seen that before, but it is valid.

I suspect the logic in GnuTLS to pick one encoding over the other looks
at the date to see if it fits in a UTCTime value or not.  It shouldn't
be related to EdDSA.

/Simon

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

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Thu, 24 Sep 2015 14:01:14 +0200

> think I has seen that before, but it is valid.

Hi,
 Thanks for the comments, they should be addressed in the next update.
About the times, that's an RFC5280 requirement. 
"CAs conforming to this profile MUST always encode certificate
validity dates through the year 2049 as UTCTime; certificate
validity dates in 2050 or later MUST be encoded as GeneralizedTime."

The notAfter is a date over 2050 (in fact its the 'no well defined
expiration date').

regards,
Nikos