> On 12/2/15, 9:29 AM, "Simon Josefsson" <[email protected]> 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
pgppfSXtWrKA_.pgp
Description: OpenPGP digital signatur
