linux-kernel - Re: kernel.org status: establishing a PGP web of trust

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20111002182005.GB16368@khazad-dum.debian.net>
Date:	Sun, 2 Oct 2011 15:20:06 -0300
From:	Henrique de Moraes Holschuh <hmh@....eng.br>
To:	"H. Peter Anvin" <hpa@...or.com>
Cc:	"Rafael J. Wysocki" <rjw@...k.pl>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Greg KH <gregkh@...e.de>
Subject: Re: kernel.org status: establishing a PGP web of trust

On Sat, 01 Oct 2011, H. Peter Anvin wrote:
> On 10/01/2011 02:33 PM, Rafael J. Wysocki wrote:
> > 
> > OK, how long should the new key be valid?
> > 
> 
> That is a good question.  At the very least you want it to be valid for
> long enough that you will be able to get enough signatures on a new key
> *before* your old key expires.  As such I would recommend 3-5 years
> depending on how much you trust yourself to keep the key secure.
> 
> Some people have decided to opt for an unlimited key, but that
> *requires* that you have a way to revoke the old key, which is why we
> are considering a key revocation escrow service.

You can update the key expirity date at any time[1].  However, such
updates can still leave you with a lot of expired signatures, it all
depends on how the signers will set the expirity date of their
signatures when they sign your key...

This happened to my 0x1cdb0fe3 key.  It is still part of the strong set,
but it used to have much better connectivity.  It was necessary to
extend its service life, and about 3/4 of the signatures in it had
expire dates in sync with its original validity, and have now expired.

As for the key revocation escrow service, it should be kept offline and
very well protected.  If someone revokes all those keys at once, it can
cause a large service disruption at the very least.

It is also good to keep in mind that any sane security model extends the
loss of trust on a key to all signatures it has ever made and will ever
make, unless you have extra information (such as timestamp signatures
made by a still-trusted key).

On a somewhat related note, gpg supports subkeys.  When using subkeys,
you will only need the main key to sign other keys.  That means you can
have a large validity on a strong key (say: 10yr for RSA/4096) and keep
it always offline (in encrypted media, of course), and have subkeys on a
simple token or encrypted removable media for day-to-day use.

subkeys can be made to expire a lot more often (say, 1yr or 2yr
validity) without any major disadvantages, you just upload a new subkey
to the keyservers a few months before the current ones will expire.  You
can also revoke subkeys without any detrimental effects to the main key
and to your connectivity to the web of trust.

[1] that doesn't mean it will be easy to get people to accept such an
update after the key expired.  I don't think the keysevers will allow an
expired key to be "unexpired", for example.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/