--- Begin Message ---
I think I'd like to take a step back from my concrete proposal, and
think about what the difficult problems are:
* Maintainer identity and initial certification.
This is as much a policy as a technical decision - there's a strong
effort/security tradeoff.
I think that at least one of our objectives should be to establish a
sociolegal comeback in the case of a malicious developer. This means
that we need to verify the real-world identify of the developer
somehow. There are several ways to do this, including personal
introduction by an existing developer, commercial key-signing,
attempting to use PGP web of trust, telephone verification of some
kind, &c.
Do we want to have any competence or integrity requirements for our
developers ? If so then references are probably the best idea, but
what kind and who from ?
* Maintainer key/site compromise/loss.
We need to have a mechanism for recovery if a maintainer's key is
compromised and/or their system trojanned so that bogus sources or
binaries are distributed. We need to be able to carry out this
revocation without having to have the maintainer act - they may be
incommunicando or malicious.
When the maintainer has recovered the integrity of their system and
generated a new key we need a way to verify that the new key belongs
to the original developer.
Do we want to try to detect maintainer key compromise, perhaps by
having a check message about uploads sent back to the maintainer by
email or distributed on a mailing list ?
* Upstream source integrity.
Maintainers cannot be expected to eyeball the entire upstream source.
They should encourage upstream authors to use checksums and digital
signatures.
Despite these measures it will be possible for an upstream source to
be used and distributed by us even though it has trojans. We need to
be able to revoke the bad packages, preferably without having to have
the relevant maintainer revoke their key.
* Master or certification key(s) safety/compromise/loss.
Any system which relies on a small number of master keys must be able
to cope with those keys are lost or compromised, and/or must keep them
somewhere hard to attack.
* Restrict activities that maintainers can take part in ?
We could make it difficult for maintainers to certify packages other
than their own, or packages with certain properties, but I don't think
this leads anywhere. Any package can, if installed, completely
subvert the system, and this is a fairly fundamental design decision
in the package management system. In any case, maintainers need to be
able to make point releases of other maintainers' packages.
* Testing - how can we best use the testing infrastructure, which
we've decided we need anyway, to assist us ?
How may testers will have to sign a package in order for it to be OK
for shipping ?
Even `untested' and `experimental' will have to have integrity checks,
to avoid our developers' machines being trojanned and their keys
stolen.
Can all maintainers be testers, without having to be registered
formally ? I'd say yes.
So, where does that leave us ? Let's tackle revocation first:
We have at least three kinds of revocation:
- Maintainer key certification revocation
- Individual package revocation
- Master key revocation
Traditionally there are two standard ways of dealing with revocation:
revocation lists and on-line recertification by a key validity agent.
We can't do just on-line recertification because the system needs to
be installable from CD-ROM. I want to be able to buy a commercial
CD-ROM and have my system verify that the binaries on it really did
come from the Project, without having the system have to be on-line or
having to download a file from the net.
Validity times on certificates don't help, because CD-ROMs need to be
installable well after pressing - preferably indefinitely on new
systems.
We _can_ have a system of epochs (oops, need a new word - umm, aeons,
ages?) which never go backwards, which will allow the software to
verify that `as of the last information available' a package is OK -
but every time you increment the aeon you have to recertify
everything.
Revocation lists will grow, of course. Aeons, at least, do not.
Who can revoke things ? A key should be able to revoke any of its own
signatures, but we need to be able to revoke lost keys too.
What about the shape of our certification scheme ?
Clearly a new installer is going to run the boot disks, so the boot
disks will have to be signed by some special key. The boot disks will
contain the bootstrapping key material, including whatever master keys
there are.
Existing installations upgrading from the previous uncertified
versions will presumably get the project's keys as part of dpkg.
Some small set of keys must sign the keys of maintainers; the policy
mechanisms about the verification of maintainers' identities should be
implemented in wetware and not (for example) by having the software
implicitly accept certificates from outside bodies.
Some maintainers will be able to keep a more secure key on another
system, or will want not to expose their `standard' PGP key to our
package building mechanisms etc. So, we must not require maintainers
to use their ordinary key for package signing.
Conclusions, perhaps:
* Three or four Project master keys held by separate people,
maintainers' working keys must be signed by some n-out-of-m of them.
* Revoke Project master keys by n-out-of-m of them; this way we can
gradually leave bad old keys behind.
* Revocation list kept on master site and also distributed with dpkg.
* Clean out revocation list and referesh keys every few years, by
gradually changing root key set and not recertifying old stuff.
* Maintainer/builder and distinct tester(s) must sign a package.
Builder's signature should state integrity information about source
version being built from, so that if source is revoked all binaries
are revoked too.
* Recertification of maintainers after key compromise using same
policy mechanisms as before. Possibly certifying keyholders could
keep on file maintainer's `extra secure' key to allow recertification
after compromise of a less-secure environment, but not all maintainers
can keep an `extra secure' key.
* Delay between package being issued and certified as tested ?
Perhaps this is excessive.
Comments ?
Ian.
--- End Message ---