Policy-Discussion

[<Lambert.Hofstra AT ins.com>]

> > Define "end user": is this
> > a) the owner of the CSC?
> > b) the person running the code?
> > c) someone else?
> 
> 
> Above, I meant the NRP, the poor sod who's computer just got trashed,
> or worse, bank account raided.
> 
> That is, there are these parties:
> 
> a. code author
> b. code distributor
> c. CAcert
> d. Assurer(s)
> e. Browser vendor
> f. end-user / NRP
> g. attacker
> 
> For now.  The question for the moment is to allocate the Risks,
> liabilities and obligations amongst that set.
> 
> Please sum the numbers to 100% :)
>
The question is not what we think, but what the outcome would be in a court 
case, so that is what you want to avoid by a combination of education and 
disclaimers...

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 ;)
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
OS Vendor: not responsible, but should provide a clear warning regarding the 
CSC in use instead of blindly running anything, and should check CRL
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 :-) )
Attacker: is responsible for all damage if deliberately using the flaws in 
the software

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.


Related question: will CAcert revole a CSC? On what condition?
It is possible to join CAcert, can you "unjoin"? Would all your certs be 
revoked?

Lambert Hofstra