Mixing Authenticate capability with others

[Peter Lebbing]

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>