Bug 1498 - OpenSC smartcard access should use raw public keys, not X.509 certificates
Summary: OpenSC smartcard access should use raw public keys, not X.509 certificates
Status: CLOSED WONTFIX
Alias: None
Product: Portable OpenSSH
Classification: Unclassified
Component: Smartcard (show other bugs)
Version: 5.1p1
Hardware: Other Linux
: P2 normal
Assignee: Assigned to nobody
URL:
Keywords: patch
Depends on:
Blocks:
 
Reported: 2008-08-01 07:46 AEST by Daniel Kahn Gillmor
Modified: 2011-01-24 12:34 AEDT (History)
1 user (show)

See Also:


Attachments
patch so that OpenSC uses public keys instead of certificates (5.38 KB, patch)
2008-08-01 07:46 AEST, Daniel Kahn Gillmor
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Daniel Kahn Gillmor 2008-08-01 07:46:40 AEST
Created attachment 1555 [details]
patch so that OpenSC uses public keys instead of certificates

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.

Everyone who has an X.509 certificate already has (embedded in the
cert) a public key.  But you can load a raw key onto a card without
having a certificate.  So raw keys would seem to be the lowest common
denominator.  Is there some other reason to require an X.509
certificate that i'm missing?

The attached patch allows OpenSSH to use certificateless RSA keys on
any OpenSC-supported hardware crypto token.  Fixing this bug also
simplifies the sc_read_pubkey() implementation, reduces the number of
#includes in scard-opensc.c, and removes a compilation warning, for
whatever that's worth.

The patch was developed and tested against openssh 4.7p1 (from debian
unstable), but it also applies cleanly to CVS HEAD.  I used
libopensc2-dev version 0.11.4, and did my testing against an Axalto
CryptoFlex eGate 32k hardware token.

I'd appreciate any feedback on the patch.  If i can do anything to
encourage its adoption into the upstream codebase, let me know what it
needs.
Comment 1 Daniel Kahn Gillmor 2008-08-01 07:47:24 AEST
This was initially reported on 2008-06-20 on openssh-unix-dev:

  http://marc.info/?l=openssh-unix-dev&m=121394687518903&w=2
Comment 2 Damien Miller 2009-01-21 21:36:18 AEDT
I don't know enough about OpenSC to render an opinion on this, and I suspect that the other active developers are in the same boat. I'd suggest that you solicit some feedback and testing on the openssh-unix-dev@ mailing list as a way to move this forward.
Comment 3 Daniel Kahn Gillmor 2009-01-22 03:40:24 AEDT
The consensus on the list seemed to be that the patch was *not* acceptable as it currently stands because apparently some devices offer certificates but not raw public keys.  Unfortunately no one identified a specific device, so i have no way of testing.

Probably the right thing to do is to scan for both types of object, to be able to handle both cases.  This makes the code bulkier, but if there's no objection to that, i'll try to cook up a patch.
Comment 4 Damien Miller 2010-04-26 10:46:18 AEST
Rendered obsolete by the replacement of OpenSC with PKCS#11, which incidentally uses certificates by default :)
Comment 5 Damien Miller 2011-01-24 12:34:01 AEDT
Move resolved bugs to CLOSED after 5.7 release