Best practice for periodic key change?
kgo at grant-olson.net
Tue May 10 07:01:01 CEST 2011
On 5/10/2011 12:41 AM, Daniel Kahn Gillmor wrote:
> On 05/10/2011 12:32 AM, Jerome Baum wrote:
>> Is that an implementation problem? i.e. is it possible to write an
>> implementation that does distinguish, or is it technically impossible w/out
>> processing the entire data on-card?
> As i understand the process, i think it would be necessary to pass all
> the data through the card in order to for the card to know which type of
> signature it was making.
> I know nothing of the details of how these cards are implemented,
> though. Maybe they do this already? it seems like performance would be
> problematic if you were signing something like a multi-MiB document,
> given the speed of most smartcards.
> Maybe one of the folks with experience implementing these devices can
> give more concrete details?
I can confirm. The cards only get the hash and sign that. The trouble
is the the "smart" cards are pretty dumb by modern standards. They
don't actually know much about OpenPGP itself, they basically just do
RSA signing, encryption, and decryption. gpg passes the minimal
operations off to the card in very simple APDU commands.
The smartcard spec itself doesn't even acknowledge the difference
between a certification sig vs a normal sig. And even with a valid
smart-card, you still need to retrieve the public key from the
keyservers when setting up your card. The whole public key is just too
much info to store on the card.
This is pure speculation on my part, but now that the chip-cards aren't
that powerful, and the even less powerful contact-less smart-cards are
becoming more popular, I don't expect the standard to get much more
sophisticated in the near future. Maybe ECC gets added in the new spec,
but I can't see the stuff you guys are talking about hitting the 3.0
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 552 bytes
Desc: OpenPGP digital signature
More information about the Gnupg-users