Crypto (Re: Archive database (projectb) queries for the public)
Joerg Jaspert writes ("Re: Archive database (projectb) queries for the public"):
> I'm not considering a key issued directly by SPI, at maximum a CA issued
> by them, which would have the benefit of the ca-certificates package as
> said above.
Let us set this out more formally.
We have two proposed designs. I will call them "Direct" and "CA".
Notation:
K Some public key.
K-1 The corresponding private key.
K' New version of the key
K_serv The TLS key used directly by the service on coccia.
K_serv-1 lives on coccia.
K_lca Local (adhoc) CA. Exists in the "Direct" design only.
K_lca-1 lives alongside K_serv-1 (or could be discarded
after use since it is only ever used once). This key is
only necessary because (AIUI) X.509 has the defect that
it is not permissible to put a self-signed certificate
directly in a TLS client's trusted "CA" list.
K_dca The Debian CA key.
K_spi The SPI CA key.
K_ca1..9 Other CA public keys in ca-certificates;
write K_caN for the general case.
Direct CA
Public key(s) trusted K_lca K_spi, K_caN
by clients (in .deb)
Package to contain debian-keyring ca-certificates
public key(s) (Maintainer, DSA, is (Maintainer is at
closely associated arm's length from
with service operator, everyone else.)
ftpmaster.)
Cert chain supplied to K_lca -> K_serv K_spi -> K_dca -> K_serv
TLS client by server
Compromise of coccia Security compromised Security compromised
Must revoke, roll over Must revoke, roll over
K_lca, K_serv K_serv
Revocation process for Generate K_serv' K_lca' Revocation is not
K_serv (and K_lca) Update .deb via security feasible; security
process. Switch to regained only after
K_serv', K_lca' right cert expires (weeks/
away; clients with months/years).
bad K_lca stop working
until update installed.
Rollover process for Generate K_serv' K_lca' Generate K_serv',
K_serv (and K_lca) Update .deb via distro Re-sign with Debian CA
updates. After updates Start using right away
thought installed,
switch server to K_serv'
Compromise of Debian CA Security preserved Security compromised.
Must revoke, roll over
K_dca. But revocation
is not feasible (see
above).
Rollover process for Service operator Debian CA must
Debian CA does not need to be liase with SPI CA
involved. and with service
operator. K_spi signs
K_dca'; K_dca' signs
serv, service
operator installs
new certs.
Compromise of SPI CA Security preserved Security compromised.
Must revoke, roll over
K_spi; security is
restored for clients
which have installed new
ca-certificates .deb.
Rollover process for Service operator SPI CA must liase
SPI CA does not need to be with Debian CA, with
involved. service operator and
with .deb maintainer.
K_spi' signs K_dca;
that cert is passed
to all Debian CA users.
.deb maintainer
publishes K_spi' via
updates process.
After updates thought
installed, service
operator switches server
to K_spi'->K_dca->K_serv.
SPI CA operator
cannot complete rollover
without cooperation from
software vendors who have
installed K_spi.
Compromise of a K_caN Security preserved Security compromised.
(some other CA in the Recovery is entangled
ca-certificates trust with breaking web
list) browsing functionality
of unknown number
of sites for unknown
number of users (by
removing K_caN
from ca-certs list)
>From the above we see that the direct approach is both operationally
simpler and more secure.
Or to put it another way, the standard X.509 web TLS certificate
system is very poor. I don't see "the benefit of ca-certificates";
rather I see a whole pile of unnecessary security weaknesses and
organisational complications.
Given that we don't want to invent a new protocol for secure
half-anonymous RPC (that would be nice but I don't want to bring that
yak into this project), the right approach is to use the existing
protocol syntax, and existing implementations, but with a simple and
sane security and key management model.
The key part of your argument appears to be this:
> All that creating a new CA does is introduce an additional "critical"
> CA to be attacked.
But of course this additional CA is not really a CA at all.
Syntactically it is a CA, but its private key is generated alongside
and the service private key, and either stored alongside it or
discarded. So the adhoc CA does not represent any additional
vulnerability.
Really what I'm proposing is putting the service's public key directly
in the debian-keyring package, with a wrinkle to satisfy some X.509
braindamage.
Ian.
(Has the SPI CA key ever been rolled over? I haven't looked...)
Reply to: