Policy-Discussion

[Ian G <iang AT systemics.com>]

Lambert.Hofstra AT ins.com
 wrote:
> Ian wrote:
> > That all assumes that once the key is compromised, we know it has been 
> > compromised :)  An attacker is more likely to
> > try and keep the compromise secret, as it is then more valuable.  A known 
> > compromise triggers the compromise
> > response as you outlined, and that limits its usefulness.
>
> > So one defence is to make secret compromise convert into open compromise.
>
> I think the original question was not regarding an attacker, but some kind of 
> "voluntary" sharing of key data:


(I tend to view voluntary sharing as an attack ... I'm not 
sure that is a correct view, but it helps to focus away from 
hacker attacks and towards the easy but less familiar 
governance breach.)


> The original email stated:
> > Which lead me to the thought of trust in the repository for
> > the public key. Here in the USA, there is a long history of
> > behind the scenes "cooperation" by various large companies
> > with the forces of the law, like the wiretap in the A&TT
> > wire room, etc.
> >
> > What is to prevent this from happening at a CA and it not
> > being known for a lengthy period of time? Jurors have been
> > suborned for political reasons, why not CAs? 
>  
> So my answer is based on: what if a CA in general (not just CAcert) is somehow forced to hand over their private key or private keys of specific users to the authorities to help fight terrorism or money laundering or whatever ("behind the scenes "cooperation" by various large companies with the forces of the law")? Or one of the employees of a CA is sharing data with a friend in another company, in return receiving certain benefits?


Right, those were certainly the possibilities.  Taking in 
reverse order.

The normal way to slow/stop a person sharing information is 
to make that information subject to some form of access 
control.  The normal way this is done is to apply separation 
of roles or 4 eyes principle or similar, in that there are 
always 2 people in the loop on any action that is "special" 
in some sense.

So to get one person to do some act, the second pair of eyes 
would also have to be blinded/perverted as well. 
(Particularly sensitive things like root keys might involve 
more eyes and people.)  What this does is to raise the risks 
of the outsider, and increase chances of compromise of the 
attack, especially that it is made visible.

Adjuncts to this are procedure, logging, auditing.  A 
typical breach is a breach of procedure that is well bedded 
in, and is recorded in logs.  E.g., any access to another 
person's data can be treated as a breach, so the sysadm 
should have a ruling to authorise the access.

CAcert, if it implements the full model of the Arbitrator, 
would have this covered, procedurally.  In that model, a 
sysadm might be required to enter the case number for each 
admin request.  Later on, we can check each access (from the 
logs) to see that the appropriate accounts were accessed 
pursuant to the appropriate rulings.



When it comes to a TLA request, the above process should 
still protect for *covert* channels.

For *overt* channels, court orders are delivered.  These can 
be interpreted as disputes, ruled on by arbitrator and then 
implemented as per ruling.  So the prosecutor would have to 
get a court order to hand over the keys, in which case it 
could be dealt with in court, until finally complied with.

Then CA implements the procedures for compromise, etc, etc.



All of this might be good in theory, but implementation is 
slow.  Now that we've got a new board, we might see some 
progress on approval of those key policies...

iang