On 28 Jun 2011, at 09:53, Jukka Zitting wrote:
> Hi,
>
> On Tue, Jun 28, 2011 at 10:29 AM, Bertrand Delacretaz
> <bdelacre...@apache.org> wrote:
>> Hence the need for people to download KEYS files from an *.apache.org
>> domain that we do control. Putting KEYS in a distribution might cause
>> people to use them instead of getting them from a trusted source, and
>> that's bad.
>
> The keys should be included in the web of trust, so it shouldn't
> matter from where a user gets the keys.
In an ideal world that would work for everyone ...
> Without the web of trust, the PGP signatures are just a rather
> elaborate version of the MD5 and SHA1 checksums we also provide.
Not quite. Keeping a KEYS file at apache.org puts an extra hurdle
in the way of an imposter forging a signature.
> Of course, without being included in the web of trust, the best a user
> can do is to get at least one of the keys from a trusted source.
Right. How trusted is apache.org, and can we build in more security?
(a) Checksums provide security against things like damage in transmission
but have no power against forgery. Anyone having tampered a package can
trivially create their own checksums.
(b) Checksums downloaded separately from a sufficiently trusted source
add security but beg the question of 'sufficiently trusted'.
(c) PGP helps by introducing an identity and the web of trust. If an intruder
were to introduce new, forged keys and signatures at apache.org, that's
going to get noticed by the real owners of the identities on the forged keys.
The more signatures on a key, the more people will be there to flag up
the intruder when they check a forged signature.
But perhaps we can improve further on that. What if we could introduce
an automated official ASF signing key whose role would be to authenticate
our own legitimate keys? Obviously this key won't itself attend keysignings,
but it can apply rules that will improve security over the mere presence of
an unverified signature from [someone]@apache.org.
I'm thinking now of tests like:
- don't sign any new key until it's been verified by multiple channels
(exchange of email, verify a token at id.apache.org, ???)
- only accept new keys whose WoT traces back to established keys
- require releases to be signed by an ASF-trusted key
- visual display highlighting ASF-verified keys in a release key's WoT.
- Regular checks of all keys @apache.org, and a page to highlight
unverified keys and buzz their purported owners.
Of course nothing is perfect, but we should be able to improve on
unverified! We should certainly be able to improve the surveillance
that leads to any bogus key getting rapidly noticed!
Anyone from infra reading this? Has this kind of discussion already
happened?
--
Nick Kew
Available for work, contract or permanent
http://www.webthing.com/~nick/cv.html
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org
