Subject: Re: [Curdle] draft-ietf-curdle-pkix-eddsa-00

From: Simon Josefsson <[email-masked]>
Date: Thu, 07 Apr 2016 16:32:11 +0200

"Jim Schaad" <[email-masked]> writes:

> I have read through this draft and I have a couple of issues that I would
> like to raise:
>
> 1.   Although there is a private key in the examples, there is no private
> key ASN.1 structure defined in the document.  I would prefer to see the
> re-use of ECPrivateKey from RFC 5915.  However, it needs to be redefined as
> the parameters field would not be correct 

The current example uses a new ASN.1 construct as implemented in GnuTLS:

EdDSAParameters ::= ENUMERATED { ed25519 (1), ed25519ph (2) }
EdDSAPrivateKey ::= SEQUENCE {
  curve  EdDSAParameters,
  priv   OCTET STRING
}

We considered the ECPrivateKey construct but the definition of it uses
the RSA Integer-to-Octet-String-Primitive (I2OSP) function to convert
values from integers, and this is not applicable to EdDSA which uses
opaque binary strings.

I'll include the EdDSAPrivateKey ASN.1 structure.

> 2.  There is not an ASN.1 module defined for the document.  I find this to
> be useful as it centralized the information I need to feed to a compiler in
> one location.  I would have a preference for using 2008 syntax, but would
> understand if you kept the current 1988 syntax that the PKIX group strongly
> preferred.

Agreed.  We could include both, to (not) please everyone.

> 3.  If you are going to include the random art in the examples, then a
> pointer to what it is should be included as well.  This is a new concept to
> me.

It is only an illustration.

> 4.  I would believe that it would be remiss not to suggest that only the
> pure versions of EdDSA be used to sign certificates.  I would not outlaw the
> use of the pre-hash versions but a strong recommendation to use the pure
> versions seems in order.

Which text are you thinking of here?  I don't see text like you
describe, but I may be missing it.

/Simon

---

From: Daniel Migault <[email-masked]>
Date: Thu, 7 Apr 2016 14:54:24 +0000

Thanks for the updates Simon. We would appreciate that the WG review the draft as soon as possible before so we proceed to the WGLC.

BR, 
Daniel

-----Original Message-----
From: Curdle [mailto:[email-masked]] On Behalf Of Simon Josefsson
Sent: Thursday, April 07, 2016 11:32 AM
To: Jim Schaad
Cc: [email-masked]; [email-masked]
Subject: Re: [Curdle] draft-ietf-curdle-pkix-eddsa-00

"Jim Schaad" <[email-masked]> writes:

> I have read through this draft and I have a couple of issues that I 
> would like to raise:
>
> key ASN.1 structure defined in the document.  I would prefer to see 
> the re-use of ECPrivateKey from RFC 5915.  However, it needs to be 
> redefined as the parameters field would not be correct

EdDSAParameters ::= ENUMERATED { ed25519 (1), ed25519ph (2) } EdDSAPrivateKey ::= SEQUENCE {
  curve  EdDSAParameters,
  priv   OCTET STRING
}

We considered the ECPrivateKey construct but the definition of it uses the RSA Integer-to-Octet-String-Primitive (I2OSP) function to convert values from integers, and this is not applicable to EdDSA which uses opaque binary strings.

> 2.  There is not an ASN.1 module defined for the document.  I find 
> this to be useful as it centralized the information I need to feed to 
> a compiler in one location.  I would have a preference for using 2008 
> syntax, but would understand if you kept the current 1988 syntax that 
> the PKIX group strongly preferred.

> pointer to what it is should be included as well.  This is a new 
> concept to me.

> 4.  I would believe that it would be remiss not to suggest that only 
> the pure versions of EdDSA be used to sign certificates.  I would not 
> outlaw the use of the pre-hash versions but a strong recommendation to 
> use the pure versions seems in order.

Which text are you thinking of here?  I don't see text like you describe, but I may be missing it.

/Simon

---

From: Simon Josefsson <[email-masked]>
Date: Thu, 07 Apr 2016 17:00:32 +0200

Daniel Migault <[email-masked]> writes:

> Thanks for the updates Simon. We would appreciate that the WG review
> the draft as soon as possible before so we proceed to the WGLC.

What do you and the WG think of merging the content of these two drafts
into one?  They are both PKIX and Curve25519/448-related, and if we are
going to push both ideas forward, having them in the same document make
sense.

The purpose behing separating the ideas into two separate documents was
that we may end up with using only one of the approaches and saying the
other one is not a good idea.  There haven't been a lot of
feedback/discussion on that aspect as far as I have seen.

/Simon

>> the RSA Integer-to-Octet-String-Primitive (I2OSP) function to
>> convert values from integers, and this is not applicable to EdDSA
>> which uses opaque binary strings.
>

---

From: "Salz, Rich" <[email-masked]>
Date: Thu, 7 Apr 2016 17:47:46 +0000

Since the WG agreed to merge the DNS documents into one, I suggest the same thing makes sense here.

And to repeat what Daniel said:  thanks very much for your work on these!

--  
Senior Architect, Akamai Technologies
IM: [email-masked] Twitter: RichSalz

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Mon, 11 Apr 2016 17:05:10 -0400

> Since the WG agreed to merge the DNS documents into one, I suggest the same thing makes sense here.

I'd agree with Rich on this.  One doc should be fine.

    --dkg