On 5/10/2011 1:10 AM, Jerome Baum wrote: > On Tue, May 10, 2011 at 07:01, Grant Olson <[email protected] > <mailto:[email protected]>> 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
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Gnupg-users mailing list [email protected] http://lists.gnupg.org/mailman/listinfo/gnupg-users
