[Gpg4win-users-en] WKD for OpenPGP certificate "Intevation File Distribution Key <distribution-key at intevation.de>"

Thomas Arendsen Hein thomas at intevation.de
Wed Aug 7 15:25:43 CEST 2019


Hi Andre!

* Andre Heinecke <aheinecke at gnupg.org> [20190806 10:26]:
> On Monday 5 August 2019 15:18:01 CEST Thomas Arendsen Hein wrote:
> > But for the following scenario this fails:
> > 1. Gpg4win version x.y.1 is released in January 2020, signed by the 2016 
> key.
> > 2. Intevation creates a new distribution key in February 2020 and
> >    uploads it to the WKD, replacing the 2016 key.
> > 3. The next Gpg4win release x.y.2 will be released in April 2020.
> > -> There are 2-3 months where even the newest release can't be
> >    verified by a key retrieved from WKD.
> 
> Yes, in that case Intevation should only update the key together with a 
> release. It is a bit problematic but happily such a key rollover does not 
> happen much.

Maybe key rollover does not happen often, because it is so
problematic?

> > > The old key is still used by some "historic" apt repositories that 
> intevation 
> > > still publishes, so it should not be revoked.
> > 
> > And old Gpg4win releases (including sources!) are signed by the old
> > key, too, so revoking it would make verifying the integrity harder.
> > (now this will be for releases that are at least 3 years old, but
> > when the next rollover happens this will be for quite recent
> > releases)
> 
> This depends a bit on how you handle key rollover in the GUI. For example 
> Kleopatra does show it yellow if a key is expired. It says "Valid signature 
> but the key has expired" which I find O.K.

Expired != Revoked.

WKD only allows additional keys if they have been revoked.

> > And as indicated above, this does not only affect our distribution
> > key, but key rollover for other users as well where a new key should
> > be used for new correspondence, but the old key should continue to
> > be available to verify recent correspondence signed by the previous
> > key.
> 
> Again, depends a bit on the GUI. I know that KMail at least in old version 
> would show that bloody red for expired / revoked keys. But IMO at least expiry 
> is "not so bad" because of the above mentioned reasons. And at some point we 
> will have to expired the 1024 bit key to show "Don't trust it too much 
> anymore". That happens next year and is the right thing.

Sure, in this case it helps, because the old key is so old. But what
about an RSA2048 key being replaced by an RSA3072 key? Or an ECC key
being replaced by an RSA3072 key due to compatibility problems?

... or just an old RSA3072 key being replaces by a new RSA3072 key?

> Btw. I think that the rsa3072 key can have it expiry extended to at least 
> 2026. So that it will have been in use for 10 years like the old key. And this 
> should not happen at the last moment.

In hindsight the 10 years for the old keys are too long.
The distribution key should be of a level comparable to SSL/TLS
certificates, so 10 years for a non-CA key seems a bit too long,
while 5 years sounds like a good balance between cryptographic or
operational security and the insecurity introduced by keys that
change too often.

> I do not see much reason currently to 
> switch to ECC as for a rare file verification there are no real performance 
> reasons and the security of rsa3072 is still very good. 

With my current knowledge I agree. Ask me again in 2021 :)

Regards,

Thomas

-- 
Thomas Arendsen Hein <thomas at intevation.de>
OpenPGP key: https://intevation.de/~thomas/thomas_pgp.asc (0xD45DE28FF3A2250C)
Intevation GmbH, Neuer Graben 17, 49074 Osnabrueck - AG Osnabrueck, HR B 18998
Geschaeftsfuehrer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
URL: <http://lists.wald.intevation.org/pipermail/gpg4win-users-en/attachments/20190807/1041a3aa/attachment.sig>


More information about the Gpg4win-users-en mailing list