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

[Mathias Brossard]

On Thu, Oct 8, 2015 at 2:49 AM, Simon Josefsson <simon at josefsson.org> wrote:

> Mathias Brossard <mathias at brossard.org> writes:
> > 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?  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.
>

This raises a lot of different questions. I'll try to be brief and not too
controversial
(so I'll skip the PKCS#11 in GnuPG question).

PKCS#11 is the standard API to access smartcards and if you want, for
instance,
browsers to support Ed25519 for TLS authentication (I'm sure you're
familiar with
https://tools.ietf.org/html/draft-josefsson-tls-eddsa2-02), this will be a
necessary
step.

For supporting Ed25519 in ssh-agent through PKCS#11, it should be possible
using the same path as my ECDSA patch. The current implementation for
PKCS#11 uses OpenSSL as scaffolding and essentially overloads the signing
method with its own.

Now the question becomes how should Ed25519 on PKCS#11. I hadn't subscribed
to the mailing list so I missed a few mails.

The key type CKK_ECDSA has been renamed CKK_EC and
CKA_ECDSA_PARAMS is now CKA_EC_PARAMS, which I take is a signal from
the PKCS#11 TC to say that if you can fit into this framework, you are
encouraged
to do so. For CKA_EC_PARAMS, using named curves is definitely the preferred
way to do it.

For the mechanism I can not pretend to be well versed in EdDSA, but
signature
seems to return a (R,s) tuple. So application could possibly be using
CKM_ECDSA to minimize the number of execution paths (and distinguish with
CKA_EC_PARAMS if necessary). A technical problem might come up, or it might
be judged by the PKCS#11 TC to be too confusing, so a switch to CKM_EDDSA
(or CKM_EC_EDDSA).

As a first step and while the RFCs and TCs are assigning new magic values, I
would suggest:
- CKA_KEY_TYPE: CKK_EC
- CKA_EC_PARAMS: 1.3.6.1.4.1.11591.15.1
- CKA_ALLOWED_MECHANISMS: [ CKM_ECDSA ]

If adding Ed25559 support in PKCS#11 is in the work for the (OpenSC or
otherwise), I could help adding the support to ssh-agent.

Sincerely,
-- 
Mathias Brossard