Policy-Discussion

[Iang <iang AT iang.org>]

Hi Lambert,

Lambert.Hofstra AT ins.com
 wrote:
> Interesting discussion.
> Thought about the requirements.
> I think it's critical that CAcert will never be held responsible for the 
> quality or usefulness of the software that's been signed bij a CAcert CSC.


CAcert should achieve that in a direct way with its CAcert 
Community Agreement and the related NRP-DaL.  However there 
is still a possibility for a court to say "you didn't try 
hard enough" by some indirect, non-contract theory or other.

Let's say that we agree with that principle, and CAcert is 
out of the picture.

Do we also say that the end-user also is never to be held 
responsible?  Or do we say that the end-user *is* to be held 
responsible?


> Based on that I suggest another possible requirement:
>     * require that the license agreement and disclaimer of all code signed 
> with a CAcert CSC includes a reference to the CAcert CPS and a statement that 
> CAcert only verified the identity of the signer, not looked into the quality 
> and/or usefulness of the software


A possible problem with that is that a signed-code delivery 
system may not help the end-user see the licence & 
disclaimer.  Given the "easy download" nature of some 
environments, it may be that this is considered good.

Another variation here would be to:

   * require the code-signing author to go to a reasonable 
extent to advise the end-user of things needed to be known.


> This is an interesting issue: what if someone creates a worm, signs it with a CAcert CSC,  and that worm infects half of the systems on the internet. Something that would never happened with unsigned code (say for arguments sake that the CAcert root cert has been included in the major browsers). One could argue that the CAcert CSC was a facilitator in the spreading of the worm, and therefore CAcert is partly responsible for the damage (????). 


Right, and then the above requirements (both) are useless 
because the action is malicious and the author doesn't care. 
 Or, the author isn't malicious, but not a good programmer 
... or is a good programmer, but hits a bug.


> So, maybe another requirement:
>     * require that either at installation time or the first time that software is run, 
> a pop-up windows explains that the software has been written by "xyz" (the 
> name of the person that received the CSC)
>
> Or:
>     * require that either at installation time or the first time that 
> software is run, a pop-up windows explains will show the content of the CSC 
> (verified name, one of the verified email addresses (I guess this is in the 
> CSC, chapter 3.1.1 of the CPS does not specifically state anything on CSC 
> fields)


Possibly.  The contrast between a non-signed-code popping up 
and saying this is "not signed" and signed-code popping up 
and saying it is signed by "trust me" ... is curious.

(Yes, there was a case of some company having a name similar 
to that.)

> So one question to add: do we have a sort of license agreement which 
> prohibits the use of a CAcert CSC for malicious code? This will open another 
> can of worms: what is malicious? Hacker tools? Password recovery tools? 
> (remember: people kill, not guns) This type of software can be quite valuable 
> in the hands of some, but can be misused by others.


Yes, can of worms.  "Malicious" would probably only be 
showable after the fact.  In which case why do you need the 
licence agreement?  Only to make the civil judgement an easy 
one I suppose (not being a lawyer, I'm simply speculating on 
why contracts say "don't do wrong").

> So maybe:
>     * require the CAcert Assured user to agree (in whatever form) that no 
> malicious code will be signed by a CAcert CSC


This agreement is possibly already there in the Principles, 
where it states something to the extent of "do no harm."

http://svn.cacert.org/CAcert/principles.html

=================
x. We do not act to the detriment of NRPs

You may be asked to help NRPs in security. It is your choice 
to do so, but if you do, you should not act to their 
detriment. You should encourage NRPs to join the community.

While we work for the benefit of our own users, we must 
balance our benefit against harm to others. Achieving a 
benefit to ourselves at the expense of others has no part in 
our principles.

Other users may join, and they become of us. We exist to 
help the security of our community, but we also exist to 
help the security of everyone.
=================

In the sense that if end-users are harmed, then this is 
against the Principles, and this is (soft) grounds for some 
action ... does this broad statement cover it?

Can it be tightened?  Or do we need a specific statement for 
every form of evil we come across?

iang