Re: The best practice of master/sub key capabilities

[Simon Josefsson]

Dongsheng Song  writes:

> Hi all,
>
> When I create new master/sub key, in the following 2 choice, I'm
> wondering which is better?
>
> 1) master key have SCEA capabilities
>
> sec  rsa4096/A19676A1
>  created: 2015-08-20  expires: never   usage: SCEA
>  trust: ultimate  validity: ultimate
> ssb  rsa4096/27ADD750
>  created: 2015-08-20  expires: never   usage: SEA
>
> 2) master key have only Certify capability
>
> sec  rsa4096/1F8AFCAD
>  created: 2015-08-20  expires: never   usage: C
>  trust: ultimate  validity: ultimate
> ssb  rsa4096/8E1D2A87
>  created: 2015-08-20  expires: never   usage: SEA

I would use a SC master key because I would want to use it to certify
other's keys, and would also be able to use it to sign statements in
case something bad happened to my sub-keys.

I would use three separate sub-keys, one each for the three SEA usages.

/Simon


signature.asc
Description: PGP signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: The best practice of master/sub key capabilities

[Peter Lebbing]

On 21/08/15 11:31, Dongsheng Song wrote:
> But I still did't know why the master key have sign and certify
> capabilities in the default ?

I suppose because it doesn't hurt. They're both signatures in essence;
cryptographically they are the same and exchangable. The difference only
lies in the interpretation.

Also note that anyone who has access to the primary key material can
issue data signatures at will. They could either add the Sign capability
to the key or (easier) create a new subkey with which to issue signatures.

The actual reason why the default is as it is can probably best be
answered by someone else, though, since I can only guess.

HTH,

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 

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: The best practice of master/sub key capabilities

[Dongsheng Song]

Thanks, now I see why I should use a exclusively subkey for
authenticate capability.

But I still did't know why the master key have sign and certify
capabilities in the default ? I think the sign capability should move
to a exclusively subkey.

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

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 

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: The best practice of master/sub key capabilities

[Peter Lebbing]

On 20/08/15 17:01, Peter Lebbing wrote:
> Most importantly, it's generally advised not to do encryption and 
> signing with the same key material.

This is just a general recommendation, and abusing the fact a key is
used for both encryption and signatures is an intricate matter. But
since OpenPGP supports subkeys, the matter is easily avoided completely
by using a separate subkey for encryption, so it's a good idea to do so.

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.

It seems like a genuinely bad idea to assign Authenticate capability to
a key that has Certify or Sign set. Even if GnuPG or GPG-Agent does
checks to catch abuse, it's just asking for trouble that is easily
avoided, in my opinion.

HTH,

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 

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users