Mailing List Archive

Best practices for obtaining a new GPG certificate
Hello,

My existing GPG certificate is going to expire in less than a month.
I'd like to know current best practices for obtaining a new one? In
particular I'm looking for the best protocol and strength for a
security not a performance stance. The certificate will mainly be used
for verifying and signing sent messages, and tagging git commits on
personal servers. Devices used will be Windows 10 pcs and tablets and
Android (version 10 and 11) phones and tablets.
Suggestions welcome.
Thanks.
Dave.

_______________________________________________
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Best practices for obtaining a new GPG certificate [ In reply to ]
On Thu, 18 Mar 2021 00:06, David Mehler said:

> My existing GPG certificate is going to expire in less than a month.
> I'd like to know current best practices for obtaining a new one? In

Do you really want a new one? Usually it is easier to prolong your key.
By default a new key has an expire data so that unused keys and those
with forgotten passphrase will eventually expire. In general you just run

gpg --quick-set-expire FINGERPRING EXPIREDATE

Expire dat may be something like 5y for 5 years or an explicit date like
2024-12-31.

Here is an example

$ gpg -K A94A6DF8CDF934DB2BF98A46254A558A7E6D52D8

sec ed25519 2021-03-15 [SC] [expires: 2023-03-15]
A94A6DF8CDF934DB2BF98A46254A558A7E6D52D8
uid [ unknown] foo@example.de
ssb cv25519 2021-03-15 [E]
989ABB95E888956DBD5D7F66C376233B98457556

$ gpg --quick-set-expire A94A6DF8CDF934DB2BF98A46254A558A7E6D52D8 4y


$ gpg -K A94A6DF8CDF934DB2BF98A46254A558A7E6D52D8

sec ed25519 2021-03-15 [SC] [expires: 2025-03-17]
A94A6DF8CDF934DB2BF98A46254A558A7E6D52D8
uid [ unknown] foo@example.de
ssb cv25519 2021-03-15 [E]
989ABB95E888956DBD5D7F66C376233B98457556


Send the public key then to your peers, keyserver, web key directory, or
wherever.


Shalom-Salam,

Werner


--
Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz.
Re: Best practices for obtaining a new GPG certificate [ In reply to ]
Hello,

Thanks all. I am definitely wanting a new key.

With regards the info John posted:

gpg --expert --full-gen-key
Please select what kind of key you want:
   (1) RSA and RSA (default)
   (2) DSA and Elgamal
   (3) DSA (sign only)
   (4) RSA (sign only)
   (7) DSA (set your own capabilities)
   (8) RSA (set your own capabilities)
   (9) ECC and ECC
  (10) ECC (sign only)
  (11) ECC (set your own capabilities)
  (13) Existing key
  (14) Existing key from card

in the output there's ECC output should I go with an ECC-style key or
RSA? As regards RSA keysize I typically use 4096.

Thanks.
Dave.


On 3/18/21, Werner Koch <wk@gnupg.org> wrote:
> On Thu, 18 Mar 2021 00:06, David Mehler said:
>
>> My existing GPG certificate is going to expire in less than a month.
>> I'd like to know current best practices for obtaining a new one? In
>
> Do you really want a new one? Usually it is easier to prolong your key.
> By default a new key has an expire data so that unused keys and those
> with forgotten passphrase will eventually expire. In general you just run
>
> gpg --quick-set-expire FINGERPRING EXPIREDATE
>
> Expire dat may be something like 5y for 5 years or an explicit date like
> 2024-12-31.
>
> Here is an example
>
> $ gpg -K A94A6DF8CDF934DB2BF98A46254A558A7E6D52D8
>
> sec ed25519 2021-03-15 [SC] [expires: 2023-03-15]
> A94A6DF8CDF934DB2BF98A46254A558A7E6D52D8
> uid [ unknown] foo@example.de
> ssb cv25519 2021-03-15 [E]
> 989ABB95E888956DBD5D7F66C376233B98457556
>
> $ gpg --quick-set-expire A94A6DF8CDF934DB2BF98A46254A558A7E6D52D8 4y
>
>
> $ gpg -K A94A6DF8CDF934DB2BF98A46254A558A7E6D52D8
>
> sec ed25519 2021-03-15 [SC] [expires: 2025-03-17]
> A94A6DF8CDF934DB2BF98A46254A558A7E6D52D8
> uid [ unknown] foo@example.de
> ssb cv25519 2021-03-15 [E]
> 989ABB95E888956DBD5D7F66C376233B98457556
>
>
> Send the public key then to your peers, keyserver, web key directory, or
> wherever.
>
>
> Shalom-Salam,
>
> Werner
>
>
> --
> Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz.
>

_______________________________________________
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Best practices for obtaining a new GPG certificate [ In reply to ]
> I'd like to know current best practices for obtaining a new one?

This question gets asked so often that it has its own FAQ entry. Yes,
parts of the FAQ are outdated, but this particular one is very current.

https://www.gnupg.org/faq/gnupg-faq.html#tuning

* You don't need to "tune" GnuPG before using it
* The defaults for key generation are conservative and safe
* Don't overthink things. :)

My sometimes-snarky (but completely-sincere) opinion on this evergreen
question is, "unless you know what you're doing and why you're doing it,
stick with the defaults."

The other piece of sometimes-snarky (but also completely-sincere) advice
is that a good 90% of the web pages you find that talk about how to
create the "perfect" GnuPG key are absolutely full of it.

_______________________________________________
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Best practices for obtaining a new GPG certificate [ In reply to ]
On Thu, 18 Mar 2021 19:34, David Mehler said:

> in the output there's ECC output should I go with an ECC-style key or
> RSA? As regards RSA keysize I typically use 4096.

The next default is ECC (ed25519+cv25519) which is supported by most
OpenPGP implementations. Only if you have a need to communicate with
some niche implementaions you need to use rsa3072.

You may also skip the menu thing and use

gpg --quick-gen-key bar@example.com future-default


Salam-Shalom,

Werner

--
Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz.
Re: Best practices for obtaining a new GPG certificate [ In reply to ]
> The next default is ECC (ed25519+cv25519) which is supported by most
> OpenPGP implementations. Only if you have a need to communicate with
> some niche implementaions you need to use rsa3072.

Last I checked, Thunderbird 78 did not support ed25519+cv25519 keys.
That's not a niche implementation.

_______________________________________________
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Best practices for obtaining a new GPG certificate [ In reply to ]
On Fri, 19 Mar 2021 08:33:17 +0100,
Robert J. Hansen via Gnupg-users wrote:
>
> > The next default is ECC (ed25519+cv25519) which is supported by most
> > OpenPGP implementations. Only if you have a need to communicate with
> > some niche implementaions you need to use rsa3072.
>
> Last I checked, Thunderbird 78 did not support ed25519+cv25519
> keys. That's not a niche implementation.

Thunderbird 78's default OpenPGP implementation is rnp. According to
the interoperability test suite, rnp is able to use the "Alice" key
from the "OpenPGP Example Keys and Certificates" I-D.

https://tests.sequoia-pgp.org/#Encrypt-Decrypt_roundtrip_with_key__Alice_
https://tools.ietf.org/html/draft-bre-openpgp-samples-00#section-2

The "Alice" certificate uses:

Primary key algorithm: Ed25519
Subkey algorithm: Curve25519

Neal

_______________________________________________
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Best practices for obtaining a new GPG certificate [ In reply to ]
On Fri, 19 Mar 2021 03:33, Robert J. Hansen said:

> Last I checked, Thunderbird 78 did not support ed25519+cv25519
> keys. That's not a niche implementation.

I did extensive test with Ribose to make sure that RNP (the crypto
engine now used by TB) is compatible with GnuPG. Thus I wonder why TB
gets things wrong again.

There are also so many regressions in TB new OpenPGP support compared to
the long standing TB+Enigmail OpenPGP support that I wonder come it is
at all possible to send encrypted OpenPGP mails with TB.


Shalom-Salam,

Werner

--
Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz.
Re: Best practices for obtaining a new GPG certificate [ In reply to ]
It "does and it doesn't" I have some that were created in Kleopatra and
then imported into Thunderbird 78. As for creating them, no.... You
don't get to choose any options when generating ECC keys.

On 3/19/2021 12:33 AM, Robert J. Hansen via Gnupg-users wrote:
>> The next default is ECC (ed25519+cv25519) which is supported by most
>> OpenPGP implementations.  Only if you have a need to communicate with
>> some niche implementaions you need to use rsa3072.
>
> Last I checked, Thunderbird 78 did not support ed25519+cv25519 keys.
> That's not a niche implementation.
>
> _______________________________________________
> Gnupg-users mailing list
> Gnupg-users@gnupg.org
> http://lists.gnupg.org/mailman/listinfo/gnupg-users

--
PGP Key Upon Request


_______________________________________________
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Best practices for obtaining a new GPG certificate [ In reply to ]
It also has issues with signed messages and lists. For example you
signed this message but it says "uncertain digital signature".  I don't
remember this being an issue in the older TB/Enigmail.

On 3/19/2021 10:42 AM, Werner Koch via Gnupg-users wrote:
> On Fri, 19 Mar 2021 03:33, Robert J. Hansen said:
>
>> Last I checked, Thunderbird 78 did not support ed25519+cv25519
>> keys. That's not a niche implementation.
> I did extensive test with Ribose to make sure that RNP (the crypto
> engine now used by TB) is compatible with GnuPG. Thus I wonder why TB
> gets things wrong again.
>
> There are also so many regressions in TB new OpenPGP support compared to
> the long standing TB+Enigmail OpenPGP support that I wonder come it is
> at all possible to send encrypted OpenPGP mails with TB.
>
>
> Shalom-Salam,
>
> Werner
>
>
> _______________________________________________
> Gnupg-users mailing list
> Gnupg-users@gnupg.org
> http://lists.gnupg.org/mailman/listinfo/gnupg-users

--
PGP Key Upon Request
Re: Best practices for obtaining a new GPG certificate [ In reply to ]
On Fri 2021-03-19 08:29:12 +0100, Werner Koch via Gnupg-users wrote:
> You may also skip the menu thing and use
>
> gpg --quick-gen-key bar@example.com future-default

I agree with Werner's recommendation of using --quick-gen-key and
future-default.

If you're going to provide an e-mail address-only User ID, though, i'd
also recommend wrapping it in angle-brackets, as raw e-mail addresses
are still liable to trigger some minor bugs in various pieces of older
OpenPGP tooling. So that'd be:

gpg --quick-gen-key '<bar@example.com>' future-default

Using the defaults (or the future defaults, as here) is a good
practice. Most people shouldn't need anything fancier.

Regards,

--dkg