On Thu, Oct 8, 2015 at 2:49 AM, Simon Josefsson <simon@xxxxxxxxxxxxx> wrote: > Mathias Brossard <mathias@xxxxxxxxxxxx> 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 _______________________________________________ openssh-unix-dev mailing list openssh-unix-dev@xxxxxxxxxxx https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev