Policy-Discussion

[Bernhard Froehlich <ted AT convey.de>]

Lambert.Hofstra AT ins.com
 schrieb:
> [...]
> I miss a role: the code signer: I could get someone else's (malicious ?) 
> code, sign it with my CSC, and redistribute it
> The OS vendor: Browser vendor is part of the equation for java applets or active 
> components. OS Vendor is involved in "normal" programs or for instance driver 
> installations
>
> I would say:
> Code author: responsible for the quality of the code, should have a 
> disclaimer in his/her license agreement
> Code signer: tricky. Is not responsible for the code itself, but would be the 
> person whose name would show up. I would definitely discourage signing 
> someone else's code, unless you know that person very well, and know where to 
> find him/her :-)
> Code distributor (e.g. tucows): not responsible, should have a "limitation of 
> liability" statement (e.g. http://www.tucows.com/terms.html ;)
>   

I'd say the one who signed the code is to be considered distributor, 
with all obligations a typical distributor has. He's the first one 
responsible for the code, though he'll usually have some agreement with 
the author (if the two are different) to forward some or all 
liabilities. So applying one's signature would be a bit like producing 
the CD and packaging it in a shrinkwrap package in "classic" software 
distribution.

> CAcert: not responsible, should explain that CAcert only provided the CSC to 
> an assured person, based on the fact that the identity of the person was 
> checked by CAcert assurers, based on official government provided documents
> Assurer(s): not responsible, assurers only make a statement regarding a 
> person (the code author) and the official identity documents that that person 
> has shown. This was done before the code was signed (probably before the code 
> was written)
> Browser vendor: not responsible, but should provide a clear warning regarding 
> the CSC in use instead of blindly running anything, and should check CRL
>   
Of course a browser vendor can be responsible, for the CA certificates 
contained in its package. That's the reason why they usually insist on 
some audit.
If my computer is damaged by signed code, where the signature was issued 
by a CA not conforming to the browser vendor's inclusion policy, the 
browser vendor has some (not the whole and single, but some) liability, 
since they "did not do what they said".

I'd consider the situation with CAcert similar, if the certificate was 
issued not conforming to our policy I can imagine someone could also say 
"you did not do what you said". In this light maybe no policy is even 
better than a policy that's not adhered.

> OS Vendor: not responsible, but should provide a clear warning regarding the 
> CSC in use instead of blindly running anything, and should check CRL
>   
Let's consider the Browser a kind of OS, I don't see a relevant 
difference between OS and Browser vendors.

> End user/NRP: not responsible, unless he/she disregarded all clear warnings 
> (license agreement, disclaimers) and just runs any software available in the 
> wild
>   
> End user/ inside CAcert community: not responsible, but should understand the limitations of certificates (and as such should not have run code purely based on the fact that someone signed it :-) )
>   
So the end user/NRP IS responsible to adhere to our licence, and all the 
other licences attached to the code on the way. Community users have to 
adhere there own licence, which gives them greater liberties with the 
certificates (they may rely on them) but also greater obligations/risks 
as they have to decide wether the signer is trustable.
At least in principle. ;)

> Attacker: is responsible for all damage if deliberately using the flaws in 
> the software
>   

If we can catch the attacker the case is simple, as "attacker" implies 
he acted deliberately. Everyone damaged on the way will sue him to death 
(and maybe receive nothing because he has nothing anyway).
> The above is the "normal" situation. Anyone of the above could misuse his/her 
> position: the code distributor could deliberately place malicious code on the web site, 
> CAcert could provide untraceable CSC's (would that be a problem?), a group of assurers 
> could create a false identity and request a CSC on behalf of that nonexisting person, 
> the browser vendor could silently load code signed with a specific CSC, the OS vendor 
> could silently load code signed with a specific CSC or not check the CRL.
>   

Everyone not doing what s/he should do can be made liable if s/he acted 
deliberately or with gross negligance. If the act was only a simple 
negligance the trouble starts. ;)

> Related question: will CAcert revole a CSC? On what condition?
>   
This has to be laid down in the policy.
My proposal would be "on user request", "if the arbitrator rules so". 
Maybe it could also be revoked by support as an emergency measure "if 
there is strong evidence that the key is compromized", for example if 
obvious malware is signed with it. Note that certificates can also be 
temporarily revoked (for example till the arbitration is finished).

> It is possible to join CAcert, can you "unjoin"? Would all your certs be 
> revoked?
>   

There should be a policy about that... ;)
AKAIK you can quit by sending a mail to support. IMHO all certificates 
should be revoked at that time, but I'm not sure if it is currently done.
> Lambert Hofstra  
>   

I have added a paragraph to 
http://wiki.cacert.org/wiki/RisksLiabilitiesObligations about code 
signing certificates with some information I extracted from the 
discussion. Feel free to add or modify...

Ted
;)

--
PGP Public Key Information
Download complete Key from http://www.convey.de/ted/tedkey_convey.asc
Key fingerprint = 31B0 E029 BCF9 6605 DAC1  B2E1 0CC8 70F4 7AFB 8D26

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature