Best practice for periodic key change?

[Jerome Baum]

On Tue, May 10, 2011 at 07:01, Grant Olson <kgo at grant-olson.net> wrote:

> On 5/10/2011 12:41 AM, Daniel Kahn Gillmor wrote:
> > 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
> standard.
>

So given that, I guess we could still distinguish between a master key
signature and a sub-key signature, to conform w/ signature laws? e.g. an
option for GnuPG: reject-subkey-signatures -- then an installation w/ this
option set would validate only master key signatures, practically forbidding
signing sub-keys. No need to change OpenPGP for this.

The CA would then sign the master key that is generated on-card, and the
certification just won't apply to the sub-keys. Does this solve the "all
signatures _must_ be generated on-card" issue?

-- 
Jerome Baum

tel +49-1578-8434336
email jerome at jeromebaum.com
-- 
PGP: A0E4 B2D4 94E6 20EE 85BA E45B 63E4 2BD8 C58C 753A
PGP: 2C23 EBFF DF1A 840D 2351 F5F5 F25B A03F 2152 36DA
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20110510/4b771f24/attachment.htm>