[PATCH] Enabling ECDSA in PKCS#11 support for ssh-agent

[Douglas E Engert]

On 10/8/2015 9:17 AM, Simon Josefsson wrote:
> Thomas Calderon <calderon.thomas at gmail.com> 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 at gmail.com> wrote:
>>
>>>
>>>
>>> On 10/8/2015 4:49 AM, Simon Josefsson wrote:
>>>
>>>> Mathias Brossard <mathias at brossard.org> 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 at mindrot.org
>>>> https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
>>>>
>>>>
>>> --
>>>
>>>   Douglas E. Engert  <DEEngert at gmail.com>
>>>
>>>
>>> _______________________________________________
>>> openssh-unix-dev mailing list
>>> openssh-unix-dev at mindrot.org
>>> https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
>>>

-- 

  Douglas E. Engert  <DEEngert at gmail.com>