Subject: [Curdle] DER/PEM storage format for EdDSA private keys

From: Hugo Landau <[email-masked]>
Date: Tue, 22 Dec 2015 16:54:07 +0000

Does this WG intend to provide a storage format for EdDSA private keys?
Such a format will certainly be needed.

The existing EC ASN.1 format could probably be reused. It is:

   ECPrivateKey ::= SEQUENCE {
     version        INTEGER { ecPrivkeyVer1(1) } (ecPrivkeyVer1),
     privateKey     OCTET STRING,
     parameters [0] ECParameters {{ NamedCurve }} OPTIONAL,
     publicKey  [1] BIT STRING OPTIONAL
   }

Since draft-josefsson-pkix-newcurves has allocated named curve OIDs for
the CFRG curves, these OIDs could be used here.

On the other hand, since this is essentially an overloading of the
semantics of ECPrivateKey, NamedCurve, etc., there could be issues
adding support to existing implementations that would be prefer to treat
EdDSA substantially differently to NIST ECDSA.

Another issue is what it means for a key to be Ed25519 vs. Ed25519ph.
Must an Ed25519ph key only be used for prehashed data? The issue, I
suppose, is that if you allow the same key to be used for non-prehashed
data and prehashed data, you create the potential issue that a signature
generated over 64 bytes (assuming SHA512) via Ed25519 could be passed
off as an Ed25519ph signature by an attacker. The 'namespaces' conflict.
On the other hand, one won't necessarily know, when generating a key,
whether prehashing will be used. If a key is used with more than one
application, prehashing might be used for one and not the other.

---

From: "Salz, Rich" <[email-masked]>
Date: Wed, 23 Dec 2015 14:45:11 +0000

The IETF generally doesn't do storage formats.

BUT we do define ASN.1, and then it's easy to specify a storage format.  And we need to define ASN.1 because the intent is that these things are transmitted as bytes on the wire.

I'd be interested in a non-normative appendix that says things like "base64 encode the DER of ECPrivateKey" as one MAY format, and so on.

Does that make sense?

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

---

From: "Paul Hoffman" <[email-masked]>
Date: Wed, 23 Dec 2015 07:57:26 -0800

On 23 Dec 2015, at 6:45, Salz, Rich wrote:

> BUT we do define ASN.1, and then it's easy to specify a storage 
> format.  And we need to define ASN.1 because the intent is that these 
> things are transmitted as bytes on the wire.
>
> I'd be interested in a non-normative appendix that says things like 
> "base64 encode the DER of ECPrivateKey" as one MAY format, and so on.
>
> Does that make sense?

Yes, and it sounds like a good idea. Other binary formats might 
MAY-level as well.

--Paul Hoffman

---

From: Watson Ladd <[email-masked]>
Date: Wed, 23 Dec 2015 12:13:29 -0500

Why do we need to base64 encode the DER, instead of storing a string
of bytes? It's a string of bytes: I'm sure you can store it in all
sort of weird ways, but you really don't need to.

On Wed, Dec 23, 2015 at 10:57 AM, Paul Hoffman <[email-masked]> wrote:
>> BUT we do define ASN.1, and then it's easy to specify a storage format.
>> And we need to define ASN.1 because the intent is that these things are
>> transmitted as bytes on the wire.
>>
> Yes, and it sounds like a good idea. Other binary formats might MAY-level as
> well.
>
> --Paul Hoffman
>
>
> _______________________________________________
> Curdle mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/curdle

-- 
"Man is born free, but everywhere he is in chains".
--Rousseau.

---

From: Watson Ladd <[email-masked]>
Date: Wed, 23 Dec 2015 12:52:10 -0500

On Wed, Dec 23, 2015 at 12:20 PM, Salz, Rich <[email-masked]> wrote:
>
>> Why do we need to base64 encode the DER, instead of storing a string of
>> bytes? It's a string of bytes: I'm sure you can store it in all sort of weird ways,
>> but you really don't need to.
>
> For compatibility with existing tools, such as OpenSSH's authorized_keys file, etc.
>
authorized_keys can take a base-64 encoded blob, without any DER structure.

---

From: "Salz, Rich" <[email-masked]>
Date: Wed, 23 Dec 2015 18:00:04 +0000

> authorized_keys can take a base-64 encoded blob, without any DER

It was an example, perhaps not a good one.  The main clause "for compatibility with existing tools" is important.

---

From: Hugo Landau <[email-masked]>
Date: Wed, 23 Dec 2015 18:13:48 +0000

That may be the case in theory, but RFC5915 basically spells out the PEM-style
encoding for its preferred DER representation of private keys.

So specifying a DER format (whether using some existing format or not)
and having an appendix which basically says "if you PEM-armour this,
you should probably use a banner of 'EdDSA PRIVATE KEY'" sounds good.

(My use of the term 'PEM' here seems to be technically incorrect, but
there doesn't seem to be any reasonable way of referring specifically to
the habit of placing line-wrapped base64 data between -----BEGIN x-----
and -----END x-----, or any independent document describing the format.)

On Wed, Dec 23, 2015 at 02:45:11PM +0000, Salz, Rich wrote:
> BUT we do define ASN.1, and then it's easy to specify a storage format.  And we need to define ASN.1 because the intent is that these things are transmitted as bytes on the wire.n
>

---

From: "Salz, Rich" <[email-masked]>
Date: Wed, 23 Dec 2015 18:18:19 +0000

> So specifying a DER format (whether using some existing format or not) and
> having an appendix which basically says "if you PEM-armour this, you should
> probably use a banner of 'EdDSA PRIVATE KEY'" sounds good.

Glad we agree.
 
> (My use of the term 'PEM' here seems to be technically incorrect, but there
> doesn't seem to be any reasonable way of referring specifically to the habit
> of placing line-wrapped base64 data between -----BEGIN x----- and -----END
> x-----, or any independent document describing the format.)

It comes from the old Privacy-Enhanced Mail RFC's.  I think SSLeay (the predecessor to OpenSSL) made it very popular and coined the term.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 24 Dec 2015 00:19:14 +0000 (UTC)

I don't care what the IETF 'does'
Not specifying the private key format means we ended up with three flavored of SSH an an unnecessary incompatibility
Specify everything that needs to be said to make things work. 

Sent from Outlook Mobile

Glad we agree.

---

From: Simon Josefsson <[email-masked]>
Date: Thu, 24 Dec 2015 12:21:34 +0700

We looked into reusing that structure but it is not a good fit for eddsa. See draft-josefsson-pkix for an example eddsa private key in PEM-format.  It is implemented in GnuTLS. There are known problems with it - I'll update the draft in January with an updated version.

I believe the charter covers doing private key formats. The IETF defines them for all other algs.

/Simon

Hugo Landau <[email-masked]> skrev: (22 december 2015 23:54:07 GMT+07:00)

-- 
Skickat från min Android-telefon med K-9 E-post. Ursäkta min fåordighet.