Hi Henning, On Mon, Nov 21, 2005 at 02:18:02AM +0100, Henning Makholm wrote: > Scripsit Martijn van Oosterhout <kleptog@gmail.com> > > > "push aside"? There's no rule that says there can be only one. Yes, > > replacing someone could become ugly, but providing additional hands > > can't be considered bad, can it? > > It can be considered bad from a technical viewpoint - as far as I > understand the master copy of the keyring is currently on a medium > that is under the keyring maintainer's direct physical control. > > The "obvious" way of switching to team maintenance of the keyring > would entail keeping the master copy in a central machine - for > example on a debian.org box somewhere in a colo. Doing that in a way > that does not leave the keyring more vulnerable to surreptitious > compromise than some reasonable persons might prefer, requires > software support that does not currently exist. > > If somebody designs and implements (after a suitable architectural > review) some software to support distributed keyring maintenance in a > secure, auditable way, it is likely that calls for adding more people > to the task would be considered more seriously. This is an interesting technical position but one that I think is incorrect. The keyring-maint@debian.org is to add, update and remove keys in the keyring. Generally both the add and remove functions should be done after being directed to -- either via a GR or from the Debian Account Maintainers (DAM)s, or in the case of removal once a developer has resigned -- not on their own accord. This leaves the update function, which has a number of components: - update the signature set of existing keys (simple) Poll the various public keyservers to for each key existing on the keyring. - migrate a developer from current to emeritus and vice versa (medium) I would assume that this also occurs upon the instructions of some other entity, either QA, the developer themself, via GR, etc. - replace an existing (compromised, lost) key with a new one (hard) This seem to be the problematic function. This is hard because the solution it isn't just technical (like the first), nor social (like the second) but a combination of them both. One solution might be: - require the developer to generate a new key - require the developer to have _at least_ N number of other, existing developers sign their key - once the developer submits their new key, the keyring-maint can select M of the N signatures from existing developers and ask them to further assure keyring-maint that the developer in question is who they say they are. - once that check passes, update the keyring. I would suggest that M be 2 and N be 3. > > Anyway, ISTM that removing keys from a keyring is much more important > > than adding new ones, right? > > It is also more difficult to implement in a secure distributed way. > Anybody can think up a scheme for using gpg signatures to prevent keys > from being added without authorisation in the first place. Making sure > that a removed key stays removed is a more complex question - > particularly if emergency powers-to-remove just get kludged onto the > existing system as an afterthought. As I have indicated above, I do not believe the role of keyring-maint is to make *any* decision but to act upon the instructions of other parts of Debian (QA, DAM, tech-ctte, DPL(s), DDs via GR). Ideally the role of keyring-maint can be useful performed by a script but since the set of entities who could instruct the keyring-maint is large it would probably make sense to have a number of humans fronting that script. Cheers, Anand -- `When any government, or any church for that matter, undertakes to say to its subjects, "This you may not read, this you must not see, this you are forbidden to know," the end result is tyranny and oppression no matter how holy the motives' -- Robert A Heinlein, "If this goes on --"
Attachment:
signature.asc
Description: Digital signature