Policy-Discussion

[<Lambert.Hofstra AT ins.com>]

> -----Original Message-----
> From: 
> cacert-policy-bounces AT lists.cacert.org
>  [mailto:cacert-policy-
> bounces AT lists.cacert.org]
>  On Behalf Of Iang
> Sent: 17 December 2007 10:29
> To: Policy-Discussion
> Subject: Re: [CAcert-Policy] Policy about code signing certificate
> 
> Hi Lambert,
> 
Hi Ian,


> 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?

Define "end user": is this
a) the owner of the CSC?
b) the person running the code?
c) someone else?

> 
> 
> > 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.

Most software includes a license agreement, could be in there. For for
instance Java applets it could be the pop-up stating that the code is
signed, and allowing you to review the cert.


> 
> 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.
> 
Hmm, I like that

> 
> > 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.

Or the author did a fine job, created a good application that is used by
a number of people, however someone finds a way to misuse the
application...
> 
> 
> > 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.
> 
Well, there is a difference between "you will never know who wrote this
code" and "you might be able to trace the author of this code if it
harms you", although, in reality, it might not be a big difference for
writers of malicious code.

Maybe another requirement (or statement) regarding CSC revocation when
author used it to sign malicious code (who would decide this? Only when
a CAcert user requests it?)


> (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?

No, keep it generic, will cover more than a list of specific forms of
evil

> 
> iang

Lambert

> _______________________________________________
> Have you subscribed to our RSS News Feed yet?
> 
> CAcert-Policy mailing list
> CAcert-Policy AT lists.cacert.org
> https://lists.cacert.org/cgi-bin/mailman/listinfo/cacert-policy