Best practice for periodic key change?

[Grant Olson]

On 5/10/2011 1:10 AM, Jerome Baum wrote:
> On Tue, May 10, 2011 at 07:01, Grant Olson <kgo at grant-olson.net
> <mailto: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?
> 
>

I haven't been totally following this thread, but...

The card itself only has one Signature key slot.  If you generate this
key on-board, that will be both the certification key and the signing
key.  If you migrate a signing sub-key, you'll still have an offline
master key.  The card itself doesn't know if you have a signing subkey
or not.  It just knows, "This is the signing key I use."

If you generate all keys on-card, you only have a master
Certification/Signing key, along with (optionally) one encryption and
one authentication key.

If you didn't generate the keys on-card, and have an offline master key,
the card itself won't know about it, but the certificate will still
imply that the on-card signing key isn't the master key, since the card
only allows one signing key and don't know the difference.

But there's no way to prove that the keys were originally generated
on-card, and weren't imported from a software private key where there
was never a separate master certification key.

I think a 'generated on card' flag is something that you could probably
fit into the constraints of a smart-card spec, if this is all you need.
 But at least in the US, you'd probably need some sort of
certification/approval process (like the NIST lab) to demonstrate to the
government that you're actually setting this flag correctly.  The same
way PGP Corp software has some government approvals that gpg will never
have.

-- 
Grant

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 552 bytes
Desc: OpenPGP digital signature
URL: </pipermail/attachments/20110510/f7869a16/attachment.pgp>