crypto signatures for arch/another proposal [was: Re: [Gnu-arch-users] (volunteers?) crypto signatures for arch]

[Karel Gardas]

On Sun, 7 Dec 2003, Karel Gardas wrote:

> Well, I will probably finally write my own proposal, just to not only
> criticize your own. :-)

Hello,

as promissed:

I would like to write some points about cryptographic signatures
support for arch/tla. So just shortly to heat discussion started by
Tom. :-)

The basic idea is that the support itself should be backward
compatible with the older arch/tla versions and so it will be possible
for arch user to get sources from the signed archive even with the
arch/tla version which do not support signatures yet.

This proposal deals only with signing of *.tar.gz files (changesets) in
the archives, although signing of other important files needs to be
considered, because of possible future archive attacks.

1) the only way to be backward compatible, is to use detached
   signatures. As a result we will have changeset file X.tar.gz and
   signature file X.tar.gz.sign

2) also I would like to use text based signatures since they are
   better to detect which system was used for signing, i.e. OpenPGP,
   X509. (just for case we will need to add X509 support to arch
   later)

3) signing and verification will be done directly on changeset after
   its creation or before application of downloaded changeset from the
   foreign archive. (I have not found the right place in tla yet, but
   in good old arch (larch), which I'm still using (shame on me :-)) these
   places are mkpatch and dopatch scripts)

4) there will be some crypto support metadata associated with every
   archive in $HOME/.arch-params/=locations which will manage actions
   like:
   a) sign or not sign changeset going into the archive, if sign, with
   what key/id? (mechanism specific string)
   b) if signature is broken on the changeset obtained from the
   foreign archive and/or missing, what to do?. i.e. nothing, warning
   (print message and continue), error (i.e. panic)

5) functions dealing with archives needs to be extended to also
   put/get/copy signature files beside the changeset files.

6) push-mirror will need to be modified to also copy signature files
   as it copies changeset files today


Some advantages/disadvantages:

- arch/tla itself will not store/hold/manage any security sensitive
  data like key passphrases etc. It will use some third
  party application to do the signing/verification job like
  gpg/openssl/etc. The advantage is that the arch/tla code will not
  need to be added into TCB (trusted computing base) code, a slight
  disadvantage might be that the user need to type his/her key
  passphrase more than once, i.e. N commits == N typing of passphrase
  (if the user doesn't use any kind of passphrase manager/agent).

- IMHO the advantage is that the support is proposed to be as simple
  as possible. I have also thought about the possibility to implement
  some kind and post-mkpatch/pre-dopatch hooks and extend the
  transport layer to put every X.tar.gz.* file in to the archive/get
  from archive instead of just X.tar.gz, where X is the changeset
  name. This way whole signature support will just be some scripting
  work ;-)


Cheers,

Karel
--
Karel Gardas                  address@hidden
ObjectSecurity Ltd.           http://www.objectsecurity.com