On 12/2/15, 3:43 PM, "Simon Josefsson" <[email protected]> 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
