Subject: [Curdle] I-D Action: draft-ietf-curdle-pkix-eddsa-00.txt

From: [email-masked]
Date: Sun, 20 Mar 2016 12:44:14 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the CURves, Deprecating and a Little more Encryption of the IETF.

        Title           : Using EdDSA with Ed25519/Ed448 in the Internet X.509 Public Key Infrastructure
        Authors         : Simon Josefsson
                          Nikos Mavrogiannopoulos
	Filename        : draft-ietf-curdle-pkix-eddsa-00.txt
	Pages           : 10
	Date            : 2016-03-20

Abstract:
   This document specify algorithm identifiers and ASN.1 encoding
   formats for EdDSA digital signatures and subject public keys used in
   the Internet X.509 Public Key Infrastructure (PKIX) for Certificates
   and CRLs.  Parameters for Ed25519, Ed25519ph, Ed448, and Ed448ph are
   defined.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-curdle-pkix-eddsa/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-curdle-pkix-eddsa-00

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Ilari Liusvaara <[email-masked]>
Date: Sun, 20 Mar 2016 22:26:22 +0200

> 	Filename        : draft-ietf-curdle-pkix-eddsa-00.txt

The certificate example contains signature OID 1.3.101.100.1, whereas
the prose says the signature OID is 1.3.101.101. Which one is correct?

-Ilari

---

From: Erwann Abalea <[email-masked]>
Date: Tue, 22 Mar 2016 16:11:16 +0000

Bonjour,

Section 4, the EdDSAParameters definition is not correct ASN.1.

It should be:
EdDSAParameters ::= ENUMERATED {
  ed25519   (1),
  ed25519ph (2),
  ed448     (3),
  ed448ph   (4),
  ...
}

if you want the enumeration to be extensible, you MUST include the extensibility marker (the 3 dots).

Section 3 and 6, some data structure definitions are recalled (AlgorithmIdentifier). I think it may be wiser to use the definition from the AlgorithmInformation-2009 module (RFC5912) than mentioning the now really obsolete ANY-based one (ANY has been removed from the standard in 1994, and replaced by information object classes and information objects).

The text in section 6 is focused on certificates, where the signature is encoded as a BIT STRING; but this algorithm definition can also be used with CMS, where a signature is encoded as an OCTET STRING. It may be nice to specify algorithms and content of the signature (the ENC(R)||ENC(S) part, and don’t discuss about the enclosing of the signature (BIT STRING vs OCTET STRING).

Following the idea proposed in this draft, I’d then propose this:

pk-eddsa PUBLIC-KEY ::= {
  IDENTIFIER id-EdDSAPublicKey
  PARAMS TYPE EdDSAParameters ARE required
  CERT-KEY-USAGE { digitalSignature, nonRepudiation, keyCertSign, cRLSign }
}

for the public key.

And:

sa-eddsa SIGNATURE-ALGORITHM ::= {
  IDENTIFIER id-EdDSASignature
  PARAMS TYPE NULL ARE absent
  PUBLIC-KEYS { pk-eddsa }
}

for the signature. Note that VALUE and HASHES are absent here. You can also remove the « PARAMS TYPE NULL ARE absent » if you want.

Isn’t it embarrassing that there’s little room for agility here?. Ed25519 can only be used with SHA-512 (no SHA-3 option), and Ed448 only with SHAKE256.

Cordialement,
Erwann Abalea

Le 20 mars 2016 à 20:44, [email-masked]<mailto:[email-masked]> a écrit :

Abstract:

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