Re: RFC: Proposal for signed packages

[Stephen Early <steve@myrddin.greenend.org.uk>]

Kai Henningsen writes:
 > This is probably true. I think the original design (was it by Ian?)  
 > included something like a machine reachable only by a serial cable, and  
 > not running a login on that port, but instead a specialized program that  
 > just did verification and signing, or something similar to this.

Here is the original design that Ian and I came up with last year. Ian
has said that he wants to make some changes, but he's still busy with
his thesis.

Steve Early


\section{Keys}

There are three master keys, held offline in geographically separate
locations.

There are a number (about three, but definitely no more than five) of
certification keys, held (perhaps online) by separate important
developers.

Each package maintainer has a key.

There is a 'validity' key, held online in dedicated secure
hardware. This could be a separate, non-networked machine connected to
a networked front-end machine (not necessarily dedicated) by a serial
cable. It need not be securely connected to the primary ftp site.

\section{Certification}

Each package is signed by the package maintainer.

The package maintainer's key is signed by the nearest certification key.

Each certification key must be signed by at least two of the master
keys; usually it will be signed by all three.

The validity key is signed by all three of the master keys. This
certificate includes the date of the last revocation of a validity
key.

When a package is received by the archive its details are forwarded to
the validity server's front-end. This posts an announcement on
debian-devel and submits the certification information to the validity
server.  This delays for 24 hours; if the maintainer has not
repudiated his signature after 24 hours then a certificate is applied
using the validity key and returned to the archive site. This
certificate binds the certification key, the package maintainer's key
and the checksum of the package as found in the package maintainer's
signature.

If a package needs to be inserted into the archive within 24 hours
(security bugfixes, for example) then verification of the package
checksum and status of the maintainer's key must be obtained through
external means. Each package maintainer must provide a telephone
number and hours at which they can be contacted. The validity server
maintainer must call the package maintainer (_not_ vice versa).

All of the certificates have timestamps, but apart from the timestamps
in the master keys' signature on the validity key these are not
used. Timestamps cannot generally be used as this would, for example,
make CD-ROMs go 'out of date'.

\section{Distribution of keys and certificates}

Each package contains its own signature from the package maintainer's
key, the certification on the package maintainer's key from the
certification key, the certification key itself, and the certificates
on the certification key from the master keys.  It also contains the
certificate from the validity key, and the validity key and its
certificate from the master keys. This will add around 4k to the size
of a package.

The master keys are contained in the dpkg package, which also contains
a list of revoked keys and packages (though since these revocations
cannot be guaranteed to arrive they are not required for the security
of the system).

\section{Revocation}

If a package is issued in error we either live with it or have the
maintainer revoke their key.

If a maintainer's key or a certification key is compromised or needs
to be changed, it is revoked with the validity server; a certifcation
key or the master keys, respectively, must sign the new key.

If a maintainer's key compromise goes undetected for 24 hours and a
bad package is issued the validity key revocation procedure is
followed.

If the validity key is compromised then an announcement is posted
widely, asking users to run `dpkg-auth --revoke-validity-key' and give
the date of the announcement.  This updates the system's idea of when
the most recent validity key revocation occurred, so that only
validity keys certified by the master keys after this date are
accepted.  (This data, held on the system in /var/lib/dpkg, is also
updated when a more recent last revocation timestamp is found in a
package---see above.)

If a single master key is compromised we widely announce a new version
of dpkg with the new master keys and revocations and ask users to
upgrade urgently.

If a single master key is lost we release a new version of dpkg with
the new master keys.

If several master keys are compromised we widely announce that this
has happened, and widely publish the MD5 checksum of the new version
of dpkg that users are required to install.

If several master keys are lost simultaneously we widely announce that
this has happened, and users must use dpkg with special options to
update to a dpkg version with new master keys.

\section{Caveat}

Note that this doesn't protect against package maintainers providing
bad packages (maliciously or through bad upstream source), but it does
ensure that every Debian user sees the same packages and that bad
packages can be traced.


--
Please respect the confidentiality of material on the debian-private list.
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
debian-private-REQUEST@lists.debian.org . Trouble? e-mail to Bruce@Pixar.com