Re: Archive database (projectb) queries for the public

[Ian Jackson <ijackson@chiark.greenend.org.uk>]

Jonathan McDowell writes ("Re: Archive database (projectb) queries for the public"):
> I don't think debian-keyring is the correct package for this. I think of
> the existing packages debian-archive-keyring is probably more
> appropriate. [...]

Thanks for your comments.

You are entirely right and I stand corrected.

> (I personally think that ca-certificates is the best place if we're
> looking at an X.509 certificate - I accept the point about the
> maintainer being unrelated, but that's also true for debian-keyring and
> debian-archive-keyring.)

The proposed key is not really an X.509 certificate in the normal
sense.  It doesn't want all the machinery that the ca-certificates
package has to allow the user to choose to include (or not) particular
keys in the trusted set.

Rather, the trust model is like the one for debian-archive-keyring:
there is a specific set of keys which the client software should use.
So in syntax it's an X.509 certificate, true, but the package it goes
into can treat it as an opaque blob to be simply shipped.

But if you think it ought to go into ca-certificates then that's
tolerable, provided that it is entirely separate from the existing
X.509 root certificate list disaster.


Joerg: since you had concerns about the burden on the ftpmasters of
generating K_lca, K_serv and the delegation certificate, I wrote a
script for you to DTRT.  Attached.

You'll need to substitute the actual service DNS name for "localhost".
Each time you run it it generates the two keys and necessary certs.

After running it:

  kserv-<timet>-privkey.pem   } for installing in the webserver
  kserv-<timet>-cert.pem      }

  klca-<timet>-cert.pem       "root" certificate for use by clients;
                              should be shipped somewhere in /etc, in
                              a directory for klca's generated at
                              different times; this directory must
                              contain no certs from the rest of the
                              public X.509 infrastructure

  klca-<timet>-privkey.pem    will not be needed again but must be kept
                              at least as secure as
                              kserv-<timet>-privkey.pem; securely
                              deleting it is probably sensible.

I tested this locally with openssl s_client as a server and curl as
the client, specifically:

   openssl s_server -key kserv-1384891699-privkey.pem -cert kserv-1384891699-cert.pem
   curl -v --ssl-reqd --cacert klca-1384891699-cert.pem https://localhost:4433/

I also checked that if I gave curl the wrong cert it produced an error
message and didn't continue.

Ian.

#!/bin/bash
set -e

now=${DEBUG_NOW-`date +%s`}

klca=klca-$now
kserv=kserv-$now

genkey () {
	if test -f $1-privkey.pem; then return; fi
	certtool --generate-privkey --outfile $1-privkey.pem
}

genkey $klca
genkey $kserv

certtool --generate-self-signed --load-privkey $klca-privkey.pem \
	--outfile $klca-cert.pem --template /dev/stdin <<END
organization = "Debian"
unit = "ftpmaster"
country = GB
cn = "archive query service pseudo-CA"
serial = $now
expiration_days = 5000
ca
END

certtool --generate-certificate \
	--load-ca-privkey $klca-privkey.pem \
	--load-ca-certificate $klca-cert.pem \
	--load-privkey $kserv-privkey.pem \
	--outfile $kserv-cert.pem --template /dev/stdin <<END
organization = "Debian"
unit = "ftpmaster"
country = GB
cn = "archive query service"
serial = $now
expiration_days = 5000
tls_www_server
dns_name = "localhost"
END