In the thread "The best practice of master/sub key capabilities", Dongsheng Song asked for advice and gave an example where a master key has both Certify and Authenticate set, and an example where a subkey has both Sign and Authenticate set. I wrote in a reply in that thread:
> But it suddenly dawned on me you might have an actual issue when you > assign both Sign and Authenticate capabilities to a key! > Authentication is pretty much proving that you can sign what the > server sends you. It might be the case that these signatures can > actually pass for data signatures or key certifications! I don't > think RFC 4880 says anything about authentication (except when used > to refer to data signatures and key certifications). Checking the > OpenPGP Card Specification 3.0, it would seem that the key in the > Authenticate command can indeed issue signatures, since the PKCS#1 > padding is identical to the Sign command, and there is no check on > the signed data. Does GnuPG (or GPG-Agent in 2.1) actually check that the challenge sent by the server is not a validly formatted OpenPGP signature or certification? And should GnuPG in general perhaps refuse to assign Authenticate capability to key material with other signature capabilities, just to be safe? Oh, I forgot to mention in that other mail that I'm fairly sure I actually had a signature subkey in the Authenticate slot of an OpenPGP v.1 card, which worked fine. This corresponds with the observation that the padding is the same for both operations. Peter. -- I use the GNU Privacy Guard (GnuPG) in combination with Enigmail. You can send me encrypted mail if you want some privacy. My key is available at <http://digitalbrains.com/2012/openpgp-key-peter> _______________________________________________ Gnupg-users mailing list [email protected] http://lists.gnupg.org/mailman/listinfo/gnupg-users
