OpenSC smartcard access should use raw public keys,not X.509 certificates - openssh

This is a discussion on OpenSC smartcard access should use raw public keys,not X.509 certificates - openssh ; _______________________________________________ openssh-unix-dev mailing list openssh-unix-dev@mindrot.org https://lists.mindrot.org/mailman/li...enssh-unix-dev -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iQIVAwUBSFtNeczS7ZTSFznpAQL0Zw//TikO4oXODfSBg2mZOqIsdbtJfy8t7AGu u/5mw++Dsg/dlmez906Zt8UyXb7fSuBk/pSUxPLrftg2+lIvIrGLgijLGfWtTiKs pHZRXrfjhuEGFdZ3Iw7jpuV4ELkjSPiVezOehKok7X+zHdxM1I mwZL3OLBqciXb5 7qeU4Bi2GMTUZtSeA92w9uSrH5qYgsGh620fQ3VdNTQpZ0xGP4 XVWUTrhZdKfqDS h6OcyJwT1e01ua2DZcajs9zmoB2KoYMd7acsHmppVcoFc4dHFN XLsMMBeoQZqlm5 uAv5YDncF8ffldKCClbKXJMyC1ILK+UqrTBvMgJsF81+vpqH3O O2oebN4AU6Ukis 8ZLREdLCCewaAdDS2aTYH2FcfN+8j7N5sNwyy+MDC9jHTt8QPO vXnCh8PhgmRKPK LIo7BV1QJua0Syv7XypKh4fe3/td9sMR48mz1QLkyKenp/ISSNqXHXJeEExWY385 tpOLMIxZX8gbGoCl468oDexJjlLAOB8GmltL4+SrUI81ehejJU lVlYqbFVsvf4Zk EDfit6LDGG1CSrdCsOqJiICkrsmgxwklVMlNQbzlEd/cBuirZ8R3YqgUxiGDPqIw lGRydEy/I0/6+5iUcSrzeg8zV2PCQc2xaaiB0fck6xW9Eu5e3NJfi9ns3ehbE xHP mgE+oeGPcDw= =5r6+ -----END PGP SIGNATURE-----...

+ Reply to Thread
Results 1 to 14 of 14

Thread: OpenSC smartcard access should use raw public keys,not X.509 certificates

  1. OpenSC smartcard access should use raw public keys,not X.509 certificates

    _______________________________________________
    openssh-unix-dev mailing list
    openssh-unix-dev@mindrot.org
    https://lists.mindrot.org/mailman/li...enssh-unix-dev

    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v1.4.6 (GNU/Linux)

    iQIVAwUBSFtNeczS7ZTSFznpAQL0Zw//TikO4oXODfSBg2mZOqIsdbtJfy8t7AGu
    u/5mw++Dsg/dlmez906Zt8UyXb7fSuBk/pSUxPLrftg2+lIvIrGLgijLGfWtTiKs
    pHZRXrfjhuEGFdZ3Iw7jpuV4ELkjSPiVezOehKok7X+zHdxM1I mwZL3OLBqciXb5
    7qeU4Bi2GMTUZtSeA92w9uSrH5qYgsGh620fQ3VdNTQpZ0xGP4 XVWUTrhZdKfqDS
    h6OcyJwT1e01ua2DZcajs9zmoB2KoYMd7acsHmppVcoFc4dHFN XLsMMBeoQZqlm5
    uAv5YDncF8ffldKCClbKXJMyC1ILK+UqrTBvMgJsF81+vpqH3O O2oebN4AU6Ukis
    8ZLREdLCCewaAdDS2aTYH2FcfN+8j7N5sNwyy+MDC9jHTt8QPO vXnCh8PhgmRKPK
    LIo7BV1QJua0Syv7XypKh4fe3/td9sMR48mz1QLkyKenp/ISSNqXHXJeEExWY385
    tpOLMIxZX8gbGoCl468oDexJjlLAOB8GmltL4+SrUI81ehejJU lVlYqbFVsvf4Zk
    EDfit6LDGG1CSrdCsOqJiICkrsmgxwklVMlNQbzlEd/cBuirZ8R3YqgUxiGDPqIw
    lGRydEy/I0/6+5iUcSrzeg8zV2PCQc2xaaiB0fck6xW9Eu5e3NJfi9ns3ehbE xHP
    mgE+oeGPcDw=
    =5r6+
    -----END PGP SIGNATURE-----

  2. Re: OpenSC smartcard access should use raw public keys,not X.509 certificates

    _______________________________________________
    openssh-unix-dev mailing list
    openssh-unix-dev@mindrot.org
    https://lists.mindrot.org/mailman/li...enssh-unix-dev

    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v1.4.9 (GNU/Linux)

    iQIVAwUBSJIzgczS7ZTSFznpAQIJug//WxM3XyX6oyz5VPiAJ7CB6d2Szp8BrycM
    uavMBuHaR+eTJkwNWnuTBO5mVcVE+UD3EfKc8SwAnkoaHuPyqK 5G3IcPukFUSlHs
    1bbZZSao4Oj2VY34wZ0fTyBxJI/386JdqGo0vIN3hsvADVMG50fylfGLdm5DbqaB
    WGxXfoTX7QkND95TdVO+p+UQDahwrb6/AeL+X+bJKaXN4W+SBnfSqj5ChFn1cE2y
    jXtD+MEXwfiFVl7l/Xake7m+dvCpHYsrlpDvC5QF9tO0vA0wpud5QsYK7YTbuthz
    VI6/9GW00tD3XJiFvdnRv+KhTSssygQfsusllZfEEN+ZPJiv09wjci pCa24Mvio9
    TCHDK8Y+ERX/W/Af/iNCX6URme6IsbOPNpm0SooVR9imPgkM/XuQdVjm4DnMdv6t
    vobLN+Ry4jOdnUv3zJuIn/XmZsmxlsMt46XbC52mpozY8TftsyNHFI7w8Amr8BG4
    gZyheK3wtVdVXQOqFYnktGHGRFdLYf5cW6gObLIXAMx6UBdMoW njr31a77Xv4w9g
    Il9qYs3O2hTmJzpe6fZcWywtPOcmEt6pfnNV4LM26Y726pKWQJ lzUjazTZnBRrVE
    MOg4SfZGeI0pxf8pYdfsaAydyZonlKm+ETz5D5MmNPkzdOI4Qg R0+FKu/esNYBBd
    qlcjVSrwRRg=
    =fyme
    -----END PGP SIGNATURE-----

  3. Re: OpenSC smartcard access should use raw public keys,not X.509 certificates

    This is incorrect.
    The public key object is not always available on smartcards.
    Basic configuration is having private key + X.509 certificate on card.
    This is why the PKCS#11 patch [1] also don't assume public key existence.

    Alon.

    [1] http://alon.barlev.googlepages.com/openssh-pkcs11

    On 8/1/08, Daniel Kahn Gillmor wrote:
    > > The OpenSC smartcard framework supports access to both raw public
    > > keys and X.509 certificates on crypto tokens. When OpenSSH is
    > > compiled --with-opensc, it currently looks for X.509 certificates on
    > > any smartcard it uses. But OpenSSH itself uses raw public keys (and
    > > not X.509), so requiring the presence of an X.509 cert on the
    > > smartcard is unnecessary and potentially problematic.

    >
    > Any word on the patch i offered to fix this problem? The original
    > message can be found here:
    >
    > http://marc.info/?l=openssh-unix-dev...4687518903&w=2
    >
    > I've now opened it as a bug in the mindrot bugzilla as well:
    >
    > https://bugzilla.mindrot.org/show_bug.cgi?id=1498
    >
    > The patch is a narrow one, and affects only those folks who compile
    > --with-opensc. Is there anything i can do to encourage adoption of
    > it?
    >
    > Thanks for all the great work. I'm excited about 5.1!
    >
    >
    > --dkg
    >
    > _______________________________________________
    > openssh-unix-dev mailing list
    > openssh-unix-dev@mindrot.org
    > https://lists.mindrot.org/mailman/li...enssh-unix-dev
    >
    >
    >

    _______________________________________________
    openssh-unix-dev mailing list
    openssh-unix-dev@mindrot.org
    https://lists.mindrot.org/mailman/li...enssh-unix-dev


  4. Re: OpenSC smartcard access should use raw public keys,not X.509 certificates

    _______________________________________________
    openssh-unix-dev mailing list
    openssh-unix-dev@mindrot.org
    https://lists.mindrot.org/mailman/li...enssh-unix-dev

    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v1.4.9 (GNU/Linux)

    iQIVAwUBSJMTQczS7ZTSFznpAQKEZA/7BfY1mQ0tOqtZkDVdJS5HQ3dkr9uincoo
    o3IUzWj2Ccenu69fmOOXGAcOsbq2FR8StQLh5dMbt8HJ+j0eFc dNnB6YhUxXginN
    buk+bZjrtSSuiqRIVFcgYhQTTW77ugdDk1oLRr3BHVf9Jm4d4y hJhN25I5LAGfmm
    RaAvakj9wx+uSiinHFXMgvg+SiB6oUzEm5cm3AbNQCIP5R/4PVSUzB7x5PbrwyVB
    k1S24BDQjD1ufzbIXlAGbxlXGx+nHfO33zCyHcIuhHf7E4MBIQ OLY+bX1+5bBIIT
    mvoFZyLqYJQeBxC4diLqN+/mSxk9HaZfjhx6lZE4/+NvukXMNJ2gauXYUyGZ0T4V
    HlShr1ECpAuJ+jG5ZeOxHP3BGQrKbJegEJvbZFFNwb9vN3GsLM dMijSPehRVBBA+
    UG2oXaLbaxCi4il0AJfNJQCrOK6CJPAi1Vd951xApRHyOx5z8T kHqbVydCiPw7nN
    Nq5r1UmKaJmYsUoxUgx6E/qNzbf1/6agB2kR//hlZt1yx/zkME1OQlQsLMvJI1ax
    ImJsRnq/dC6oIWYwDN1caPUWLJGX7cATGvCRWq6GliUr5FBYlziz4bM7sC 1LM0p5
    0I1ZoevuHM6YGKZGLQ3xgYo2X2MzS7idyX8JQuIqjeUKWdh5Dq +xx4BEcdgxQnE4
    NtbQfmBeXIQ=
    =BG+7
    -----END PGP SIGNATURE-----

  5. Re: OpenSC smartcard access should use raw public keys,not X.509 certificates

    On 8/1/08, Daniel Kahn Gillmor wrote:
    > Well, for PKCS#11, you clearly are *interested* in the X.509
    > certificate, right? In that case, it wouldn't make sense to care
    > about a bare public key (unless you had some external mechanism to
    > retrieve the relevant certificate), so you're doing the right thing in
    > that patch. But for regular OpenSSH purposes, where X.509 is *not*
    > relevant, the bare public key is the thing that matters.


    No... You you interested in making ssh work...
    The PKCS#11 spec does not enforce the types of objects stored, so in
    order to save space many vendors choose not to store the public key
    object.
    So the minimal configuration is having private key (from which you can
    extract public key) as a protected object and X.509 certificate (from
    which you can extract public key) as public object.
    I am hoping to push the PKCS#11 implementation forward, and then there
    is no reason to keep the OpenSC specific one.

    > Help me understand: for a user whose smartcard:
    >
    > * allows storage of two private keys, but
    >
    > * is not capable of storing two full X.509 certificates (due to space
    > constraints), but
    >
    > * is capable of storing one X.509 cert and one additional raw public
    > key (i'm in this situation right now),
    >
    > how do you propose for OpenSSH to be able to make use of both keys?


    Oh... you truly got a problem.... I understand why you discuss this
    now... I would recommend choosing a different smartcard.

    Alon.
    _______________________________________________
    openssh-unix-dev mailing list
    openssh-unix-dev@mindrot.org
    https://lists.mindrot.org/mailman/li...enssh-unix-dev


  6. Re: OpenSC smartcard access should use raw public keys,not X.509 certificates

    On Fri, Aug 01, 2008 at 06:16:01PM +0300, Alon Bar-Lev wrote:
    > > how do you propose for OpenSSH to be able to make use of both keys?

    >
    > Oh... you truly got a problem.... I understand why you discuss this
    > now... I would recommend choosing a different smartcard.


    The problem is that this is a reality even for Cryptoflex eGate
    users. Since it used to be the gold standard OpenSC card I would
    appreciate a good solution for it. Granted, it has been unavailable
    for a while, but I expect many to still have them in use.


    //Peter
    _______________________________________________
    openssh-unix-dev mailing list
    openssh-unix-dev@mindrot.org
    https://lists.mindrot.org/mailman/li...enssh-unix-dev


  7. Re: OpenSC smartcard access should use raw public keys,not X.509 certificates

    _______________________________________________
    openssh-unix-dev mailing list
    openssh-unix-dev@mindrot.org
    https://lists.mindrot.org/mailman/li...enssh-unix-dev

    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v1.4.9 (GNU/Linux)

    iQIVAwUBSJOWjszS7ZTSFznpAQKgtg/+NbUdOp1vPt0KZ25Wz01GhAbmaueRYEWE
    3ay6DyVnTKh8vVA/LV77IZx1mAsORJEW4MstBnN2VWm58PggnLsqzctdguUPghsI
    f4TkgQ4CJXO+/ney/wLz8xQPNdWvG9pqgsxF6Om75CRiMVk8QW4WvU1yMCOTGSev
    Hbd3dC+YeKQRdW8rOT+txGUltfYiYzLH4ZeqN3b1e8sPKsbThe sezhXVsl1+bxoN
    u7UsiVbM3N1TZnVYCJiQ+uAlWlpx0xEAHwCL8AoCfaoVVHQMWA pp2ZAV8OZB7Nvj
    fQ14gGaIrDh1hFSl7AGfl9decBE0zhy5eW3libb9ITBgcvzScg +LB+86HbI0V1oM
    n2qjuzm/VDobeiiNe/3W7CZ9skIuUlWD7my+6mCcVAf3CVT+2GyeOjRHkdgIth6h
    9Kb2Cgx3VDOJjL0MhoEjE49HhItRJ3dz05iI8KbPX7AcqnebpK 1wcRCqtD3kDMaY
    s/N63xeDhIMeU5hsM95PADwPMVajsQC9g67oaCC4hevE2Zsl6/dtOCzXNX5eyTIg
    pUL35izFQPK5mjUShiQl2LDE+4s/z+xjU9K2bsfbk3L7l7xxEfBFsKvUTpr8UjsC
    aDN80mBt5oNWtUyAg4XA7IZXy6JJklJsZAt5B0QABN5eoe/K834i5JblUsCGBJku
    Bgo8oHFyP7I=
    =lgTU
    -----END PGP SIGNATURE-----

  8. Re: OpenSC smartcard access should use raw public keys,not X.509 certificates

    On Fri, Aug 01, 2008 at 07:04:45PM -0400, Daniel Kahn Gillmor wrote:
    > Since the private key is a superset of the public key, the public
    > key itself would be already present.


    Of course, but I don't think (m)any card OS will create a virtual
    file EF for the public key that actually fetches from the private
    key. That would have to be done in higher level software, but that
    code is not allowed to read the private key. (For good reason.)


    //Peter

    _______________________________________________
    openssh-unix-dev mailing list
    openssh-unix-dev@mindrot.org
    https://lists.mindrot.org/mailman/li...enssh-unix-dev

    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v1.4.7 (GNU/Linux)

    iD8DBQFIk6WjhR3Q0dhIfEgRArVdAJ9zx/IoENK8LnO5kdPdnMMYehQRCQCfdrkD
    7d2HeZmkBZHbrDyP5jGzaP4=
    =0LMe
    -----END PGP SIGNATURE-----


  9. Re: OpenSC smartcard access should use raw public keys,not X.509 certificates

    _______________________________________________
    openssh-unix-dev mailing list
    openssh-unix-dev@mindrot.org
    https://lists.mindrot.org/mailman/li...enssh-unix-dev

    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v1.4.9 (GNU/Linux)

    iQIVAwUBSJOspczS7ZTSFznpAQKdTA/9GWWztegS2pX0IAeCegOpD5XKFShI6Q4G
    OAkj5p3pEhiaghey0XsdI0HU8/qF3rIDr0FbiAGCZ7Z5ET4YviSPbNpNlaBUO9bk
    zsoAa//ywdTkKgBRYI/DjVG4VpfLRoOPSVlmD0jNbGaXWfU1utCUuOzKLlQJ3PvT
    u17hPQqlSIq8jHu2ALM0tzyt0tsRsZlPVXw1hO6cx81BH1q2G9 DDYWFRgJ5AD8M3
    qKoaHpMQkrbZFfqYg4tYqyFKWtEjYwkpgf8mbiwC0NM1BJtDmQ dZuVgf9uIyA+Rz
    hQzsZDf45Ryg4gGhW5vLMVEYm9ziDtQ/G0GfeAr6GoOsxi5mF/tDQ9eCa/oPeP8N
    YwoGE03X+OiR3z1lMGmSQIN5BdB3XQjQ3JcEWBbgAqGTz+6yE4 gpJARETyPySAao
    ViS5ZauvDfrj8hrgfalxQfFYAl8ADu33jY0He70D4H7fSOQSN7 241cq7aUaOQx2V
    tMLDjJZ6oTbGWEip+O+6nKAkNsMY/gKGi2GI+ms5BJNTqEjKtfiiO2qmyMIJwX1M
    wBkTcWCKO/gsWe3XQjFX/QqARMe1YCYn2LYkxNxPtARQLy4dn7uoLt+GKFcec/jR
    zgaYsaJlRBzB0ptLxhxFlP72fzw8+hrfSzNiDqFvXbqFAzz4jj Gz2fMS8k8gn0pI
    a7FU23ideX8=
    =Gmth
    -----END PGP SIGNATURE-----

  10. Re: OpenSC smartcard access should use raw public keys,not X.509 certificates

    On Fri, Aug 01, 2008 at 08:39:01PM -0400, Daniel Kahn Gillmor wrote:
    > I understand why the code accessing the card itself shouldn't be
    > allowed to read the private components of the secret key. But
    > surely storing the parameters separately and providing access to
    > the public ones would be reasonable?


    It's an idea, but no cards I've seen work like that.


    > I'm aware that i don't know much about the on-card formats for
    > these devices, though, so i'm probably wishing for things that seem
    > reasonable from a higher level but might run up against
    > implementation limitations. I appreciate your pointing out some of
    > the more nuanced concerns.


    Sorry - I thought you were more familiar with on-card storage.

    ISO 7816-4 card OSes implement a quite simple file system with
    directories (DF) and files (EF), which can be navigated and accessed
    depending on the various security features implemented by the card
    OS. (every card does this differently)


    > At any rate, i think my point still stands for any stored
    > certificates: Is there any reason that the card itself (or the
    > drivers accessing the card) couldn't extract the public key
    > information from a stored certificate?


    No reason in theory, but in practice cards can't parse certificates.

    As for drivers - yes, if the public key components are actually
    available in the certificate then of course they could be extracted.


    //Peter

    _______________________________________________
    openssh-unix-dev mailing list
    openssh-unix-dev@mindrot.org
    https://lists.mindrot.org/mailman/li...enssh-unix-dev

    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v1.4.7 (GNU/Linux)

    iD8DBQFIk7KjhR3Q0dhIfEgRAlaEAKDGksZQSgzodPPz/HtQAdDigZvGewCeLRPr
    C62qEO5JgybPEPCW9w3ZYPo=
    =GxXN
    -----END PGP SIGNATURE-----


  11. Re: OpenSC smartcard access should use raw public keys,not X.509 certificates

    On 8/2/08, Peter Stuge wrote:
    > On Fri, Aug 01, 2008 at 07:04:45PM -0400, Daniel Kahn Gillmor wrote:
    > > Since the private key is a superset of the public key, the public
    > > key itself would be already present.

    >
    >
    > Of course, but I don't think (m)any card OS will create a virtual
    > file EF for the public key that actually fetches from the private
    > key. That would have to be done in higher level software, but that
    > code is not allowed to read the private key. (For good reason.)


    For achieving sane user experience there is a need to access a public
    object holding the public key. This allows to enumerate keys without
    login each time the smartcard is inserted.

    Alon.
    _______________________________________________
    openssh-unix-dev mailing list
    openssh-unix-dev@mindrot.org
    https://lists.mindrot.org/mailman/li...enssh-unix-dev


  12. Re: OpenSC smartcard access should use raw public keys,not X.509 certificates

    On 8/2/08, Peter Stuge wrote:
    > On Fri, Aug 01, 2008 at 06:16:01PM +0300, Alon Bar-Lev wrote:
    > > > how do you propose for OpenSSH to be able to make use of both keys?

    > >
    > > Oh... you truly got a problem.... I understand why you discuss this
    > > now... I would recommend choosing a different smartcard.

    >
    >
    > The problem is that this is a reality even for Cryptoflex eGate
    > users. Since it used to be the gold standard OpenSC card I would
    > appreciate a good solution for it. Granted, it has been unavailable
    > for a while, but I expect many to still have them in use.


    Maybe a better solution is to implement on disk storage for public
    objects which will be available as if they were on token?
    This will allow the users to use their token with other
    applications... We discuss here OpenSSH, but please keep in mind that
    it is only one application with not-so-good smartcard support
    built-in.
    Users would like to use Firefox, OpenVPN, PSI and other software. All
    require a certificate on token.

    Alon.
    _______________________________________________
    openssh-unix-dev mailing list
    openssh-unix-dev@mindrot.org
    https://lists.mindrot.org/mailman/li...enssh-unix-dev


  13. Re: OpenSC smartcard access should use raw public keys,not X.509 certificates

    _______________________________________________
    openssh-unix-dev mailing list
    openssh-unix-dev@mindrot.org
    https://lists.mindrot.org/mailman/li...enssh-unix-dev

    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v1.4.9 (GNU/Linux)

    iQIVAwUBSJR/u8zS7ZTSFznpAQIXLA/+Ji1VyA6fcQ/bLNfr3naql6yinwLglKls
    Hf08vK1NDMqwcTral3lM7nP8s5du0rAgzu5E0W3DctlhsisD9e yRT9jb5z65Nwgt
    IwndJ0vlbjjcCQv2I58rAWMN4anE3IJ8M7FcHnvCLfCnKGaG2W 7TlfwLcmW1zfuQ
    LRXdz2Q1M156XcgLBd9wgoUlKjoVYcp406r6KTyzLe5YBBOvgv UzAYc7rSHdKF4G
    Eq4r2EkQuhbUQnK4BGzzXSV1Qx6YT8Lvc7ECuvXqAQJzy18w3B Pl/FNVPFEq0ZHN
    INBPunfNYo5lp3iQQ/+4JLAz0maPq0sEH84ooH6qf+DDB0PPquqWLY//TJguV5+d
    6fszhgqesaDrHiblhp62ZXgK2b8gO4yXebkiClqQMV8xBHnjj/3xOWtMAT22l94k
    aJYz1HxR9Kh1QzqfR1CKxkRTvPX6PtA87DmQvx5MeRDxTLgT7C KR9BD6P8qVjxm/
    +rCtZlXisXSt4zE1hf9eE5OC1BmVeYbijKNTDM0hPXKw8ixRMW 3PH04xXJZdX5tE
    cygozA0zXIvHgBp935v6Oby4/rU6tA6dDke7E1n/Xs3FZ3CjHcBLJR6DhzpXqJ/q
    Pjly9Zww21bpuE0xfyNlz9EIKV9b+/jcIT54Z2kJB2CRnSDM+knrZIHBpaTcXWOu
    eM1nGT/y4zg=
    =GS/S
    -----END PGP SIGNATURE-----

  14. Re: OpenSC smartcard access should use raw public keys, not X.509certificates

    [Sorry for jumping in late on this.]

    Daniel Kahn Gillmor wrote:
    > On Fri 2008-08-01 11:16:01 -0400, Alon Bar-Lev wrote:
    >
    >> No... You you interested in making ssh work...

    >
    > ?? i'm afraid i don't understand this sentence.
    >
    >> The PKCS#11 spec does not enforce the types of objects stored, so in
    >> order to save space many vendors choose not to store the public key
    >> object.

    >
    > Perhaps i'm confused about the PKCS#11 specification: it is my
    > understanding that an X.509 certificate is actually a superset of the
    > public key object itself [0]. Therefore, if you're storing the X.509
    > certificate, you're already storing the public key. (and in fact, the
    > public key itself is already stored in the private key object, as
    > well. For RSA, it is usually represented as the first two components
    > of the 5-tuple key). Why would being able to produce the public key
    > consume *more* space -- wouldn't the public key already be present?
    >

    Yes, but on the card there may be a pubkey object as well as a cert
    object, (which should match), but stored separately thus taking
    up more space.

    >> So the minimal configuration is having private key (from which you
    >> can extract public key) as a protected object and X.509 certificate
    >> (from which you can extract public key) as public object.

    >
    > I'm afraid i don't see this reasoning either. The minimal
    > configuration for an RSA smartcard, it would seem, is an RSA private
    > key.


    Yes. But there needs to be some way to associate the private key
    with the the pubkey. The minimal would be the user has to entry in
    some assoication manually. In practice, a certificate is
    usually stored on a card.

    > Since the private key is a superset of the public key, the
    > public key itself would be already present.


    Yes, but the card may not allow you to read modulus and exponent.

    > X.509 certificates are
    > (sort of) nice, but they're just gravy if your goal is just a hardware
    > implementation/offload of RSA.
    >
    > (the same is true of other certificate formats, fwiw, such as those
    > specified by RFC 4880 [1]. I don't want this discussion to turn into
    > a debate on the merits of the X.509 certificate format itself; the
    > point is that *any* certificate is superfluous if you're interested in
    > using a hardware token as a raw RSA engine. Certificates can be
    > stored and distributed in many other ways.)
    >
    >> I am hoping to push the PKCS#11 implementation forward, and then there
    >> is no reason to keep the OpenSC specific one.

    >
    > If your PKCS#11 implementation excludes the ability to use raw RSA
    > keys on hardware tokens, then i certainly hope OpenSSH doesn't remove
    > the OpenSC-specific one.
    >
    >> Oh... you truly got a problem.... I understand why you discuss this
    >> now... I would recommend choosing a different smartcard.

    >
    > I've provided an example of a relatively recent, widely-deployed card
    > (still currently available at retail, fwiw [2]) that behaves
    > reasonably under all circumstances we've discussed (at least with my
    > patch applied). But the card doesn't have enough on-board memory to
    > store the data associated with an extra X.509 certificate. I really
    > don't think that "you need to get new hardware" is an appropriate
    > response.
    >
    > I asked earlier for an example of a card that can store (and emit)
    > X.509 certificates, but is incapable of producing a public key. Could
    > you provide a concrete example? If i can find (or get remote access
    > to) such a card, i'd be happy to adjust my patch to be able to pull
    > From both the X.509 certificates and the raw public keys on the card.
    > Would that seem reasonable to you? Can you identify such a card?


    But you are mixing up what is on the card and what OpenSC (or some other
    middleware) can do for you. An example of a card which does not store the
    pubkey seperatly on the card is the PIV card. It stores objects, including
    cert objects and private keys.

    But pkcs15-piv.c uses the OpenSC pkcs15 emulation code sc_pkcs15emu_*
    to simulate a a pubkey object. It does this be reading the cert, and
    extracting the pubkey. So from PKCS#11 or PKCS#15 it appears the card
    does have a pubkey object.

    With other cards, it is up to the author of the libopensc/card-.C
    and pkcs15-.c modules to implement this if needed for their card.

    Your patch would be better if it tried for a cert, and if not available,
    then try for a pubkey.

    >
    > Regards,
    >
    > --dkg
    >
    > [0] http://tools.ietf.org/html/rfc5280#section-4.1.2.7
    > [1] http://tools.ietf.org/html/rfc4880#page-20
    > [2] http://www.usasmartcard.com/componen...art/Itemid,26/
    >
    >
    > ------------------------------------------------------------------------
    >
    > _______________________________________________
    > openssh-unix-dev mailing list
    > openssh-unix-dev@mindrot.org
    > https://lists.mindrot.org/mailman/li...enssh-unix-dev


    --

    Douglas E. Engert
    Argonne National Laboratory
    9700 South Cass Avenue
    Argonne, Illinois 60439
    (630) 252-5444
    _______________________________________________
    openssh-unix-dev mailing list
    openssh-unix-dev@mindrot.org
    https://lists.mindrot.org/mailman/li...enssh-unix-dev


+ Reply to Thread