[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: I am still on the keyring. With my old key.

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

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

		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
			- 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.


 `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

Reply to: