On 10/8/2015 9:17 AM, Simon Josefsson wrote:
Thomas Calderon <calderon.thomas@xxxxxxxxx> writes:
Hi,
There is no need to add new mechanism identifiers to use specific curves.
This can be done already using the CKM_ECDSA mechanism parameters (see
CKA_ECDSA_PARAMS
in the standard).
Given that the underlying HW or SW tokens supports Ed25519 curves, then you
could leverage it even with version 2.20 of the PKCS#11 standard.
I think you need an OID to put in the namedCurve field of EC Parameters
structure, right? The structure is:
Parameters:: = CHOICE {
ecParametersECParameters,
namedCurveCURVES. & id( { CurveNames}),
implicitlyCANULL}
The ecParametersECParameters approach doesn't work, I believe, for
EdDSA, but a namedCurve would probably do. But what OID to use? I'm
happy to reserve 1.3.6.1.4.1.11591.9 to mean a namedCurve value for
Ed25519 in PKCS#11.
Then what is:
1.3.6.1.4.1.11591.15.1 Ed25519
defined here:
https://www.gnu.org/prep/standards/html_node/OID-Allocations.html
The whole idea of namedCurve was you did not have to pass in the parameters,
and PKIX certificates only allow namedCurve.
But PKCS#11 does all the passing of the ecParameters but a PKCS#11 implementation
may not. (OpenSC for example, but there is a request to allow them.)
Or a hardware token may only support a limited number of curves.
This in still not clear how to use ECDSA routines to do EDDSA. (I have been looking
at Simon's RFCs on how to use EDDSA in TLS.)
To use ECDSA PKCS#11 functions, do you need to use Curve25519 rather the Ed25519?
I'm not sure this approach works out -- but let's try.
/Simon
Cheers,
Thomas
On Thu, Oct 8, 2015 at 2:00 PM, Douglas E Engert <deengert@xxxxxxxxx> wrote:
On 10/8/2015 4:49 AM, Simon Josefsson wrote:
Mathias Brossard <mathias@xxxxxxxxxxxx> writes:
Hi,
I have made a patch for enabling the use of ECDSA keys in the PKCS#11
support of ssh-agent which will be of interest to other users.
Nice! What would it take to add support for Ed25519 too? Do we need to
allocate any new PKCS#11 identifiers?
Yes, and PKCS#11 allows for *_VENDOR_SUPPLIED identifiers. But using these
can
get out of hand. Best to try and get them in the standard. OASIS controls
the
standard From 14 April 2015:
http://docs.oasis-open.org/pkcs11/pkcs11-curr/v2.40/pkcs11-curr-v2.40.html
2.40 does not define Ed25519.
The Gnuk smartcard supports
Ed25519 but I don't know if it is common to use it with OpenSSH through
PKCS#11 (I would expect it to be used with OpenSSH through GnuPG's
gpg-agent). At least it might be useful as a test case.
/Simon
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@xxxxxxxxxxx
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
--
Douglas E. Engert <DEEngert@xxxxxxxxx>
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@xxxxxxxxxxx
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
--
Douglas E. Engert <DEEngert@xxxxxxxxx>
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@xxxxxxxxxxx
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
