EdDSA Ed25519/Ed448 for XML Digital Signatures

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

EdDSA Ed25519/Ed448 for XML Digital Signatures

Simon Josefsson
Hi.  I have prepared a writeup on how to add the EdDSA Ed25519/Ed448
public-key digital signature algorithm to XMLDSIG.

https://mailarchive.ietf.org/arch/msg/curdle/Ylertitv43TdDrcm4ufh2LxdBjM

Are you interested in implementing this?  If so, your feedback on the
description is appreciated.  If there is interest among XMLDSIG
implementers, I would turn this into a proper IETF draft.

/Simon

signature.asc (482 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: EdDSA Ed25519/Ed448 for XML Digital Signatures

Cantor, Scott
On 12/2/15, 9:29 AM, "Simon Josefsson" <[hidden email]> wrote:



>Hi.  I have prepared a writeup on how to add the EdDSA Ed25519/Ed448
>public-key digital signature algorithm to XMLDSIG.
>
>https://mailarchive.ietf.org/arch/msg/curdle/Ylertitv43TdDrcm4ufh2LxdBjM
>
>Are you interested in implementing this?  If so, your feedback on the
>description is appreciated.  If there is interest among XMLDSIG
>implementers, I would turn this into a proper IETF draft.

Hi Simon,

Speaking as the C++ maintainer, it's pretty much dependent on OpenSSL support (and my ability to figure out how to make use of it without screwing it up, given that OpenSSL is largely undocumented).

Speaking as a consumer of the Java code, does Java actually support this algorithm? I didn't see any sign it did. I don't think there's any actual crypto in the current library, it's JCE-reliant. Colm can correct me.

As an aside in reading your draft, you might consider just specifying that public keys be carried in the 1.1 DEREncodedKeyValue element since you're encoding it anyway. It's generally easier to deal with one encoded format (the SubjectPublicKeyInfo form) than multiple.

-- Scott

Reply | Threaded
Open this post in threaded view
|

Re: EdDSA Ed25519/Ed448 for XML Digital Signatures

Simon Josefsson
> On 12/2/15, 9:29 AM, "Simon Josefsson" <[hidden email]> wrote:

>
> >Hi.  I have prepared a writeup on how to add the EdDSA Ed25519/Ed448
> >public-key digital signature algorithm to XMLDSIG.
> >
> >https://mailarchive.ietf.org/arch/msg/curdle/Ylertitv43TdDrcm4ufh2LxdBjM
> >
> >Are you interested in implementing this?  If so, your feedback on the
> >description is appreciated.  If there is interest among XMLDSIG
> >implementers, I would turn this into a proper IETF draft.
>
> Hi Simon,
>
> Speaking as the C++ maintainer, it's pretty much dependent on OpenSSL
> support (and my ability to figure out how to make use of it without
> screwing it up, given that OpenSSL is largely undocumented).
Hi.  Thanks.  I'm sure people are working on it, but I opened an issue
to track this: https://github.com/openssl/openssl/issues/487

> Speaking as a consumer of the Java code, does Java actually support
> this algorithm? I didn't see any sign it did. I don't think there's
> any actual crypto in the current library, it's JCE-reliant. Colm can
> correct me.

How would one go about specifying support for a new algorithm like
EdDSA in Java?  I've seen that people have been thinking about adding
it to Bouncycastle, but I assume you would really want to have it be
part of JCE.

> As an aside in reading your draft, you might consider just specifying
> that public keys be carried in the 1.1 DEREncodedKeyValue element
> since you're encoding it anyway. It's generally easier to deal with
> one encoded format (the SubjectPublicKeyInfo form) than multiple.

It seems DEREncodedKeyValue pulls in XMLDsig 1.1 which is a bit newer
than base XMLdsig, and is not described in the IETF nor used as a
normative reference by any IETF documents as far as I can tell.  It
would also pull in the EdDSA PKIX specification as a normative
dependency.

Further, reading XMLDsig11 section 4.5.9:

http://www.w3.org/TR/2013/PR-xmldsig-core1-20130124/#sec-DEREncodedKeyValue

I believe it may have an error there.
SubjectPublicKeyInfo.subjectPublicKey is a BIT STRING.  There is no
requirement anywhere (that I know of) that it has to contain DER
encoded data.  The EdDSA PKIX proposal on the table (with at least one
proof-of-concept implementation in GnuTLS) does not DER encode the EdDSA
public key.

If the XMLDsig11 spec would be fixed to say "use the data in the
SubjectPublicKeyInfo field" (which I assume is what is intended, it
works for RSA/DSA/EC) that will be identical to what I describe anyway.
It is the same encoding, i.e., raw EdDSA public key.

/Simon

attachment0 (484 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: EdDSA Ed25519/Ed448 for XML Digital Signatures

Sean Mullan
On 12/02/2015 03:43 PM, Simon Josefsson wrote:

>> On 12/2/15, 9:29 AM, "Simon Josefsson" <[hidden email]> wrote:
>>
>>> Hi.  I have prepared a writeup on how to add the EdDSA Ed25519/Ed448
>>> public-key digital signature algorithm to XMLDSIG.
>>>
>>> https://mailarchive.ietf.org/arch/msg/curdle/Ylertitv43TdDrcm4ufh2LxdBjM
>>>
>>> Are you interested in implementing this?  If so, your feedback on the
>>> description is appreciated.  If there is interest among XMLDSIG
>>> implementers, I would turn this into a proper IETF draft.
>>
>> Hi Simon,
>>
>> Speaking as the C++ maintainer, it's pretty much dependent on OpenSSL
>> support (and my ability to figure out how to make use of it without
>> screwing it up, given that OpenSSL is largely undocumented).
>
> Hi.  Thanks.  I'm sure people are working on it, but I opened an issue
> to track this: https://github.com/openssl/openssl/issues/487
>
>> Speaking as a consumer of the Java code, does Java actually support
>> this algorithm? I didn't see any sign it did. I don't think there's
>> any actual crypto in the current library, it's JCE-reliant. Colm can
>> correct me.
>
> How would one go about specifying support for a new algorithm like
> EdDSA in Java?  I've seen that people have been thinking about adding
> it to Bouncycastle, but I assume you would really want to have it be
> part of JCE.

We typically don't include an implementation of a new crypto algorithm
in the JDK unless it is a standard and has gained enough industry
traction or support from the community to justify inclusion.

Unfortunately, I'm not familiar with the EdDSA algorithm so don't really
have much more to say on your proposal.

--Sean
Reply | Threaded
Open this post in threaded view
|

Re: EdDSA Ed25519/Ed448 for XML Digital Signatures

Cantor, Scott
In reply to this post by Simon Josefsson
On 12/2/15, 3:43 PM, "Simon Josefsson" <[hidden email]> wrote:



>How would one go about specifying support for a new algorithm like
>EdDSA in Java?  I've seen that people have been thinking about adding
>it to Bouncycastle, but I assume you would really want to have it be
>part of JCE.

BC is better than nothing, but that's more a question for your deployment scenario I guess. I don't have specific demand for this, so it doesn't affect me that much whether the BC JCE is a requirement, but I would suspect that it would be a barrier to adoption.

I don't know what Oracle's process is, other than obviously just filing a bug entry as a RFE.

>It seems DEREncodedKeyValue pulls in XMLDsig 1.1 which is a bit newer
>than base XMLdsig, and is not described in the IETF nor used as a
>normative reference by any IETF documents as far as I can tell.  It
>would also pull in the EdDSA PKIX specification as a normative
>dependency.

Well, XML Signature 1.1 is the current version. Any references to 1.0 are out of date, for a lot of reasons, algorithm currency being the big one.

>I believe it may have an error there.
>SubjectPublicKeyInfo.subjectPublicKey is a BIT STRING.  There is no
>requirement anywhere (that I know of) that it has to contain DER
>encoded data.

I didn't advocate for the element name, it was a compromise trying to get them to accept that a non-XML representation was needed. That was the name that got people to stop fighting me on it.

>If the XMLDsig11 spec would be fixed to say "use the data in the
>SubjectPublicKeyInfo field" (which I assume is what is intended, it
>works for RSA/DSA/EC) that will be identical to what I describe anyway.
>It is the same encoding, i.e., raw EdDSA public key.

That's all it means, so I would not advise defining your own element for the same thing.

-- Scott