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

Re: Requirements of the tool (dpkg) support for signed packages



Sorry about the delay in posting about this.  I've skimread much of
the discussion, but not in great depth.  There was a lot of it and the
quality was of course mixed.  See my other message for some detailed
key hierarchy ideas.

* Purpose

We need to be very very clear about what we're trying to achieve.  Any
attempt to design a cryptographic system without understanding this is
doomed.

Also, cryptographic protocol and trust hierarchy designs really are
something that needs to be thoroughly discussed amongst technical
experts, and reviewed.

* Format

A signature attached to a .deb should be a separate member in the `ar'
archive that is a .deb.  It should be the last thing in the .deb and
should cover everything except itself.  Probably the signature should
be in PGP/GPG format.

It _shouldn't_ just be a signature of the control.tar.gz or
data.tar.gz or some other strangely-computed subsection in case we add
other new members.

It would be nice if the signature for a signed Packages or md5sums or
whatever could be attached to the file to prevent mirror skew from
making the signature (and thus the file) unuseable.  However, that
would mean at least putting them in PGP ASCII armour format, which
would not be completely backwards-compatible.

* Algorithm

We should use RSA and SHA-1.  We're not going to deploy this before
September anyway so the RSA patent isn't a problem.  RSA is simpler
(less code in the checking stage) and also doesn't leak your key like
DSA does if you make a signature using a bad (or compromised) RNG.

3. Protocol structure representation

We don't want to encode too much policy and protocol in the code.  I
think we should use SPKI/SDSI.

Ian.


Reply to: