Policy-Discussion

[<Lambert.Hofstra AT ins.com>]

Ted wrote:

> I'd be interested if you have any opinion on the other three proposed 
> requirements. IMHO the > best way to convince a user not to (knowingly) 
> sign malicious code would be to state that if > malicius code is signed by 
> the certificate the damaged party may find you!


> Further possible requirements should be voted upon:
>
>     * Do we want increased reliability for ID verification, that is, are
>       100 trust points needed?
>   
The objective is to link signed code to an individual, so the person's ID 
needs to be verified, so I would say the individual needs at least 100 trust 
points
100 points is enough for an assurer, the whole CAcert system relies on 
assurers, so it does not make sense to require more points for code signing.

So: I vote Yes, 100 points required
Yes: Ted
No:
>     * Do we want increased traceability, with official prosecution in
>       mind? That is, a replacement/modification/extension of the ID copy
>       required till lately.
>   
Traceability: I'd say yes, but would depend on what this entails.
Official prosecution: not by CAcert, the only thing CAcert could do is 
provide name, email address, and DOB of the person owning a certificate, and 
only after a court order.
I think we have to define what should be in the CSC: just a name or the 
official name as written on the official ID  (For Organisations the official 
name of the organization), and maybe the email address (is it in there right 
now? I noticed most CSC's do not include email address), probably name of the 
application (to prevent others to sign malicious code with a stolen CSC), 
anything else?
Windows shows Name of signer (Subject:CN?), Email address, Timestamp) as the 
digital signature details of a signed executable. 
I vote: Yes
Yes: Ted
No:
>     * Do we want an additional agreement of the applicant? Something
>       like she is no bad gal or that he knows that signing binaries
>       impose additional risks/obligations.
>   
Yes: Lambert, Ted
No:
>     * Do we want additional education of the applicant, something like
>       the Assurer Challenge for code signers?
>   
Hmm, I guess a simple test would do no harm (would show that CAcert is taking 
this serious, and that CSC's are only given to those that understand the 
impact)
So: Yes
Yes:
No:




Lambert Hofstra


-----Original Message-----
From: 
cacert-policy-bounces AT lists.cacert.org
 
[mailto:cacert-policy-bounces AT lists.cacert.org]
 On Behalf Of Bernhard Froehlich
Sent: 17 December 2007 09:05
To: Policy-Discussion
Subject: Re: [CAcert-Policy] Policy about code signing certificate

Lambert.Hofstra AT ins.com
 schrieb:
> 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.
>
> 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
>   

So I take this as a yes on "additional agreement of the applicant", although 
my personal opinion is that it is common knowledge that the SIGNER says 
something about the code not the ISSUER.

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

At least with Java applets the browser seems to open such a pop-up windows. 
And do you think anyone writing malicious code will care about that? BTW, 
following your line of arguments every internet provider would be liable for 
virus damage, since the damage would not have happened if there wouldn't have 
been an internet connection... It's something like "this screw was used to 
build a gun that killed someone, so I'll sue the maker of the screw"

Anyway, if we want something like that I'd also put it under "additional 
agreement of the applicant".

> 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.
>
> So maybe:
>     * require the CAcert Assured user to agree (in whatever form) that 
> no malicious code will be signed by a CAcert CSC
>   

Another variant of "additional agreement of the applicant". Exactly this form 
I was thinking of when writing the line. ;)

> Looking forward to your feedback :-)
>   

I'd be interested if you have any opinion on the other three proposed 
requirements. IMHO the best way to convince a user not to (knowingly) sign 
malicious code would be to state that if malicius code is signed by the 
certificate the damaged party may find you!
> Lambert
> [...]
> To make progress, some "guidelines" or "principles" on the CSC-policy 
> should be decided before working out the policy text in detail. From the 
> discussion about the IDs (and some more thinking) I'd guess the agreed 
> absolute minimum requirements would be the same as for an Assured user. 
> Further possible requirements should be voted upon:
>
>     * Do we want increased reliability for ID verification, that is, are
>       100 trust points needed?
>   
Yes: Ted
No:
>     * Do we want increased traceability, with official prosecution in
>       mind? That is, a replacement/modification/extension of the ID copy
>       required till lately.
>   
Yes: Ted
No:
>     * Do we want an additional agreement of the applicant? Something
>       like she is no bad gal or that he knows that signing binaries
>       impose additional risks/obligations.
>   
Yes: Lambert, Ted
No:
>     * Do we want additional education of the applicant, something like
>       the Assurer Challenge for code signers?
>   
Yes:
No:

[...]

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