Re: Archive database (projectb) queries for the public
Joerg Jaspert writes ("Re: Archive database (projectb) queries for the public"):
> Part I is all nice and stuff, just needs an implementation.
Great. How can I help ? This is on the critical path for anon dgit
usage, so I care about it.
> On 13397 March 1977, Ian Jackson wrote:
> > We should use a dedicated CA to sign the server's TLS key.
>
> Now this - why? What speaks against using any CA, be it the SPI one (or
> one of its subs, like the Debian CA?) as DSA use it elsewhere - or even
> one of the mafia sh*t around?
Firstly, please don't let this stand in the way of an unsecured
service.
But, on to your substantive question:
I don't know where the private key for the Debian CA is. That might
be tolerable, I guess. But in general in a closed system (as this is)
the X.509 CA paradigm is less good than direct distribution of the
public keys using an existing out-of-band mechanism. We have such an
out-of-band mechanism, the package update process.
Or to put it another way: to make this work the Debian CA public key
would have to be distributed in some binary package, identified as
"the" public key to use for the ftpmaster data service (and perhaps
other similar things). Given that, it's not clear to me what security
or convenience advantage we get from indirecting the authentication
through the Debian CA, rather than distributing the ftpmaster data
service public key directly.
All that using the Debian CA does is introduce an additional critical
key, with private key separately attackable (since it wouldn't be kept
alongside the ftpmaster data service private key). An undetected
compromise of the Debian CA private key would compromise the
reliability of data seen by data service users.
As another example of a scenario where my proposal is better: in my
proposal a compromised ftpmaster data service private key could be
resolved quite quickly by a security update to debian-keyring (or
whatever other package). If we were to use the Debian CA it's
difficult to see how this could be dealt with as quickly. (I'm
assuming no-one is suggesting we provide OCSP and require it to be
working.)
And using the Debian CA also means an additional group of people have
to be involved in key rollover/confirmation.
(Using the SPI CA for this is just plain wrong. There is no reason to
introduce an external entity, however well-meaning or competent, into
this process.)
Ian.
Reply to: