santuario-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Simon Josefsson <si...@josefsson.org>
Subject Re: EdDSA Ed25519/Ed448 for XML Digital Signatures
Date Wed, 02 Dec 2015 20:43:53 GMT
> On 12/2/15, 9:29 AM, "Simon Josefsson" <simon@josefsson.org> 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

Mime
View raw message