Simon Josefsson
2015-Oct-08 14:17 UTC
[PATCH] Enabling ECDSA in PKCS#11 support for ssh-agent
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. 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 >>-------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 472 bytes Desc: not available URL: <http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20151008/b0dc0f82/attachment.bin>
Thomas Calderon
2015-Oct-08 14:45 UTC
[PATCH] Enabling ECDSA in PKCS#11 support for ssh-agent
Hi Simon, Agreed, ecParameters are not suitable but namedCurve should do the trick. Did you mean: 1.3.6.1.4.1.11591.15.1 which seems reserved by GNU for Ed25519 (https://www.gnu.org/prep/standards/html_node/OID-Allocations.html)? As for putting it into the standard, not sure this is even needed. Cheers, Thomas On Thu, Oct 8, 2015 at 3:17 PM, Simon Josefsson <simon at josefsson.org> 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. > > 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
2015-Oct-08 15:37 UTC
[PATCH] Enabling ECDSA in PKCS#11 support for ssh-agent
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>
Damien Miller
2015-Oct-08 17:29 UTC
[PATCH] Enabling ECDSA in PKCS#11 support for ssh-agent
On Thu, 8 Oct 2015, Douglas E Engert wrote:> 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.Ed25519 is a different algorithm to ECDSA, not just a different curve. -d