Policy-Discussion

["Kyle Hamilton" <aerowolf AT gmail.com>]

The security versus availability tradeoff: encrypt the backups with
the public portion of that keypair.  If a backup needs to be restored
for any reason, the operator in Australia has one of two halves of the
key necessary to unlock the backup, which enforces an auditable event
because at least one of the other employees will know about the event
and have to contribute his share.

As well, I'd recommend the practice of using the root keys to sign
intermediate, shorter-term CAs.  This will reduce the amount of
plaintext which is encrypted with the CA key, making known-plaintext
attacks (not that I know of any against RSA, but y'never know) less
possible, and mitigating the risks thereof in any case (if an
intermediate CA is compromised, you can revoke that CA's certificate
(and thus all of the certificates it signed) without having to place a
new root certificate in every RP's software.

Anything that is done with the hardware configuration, the network
configuration, the software configuration, any usage of keys -- all of
this needs to be auditable, and thus logged.  The system administrator
should NOT have access to these logs, and these logs should also be
encrypted as new log records come in.  Once every so often, the
auditing officer (who has the private key necessary to decrypt the
logs) gets the file from the system administrator.  If the logfile is
corrupt, assume that the CA has been compromised.  (The modifications
to system, software, and network need to be written down, and the
paper logs copied and sent to the auditing officer.)

Also, even though the backup media is encrypted, you need to specify
what conditions it's kept in (a safe deposit box?  A fire safe at the
home of the system administrator?  A safe in an access-controlled
facility?), as well as how often the backups are tested and how long
they're retained.  As well as how the media is zeroed before allowing
new backups to be put on it.

In accounting and security both, "separation of trusted duties" is
fairly critical.  I understand the limitations that CAcert faces, and
those limitations need to be addressed in the resulting document
itself.  ("Security best practices dictate that these functions be
performed by separate individuals.  However, due to only one person
having access to the physical hardware at this time [due to distance
concerns], these actions are all performed by the same person:
<enumeration>.  At such time as more individuals are employed by the
CAcert Foundation, these duties will be split up according to industry
best practice, and an update to this document will be issued.")

(I wasn't talking about CA keys being generated on a 2/4 basis --
rather, access keys to auditable functions, such as generating sub-CA
keys in accordance with my recommendation above, or signing such.)

Just some thoughts. :)

-Kyle H

On 2/20/06, Philipp Gühring 
<pg AT futureware.at>
 wrote:
> Hi,
>
> > This makes me wonder if it would be possible to have a key generator
> > somewhere that would split it into a 2/4 share scheme before ever
> > letting it leave the box -- preferably one that would do all the
> > encryption necessary to send via S/MIME to each of the employees, as
> > well as talking to the SMTP server to do so.
>
> The certificate machine is nearly completely offline, has no network stack 
> on
> it, there is no SMTP there ...
> The keys on it only leave the machine on encrypted backup media.
>
> But perhaps 2/4 shared encrypted backups are an idea.
>
> The question is, whether it really helps in the end.
> (Security vs. Availability tradeoff)
>
> Best regards,
> Philipp Gühring
>
> _______________________________________________
> Have you subscribed to our RSS News Feed yet?
>
> CAcert-Policy mailing list
> CAcert-Policy AT lists.cacert.org
> http://lists.cacert.org/cgi-bin/mailman/listinfo/cacert-policy
>