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

[Daniel Kahn Gillmor]

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?

> 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.  Since the private key is a superset of the public key, the
public key itself would be already present.  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?

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/component/page,shop.product_details/flypage,shop.flypage/product_id,19/category_id,22/manufacturer_id,0/option,com_virtuemart/Itemid,26/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 826 bytes
Desc: not available
Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20080801/25a7c507/attachment.bin