Subject: Re: [Curdle] draft-ietf-curdle-pkix-newcurves

From: Russ Housley <[email-masked]>
Date: Tue, 5 Apr 2016 14:16:36 -0400

I expect that CMS will be one of the protocols where we make use of the new curves.

ECDH will be used for key agreement with Enveloped-Data and EdDSA will we used for digital signature with Signed-Data.

For ECDH, the ECPoint will carry the public key, and the parameter will identify the named curve.  I gather that this is the intended us of:

       id-Curve25519   OBJECT IDENTIFIER ::= { 1.3.6.1.4.1.11591.15.1 }
       id-Curve448     OBJECT IDENTIFIER ::= { 1.3.6.1.4.1.11591.15.2 }

If I got that right, something like id-ecdh-with-curveXXX seems like a name that will help the human.

I think the other two object identifiers in the document are only for use with EdDSA.

       id-Curve25519ph OBJECT IDENTIFIER ::= { 1.3.6.1.4.1.11591.15.3 }
       id-Curve448ph   OBJECT IDENTIFIER ::= { 1.3.6.1.4.1.11591.15.4 }

If I got that right, something like id-eddsa-with-curveXXX seems like a name that will help the human.

Russ

On Mar 28, 2016, at 5:05 PM, Jim Schaad <[email-masked]> wrote:

> I am confused on reading this draft.  I read the DSA draft first and it had
> one way of encoding the public keys.  This draft appears to have a different
> way of doing this.  What are the authors recommending?
> 
> Jim

---

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

> way of doing this.  What are the authors recommending?

Depends what your application is. :-)

It is not clear to me which approach is preferable.  Further, it is not
clear that they are exclusive.

It seems that in some PKIX applications (e.g., PKCS#11, XMLSecurity,
Java, maybe CMS), a NamedCurve OID is needed to move forward, so that
existing infrastructure for NIST/Brainpool EC can be reused/abused.
Thus draft-ietf-curdle-pkix-newcurves.

It seems that in some PKIX applications (e.g., Certificates, TLS), a new
public key algorithm and digital signature algorithm is a cleaner and
easier way to introduce EdDSA.

I don't think the situation is as easy as say that The NamedCurve OIDs
are for ECDH and the pkix-eddsa approach is for digital signatures.  We
could go that route, but I believe it is a simplification that will hurt
some application in the long run.  For example, when you want to chose a
curve before knowing what operation it will be used for (think PKCS#11).

Right now, I'm of the mind that we need NamedCurve OIDs for the curves
(including the ph-variant for signatures) but also believe a new EdDSA
certificate/signature format is needed.

Further thoughts on this would be welcome, especially from implementers.

/Simon

---

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

Russ Housley <[email-masked]> writes:

> ECDH will be used for key agreement with Enveloped-Data and EdDSA will
> we used for digital signature with Signed-Data.
>
> For ECDH, the ECPoint will carry the public key, and the parameter
> will identify the named curve.

Right.

> I gather that this is the intended us of:
>

NamedCurve OIDs are used for other purposes than ECDH, so I believe this
would be confusing.  Compare the NIST and Brainpool NamedCurve OIDs,
none of them include 'ecdh-with'.  Or am I missing something?  Compare
the more recent RFC 5639.

> a name that will help the human.

I have the same concern here.  I believe NamedCurve OIDs are used to
identify the curves themselves, not the purpose for what the curve is be
used for.  Otherwise we would have different OIDs for DH or MQV, for
example, and we don't.

Thanks,
/Simon

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

---

From: Russ Housley <[email-masked]>
Date: Thu, 7 Apr 2016 10:39:10 -0400

Okay.  I understand your point.

Russ

---

From: Anders Rundgren <[email-masked]>
Date: Thu, 7 Apr 2016 18:02:27 +0200

If I do this in openssl:

openssl ecparam -name prime256v1 -genkey -out prime256v1.pem -noout

The resulting PEM file

-----BEGIN EC PRIVATE KEY-----
MHcCAQEEIBCJ4KQUK24oUNEz/m3E9Fzu115J3btbUWICmEAezudtoAoGCCqGSM49
AwEHoUQDQgAE99m5W2jLA0KUld2QIWUq440ZngvUFgaMpeJ+ng9diJ+JrnHFb5Zx
BElOa6uZQbey3Mp7ajnYfKG6uCt3IbpB6g==
-----END EC PRIVATE KEY-----

after base64 decoding holds the following:

   0: SEQUENCE
        {
   2:     INTEGER 1
   5:     OCTET STRING, 32 bytes
      0000: 10 89 E0 A4 14 2B 6E 28 50 D1 33 FE 6D C4 F4 5C   '.....+n(P.3.m..\'
      0010: EE D7 5E 49 DD BB 5B 51 62 02 98 40 1E CE E7 6D   '..^I..[Qb..@...m'
  39:     [0]
            {
  41:         OBJECT IDENTIFIER NIST-P-256 (1.2.840.10045.3.1.7)
            }
  51:     [1]
            {
  53:         BIT STRING, 65 bytes
      0000: 04 F7 D9 B9 5B 68 CB 03 42 94 95 DD 90 21 65 2A   '....[h..B....!e*'
      0010: E3 8D 19 9E 0B D4 16 06 8C A5 E2 7E 9E 0F 5D 88   '...........~..].'
      0020: 9F 89 AE 71 C5 6F 96 71 04 49 4E 6B AB 99 41 B7   '...q.o.q.INk..A.'
      0030: B2 DC CA 7B 6A 39 D8 7C A1 BA B8 2B 77 21 BA 41   '...{j9.|...+w!.A'
      0040: EA                                                '.'
            }
        }

That is, the public key is also available. This is BTW marked as a SHOULD in RFC 5915.

I would be happy if the private key ASN.1 definition followed this scheme.

Anders

---

From: Ilari Liusvaara <[email-masked]>
Date: Thu, 7 Apr 2016 20:53:49 +0300

> curve before knowing what operation it will be used for (think PKCS#11).

The problem is that to use the same public key for ECDH and EdDSA
requires special peer side support. This is not about security, but
what mathematically works.

ECDH and ECDSA with full-group curves do not have the same problem
(it isn't cryptographically good practice, but that's about security).

-Ilari

---

From: Russ Housley <[email-masked]>
Date: Fri, 8 Apr 2016 13:39:47 -0400

We already have RFC 5084 that specifies the use of AES-CCM and AES-GCM with CMS.

A few days ago, I posted an I-D that specifies the use of ChaCha20 with Poly1305 with CMS:

	https://www.ietf.org/id/draft-housley-cms-chacha20-poly1305-00.txt

Stephen Farrell told me that he would like this document to go through this working group.  Please read and review.  Is this working group willing to adopt it?

Russ

---

From: Simon Josefsson <[email-masked]>
Date: Fri, 8 Apr 2016 19:52:30 +0200

> > > I am confused on reading this draft.  I read the DSA draft first
> > > and it had one way of encoding the public keys.  This draft
> > > appears to have a different way of doing this.  What are the
> > > authors recommending?
> > 
> > I don't think the situation is as easy as say that The NamedCurve
> > OIDs are for ECDH and the pkix-eddsa approach is for digital
> > signatures.  We could go that route, but I believe it is a
> > simplification that will hurt some application in the long run.
> > For example, when you want to chose a curve before knowing what
> > operation it will be used for (think PKCS#11).
> 

Why would we want people to use the same public key for ECDH and
EdDSA?  That seems like a terrible idea that we should simply recommend
against.

/Simon

---

From: "Salz, Rich" <[email-masked]>
Date: Sat, 9 Apr 2016 12:34:08 +0000

> Stephen Farrell told me that he would like this document to go through this
> working group.  Please read and review.  Is this working group willing to
> adopt it?

This is exactly the kind of thing that we should cover.  Let's wait a few days and then call for adoption next week.  If anyone knows of a reason why *not* to adopt this, of course speak up now -- no need to wait :)

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Mon, 11 Apr 2016 20:43:37 -0400

On Fri 2016-04-08 13:52:30 -0400, Simon Josefsson wrote:
> EdDSA?  That seems like a terrible idea that we should simply
> recommend against.

Agreed with Simon here, we should actively discourage reuse of any key
in different contexts.

    --dkg

---

From: Ilari Liusvaara <[email-masked]>
Date: Tue, 12 Apr 2016 10:21:37 +0300

> Agreed with Simon here, we should actively discourage reuse of any key

My point was that such reuse won't even work, since the two algorithms
interpret their keys differently (if implemented to spec).

And yes, even if it worked, such reuse would be bad idea. E.g. the
ECDH vs. ECDSA reuse has been exploited in at least one attack against
TLS (didn't work with DH vs. DSA because key types were separate).

-Ilari

---

From: Russ Housley <[email-masked]>
Date: Fri, 15 Apr 2016 13:41:54 -0400

We already have RFC 5753 that specifies the use of ECC with CMS.

I just posted an I-D that specifies the use of ECDH with Curve 25519 and Curve 448 with CMS:

	https://www.ietf.org/id/draft-housley-cms-ecdh-new-curves-00.txt

There are a few open issues in the document.  Please read and review.  Is this working group willing to adopt it?

Russ

---

From: Russ Housley <[email-masked]>
Date: Mon, 18 Apr 2016 20:04:04 -0400

I just posted an I-D that specifies the use of EdDSA with CMS:

	https://www.ietf.org/id/draft-housley-cms-eddsa-signatures-00.txt

It makes use of the sam object identifies that Simon used for the PKIX-related document.

Please read and review.  Is this working group willing to adopt it?

Russ

---

From: Russ Housley <[email-masked]>
Date: Thu, 28 Apr 2016 19:24:51 -0400

Russ

---

From: Martin Thomson <[email-masked]>
Date: Fri, 29 Apr 2016 09:56:48 +1000

> It makes use of the sam object identifies that Simon used for the PKIX-related document.

Which doesn't define what to put in the "context" argument to
Ed448[ph].  Though that's an open discussion in the CFRG currently.

---

From: Russ Housley <[email-masked]>
Date: Thu, 28 Apr 2016 22:36:02 -0400

> Ed448[ph].  Though that's an open discussion in the CFRG currently.

I’m watching that discussion.  In addition, Jim Schaad sent me a note asking whether the pre-hash versions actually make any sense with CMS.

Russ