| 1 |
> > 3) |
| 2 |
> 1. Generate said list L from the GPG fields in LDAP (w/ long-form keyids) |
| 3 |
> 2. Clear-sign L, produces L' |
| 4 |
> 3. Include L' in /metadata/ during rsync content build. |
| 5 |
> 3.1. Provide all L' files in a trusted Git repository for historical reference. |
| 6 |
> 4. Tree-sign per GLEP58, such that signed list is included. |
| 7 |
> |
| 8 |
> Pros: |
| 9 |
> - L' is plaintext and works well w/ rsync deltas. |
| 10 |
|
| 11 |
> Cons: Mainly that the key id is a pretty short hash afaik.(Any better-informed |
| 12 |
> people around?) |
| 13 |
> - Introduces new weak point if attacker can compromise the automated |
| 14 |
> clear-signing service of #2. |
| 15 |
> |
| 16 |
> > 4) Rely on an existing list of keys somewhere distributed in portage and |
| 17 |
> > possibly somewhere else (keyservers); a key userid is signed with a master |
| 18 |
> > key. Work with GnuPG's well-tested and well-thought-out trust relationships. |
| 19 |
> > Back to start, time to re-read the entire thread... :) |
| 20 |
> What does this actually add over #3 in terms of security? |
| 21 |
|
| 22 |
I don't know. I am basically worried that we are using a well-tested cryptosystem in a hackish way and cannot fully estimate the consequences. (Which is why I hoped someone more knowledgable could comment. I may know approximately how to use gpg, and may have some basic knowledge of the maths behind it, but I have no clue of the data structures and software internals.) |
| 23 |
|
| 24 |
I'd say, here the burden of proof is on you. |
| 25 |
(i.e. that the signed list of long keyids is as secure as a list of signed keys) |
| 26 |
|
| 27 |
-- |
| 28 |
Andreas K. Huettel |
| 29 |
Gentoo Linux developer - kde, sci, arm, tex |
| 30 |
dilfridge@g.o |
| 31 |
http://www.akhuettel.de/ |
Archives