• PolicyDrafts
• CodesigningAssurancePolicy

• I ran out of time for this - please take over if you want.

CodesigningAssurancePolicy Work In Progress

0. Preamble

We need to do this GR, Teus.

Quotes of general process:

• Up to now there are additional checks and they should stay as they are. Werner

• I think not, not in this round. Stick to the basics: we know the guy (cute), we can arbitrate (interesting), we might revoke (tough?). iang

• Once the basic code-signing cert is in place, I see no reason why a gold-standard "good code" cert can't be added. Later, though.iang

• ref: "I don't see a real reason why code-signing certificates are treated differently to any other certificate" I agree in quite some sense with this (Teus)

1. Purpose.

The purpose of the code-signing assurance policy is to lay down the checks required to meet the following objectives:

1.0 Meet audit criteria and Mozilla interpretations

Audit Criteria:

DRC A.2.j assumes OA and asks "For a subscriber certificate to be used for authenticating files (e.g., code-signing certificates), the CP clearly describes how the relationship of the subscriber to the organization identified within the certificate is verified."

need two checks

Mozilla:

Mozilla bug report extract

"Which is to say, if you want the code-signing bits set on any root to Mozilla, be aware that they want to see the verification procedures in the CPS, and have that under audit" (iang).

Stick to the audit criteria - it's stronger (iang).

Other links: Mozilla bug report Mozilla Security Policy

1.1 Traceable

Where did this come from? Is this the old purpose? [iang]

This was proposed by me, and first of all expresses my personal view. See below for some facts about the discussion. BernhardFröhlich

reaffirmed in this thread 2009-05 (TODO - exact links)

1.2 Exclusion of Purposes

Since law is slow and CAcert doesn't want bad PR here.

1.3 Understanding code-signing responsibly

Codesigners, assumed to be software developers, should be developing software that makes a distinction between identity and authorization. The marketing of that software should also not confuse the issues.

1.4 Informing the User

1.5 Consequences of misuse

2. Tools.

2.1 Identity

Currently a 100 points is required because that was what it was previously.

Points of view on points:

• Identity is gained with a single point (Daniel).

• 100 points but not require assurer (Faramir

• or 50, or zero, 100 was specified for perceived auditory process goodness (Faramir)

• Not more that 100 points (Pete)

• the coder need at least two (35+ points or 36+ if you add that 1 point for...) assurances (Maurice)

• > I think requiring 100 assurance points is good enough for this purpose. (Faramir)

  • I think, by far it is not sufficient. We should demand a lot more. (Werner) (more points? more process?)

• 100 points is nonsence (teus)

• we've got their identity (cute) (iang)

• identity is useful to law enforcement Daniel

• CAcert only asserts that the identity of the signer has been checked by multiple CAcert members (Lambert)

• Any assurance currently requires some contact which online criminals hate and police love chasing. Daniel

• scrutiny of identity as deterrent Werner

• It's not concerned *merely* about the identity of the code-signer. Check the Assurance Policy, section 1, sub-section 1.1. It is concerned about the Assurance Statement, which goes beyond the identity. iang

• Malware writers will use fake identity Werner + Faramir

Summary of votes for number of assurance points required:

• 1 - daniel
• 36 - maurice
• 50? - Faramir (going off average)
• 50? - Pete
• 100 - Werner
• 36? - teus
• 36? - iang

Take median - 36 points equating to at least two assurances.

2.2 Exclusion of Purpose

Excluded purposes for code signing are (to define somewhere like CPS):

• signing malware, trojans, viruses etc...

To understand the consequences of breaching CPS

• Assurer Training (for the sole purpose of understanding arbitration - could be merged into code-signing training below)

Quotes:

• CAcert's responsibility should be, in my view, limited to authenticating the identity publisher, not the code itself. Same thing with SSL certs.. (Pete)

• but we can't do anything about poorly-written or malicious code. (Pete)

• I don't think that CAcert should be terribly concerned with the actual content/media secured or signed by certificates it issues, merely the identity of those using the certificates. (Pete)

• avoid distribution to malware vendors Werner

2.3 Understanding code-signing responsibly

Codesigner training:

• CATs like test that tests the user's knowledge of identity, authorization and trust as it applies to code signing.
• Tests the codesigner's knowledge of arbitration

Quotes:

• OK. So, Assurer [challenge] is a stop-gap measure. it pleases no-one, and it is an acknowledged fact that certain questions are pointless to code-signing.iang

• I like the idea of a test for code-signers and a separate agreement for code signers. Also a policy which basically states those two things (iang)

• I would not like it to be just getting points (Philipp D)

• he should have an idea how assurance works, besides other activities of CAcert. (Werner)

• no too much assurance stuff in a test (Faramir)

• "Codesigners should have the chance to be just codesigners" -In the long run, yes or maybe. (Werner)

• we want the code signers that use CAcert for it not to make claims of trust for their code signing use, but only a claim of authenticity (Philipp D)

• tests prevent ignorance/stupidity Also prevent newbie codesigner from accepting a request saying 'will you sign this bit of code for me?'. (Daniel)

• tests as legal shift of blame allows CAcert to claim in court: this member should have known better, he passed test ABC before we issued this code signing certificate, so you can't blame us! (Lambert)

• the Assurer Challenge locks someone into Arbitration more tightly because it tests them on their understanding of it, etc etc. (iang) Faramir

• educate people on trustworthyness and authentication of origin

• don't need to make things harder for code signers, after all, they are not the people that needs to know a signature doesn't turn software into reliable software

• The "Assurer" hack is just that, a hack. It buys some breathing space for you to write a proper document discussing the test, the training, the special agreement, the arbitration, the declaration, etc etc. (iang)

• passing a challenge knowledge what CAcert Community and Assurance is about (teus)

• On Assurer challenge to meet objective knows more about CAcert community (Werner) + thoroughly understood what certificates are and how they work (Werner)

• Don't test coders on how certificates work (Maurice)

• since the number of people concerned by a fraudulent code cerificate is much greater (Werner)

• OK. So, Assurer is a stop-gap measure. it pleases no-one, and it is an acknowledged fact that certain questions are pointless to code-signing.iang

Agreement about what a coder-signer can ethicly say/market when talking about codesigning.

2.4 Informing the User

Hopefully the end user will have some mechanism on working out what a signed code means.

2.4.1 user documentation

Signed statement from code-signer saying what it is they are signing.

Purpose:

• Mechanism of complaint (a NRP can make a complaint but its taken as a dispute from CAcert (complainant) against code-signer (respondent)
• For criminal/civil prosecutions

Quotes:

• Make a CCA obligation that code signed must include an honest statement of the high level functionality of the code, with reference to the CC, that is subject to arbitration. (Daniel)

TODO is there any other confirmation/not here?

2.4.1 certificate fields

What fields can the certificate use?

CPS 7.1

• certificatePolicies OidAllocation new one for code signing??

As per CPS name/email will be there. How much depends on assurance level. So this means no anonymous certificates?

Quotes:

• Certificate should contain name/email (Faramir)

• code promises (teus - teus (in 2008)

(Ruled out because Text field Deprecated) Text statements in certificate "This certificate does not guarantee the safety or reliability of this code." Doubts about if this is supportable/worth while (Netscape comment tag?? - Deprecated)

2.5 Arbitration

Its here because we don't want fraud. By getting a certificate code-signer's already are agreeing to CCA and hence arbitration. Arbitration is desired in the cases:

• of fraud using certificates
• malware signing of certificates.
• fraudulent statements (limit to a specific identified statements?)

Quotes:

• Arbitration providing a public record (for laywers and police) Daniel

• Signed statement that it isn't malware is good for the civil/legal prosecution Daniel

• Signed statement of what software does is good for the civil/legal prosecution Daniel

• arbitration needs to be more tightly locked in (iang)

• Revoking may have OCSP benefits Daniel

• But to some extend, we can be carefull whom we give such a certificate and examine that programmer carefully before we give him a certificate, and if there are a lot of complaints against that programmer, we can revoke that certificate(s). (Werner)

• we should ensure that the claimed identities of the signer (e.g. the publisher of the code) are not fraudulent (Pete)

• we have to consider what happens when CAcert goes into that[codesigning] marketplace (Iang)

• Actually, coupled with our arbitration, knowing that a given person issued the code is bigger than just knowing the name. iang

2.6 Other Controls

Quotes:

• manual verification and not issue code certificates automatically. Werner

Reasoning Werner:

A computer system is only that smart as its programmers wrote the
program. If they overlook some special case, the computer cannot handle
it properly. A computer cannot think of its own. And mostly a programmer
can only "lock the stable door after the horse has bolted".

On the other side a human is very flexible. He can spontaneously react
even on unexpected events. So it is more difficult to cheat a human than
a computer.

• enter into information sharing on revoked certificates due to fraud/malware with other CAs/AV vendors? (daniel

3. Changes to implement requirements

3.1 Proposed CPS changes

http://www.cacert.org/policy/CertificationPracticeStatement.php is now binding on the community.

3.3.1. (imp) + code-signing certificates will expire after 1 year. 4.5.2 + OCSP 5.2 Registration and Trust Procedures 7.1.2 certificate extensions (TODO MORE)

3.1.1 Proposed certificate characteristics

http://www.cacert.org/policy/CertificationPracticeStatement.php#p7.1.2

==== 3.1.1.1 Expiry ====

TODO

• yearly from the expiry times on code signing certs (p20080917.2) - see PolicyDecisions it may need to be reviewed.

==== 3.1.1.2 OID for code signing policy ====

==== 3.1.1.2 Different OID for code signer's assertions ** FUTURE ** ====

Fairly complicated but has lots of merit - maybe after first release.

So each new elective will have an OID in the certificate?

3.1.2 CAcert public documentation relating to code-signing

Some reference to NRP-CaL and CCA with respect to code signing.

3.2 Proposed Education

• Knowledge of arbitration
• Knowledge of difference between identity and authorization.

3.3 Proposed Test (of education)

3.4 Proposed Codesigning agreement

On submission of the CSR for code signing the following statement will be presented to the requester:

In submission of this CSR for code signing, you hereby agree that you are subject to the following restrictions:
 1. The certificate issued in response to this CSR (here after referred "the certificate") will not be used for signing code (hereafter referred as "code") known as malware, viruses, trojans, worms.
 2. The certificate will not be used to sign any code that perform any subversive operation that the user will not be aware of or reasonably aware of.
 3. The certificate will not be used to sign code that you have not taken reasonable steps to verify that it does not breach the previous two statements.
 4. If you become aware that the certificate has been used to sign code listed in 1) or 2) you will advise support@cacert.org and revoke the certificate.
 5. You will in all your communications to all others represent signed code as a sign of the proof of origin of the code and never as an indication of trust, correctness, completeness, quality.

Failing to adhere to these conditions will result in you being subject to arbitration as per CCA. The arbitrator may impose any of the below remediations in response to your breach of these restrictions:
 1. Financial penalty of up to 1000 Euro.
 2. Revocation of certificate.
 3. Prohibition of ever being able to obtain another code-signing certificate.
 4. Publicly named as violating the conditions.
 5. Have the matter referred to any law enforcement authority.
 6. Communicate your details and those provided by the assurers that assured you to a law enforcement authority, other certificate authorities, antivirus vendors or anyone else that the arbitrator sees fit.
 7. Any combination of the above penalties.
 8. Any other penalty allowable by law.

4. Outstanding Questions

5. Old stuff - yet to be sorted

Two Views

As a summary of the discussion, there seem to be two schools of thought on the kind of statement CAcert is making:

One view is that signing code is nothing else than signing other documents, so there is no objective change, no statement change and therefore the procedures should be the same. CAcert's statement is considered to be "There is a natural person (or organisation) with the stated name and mail address. You must decide yourself if you can trust the author, and if this information is enough for you to single out the author of the code."

• signing documents assumes that people can read the document, understand the meaning of the signature, and make their own choices about reliance. That is, they can be relying parties, and the risk is with them. There is substantial history backing up this view, and the law generally puts the liability on the relying party because of this. [iang]

• however signing code is not like that; the relying party cannot read the code, and generally may not be able to, or will not read the certificate's information. Also, code is delivered to many users at once, not one at a time. [iang]

• Therefore, it is difficult to make an analogy to documents, and code is generally a 10 year old invention. [iang]

• This might then leave one of these two choices: Code-signing Certs create protocol signatures only, being integrity checking, etc, and have no legal meaning. OR, the user has to be protected from the ravages of mad code-signers by means other than their own checking.

• Is this already answered by RDL's disclaimer on RELIANCE ?

The other faction considers code signing certificates subject to easier abuse and therefore would prefer stricter procedures than normal ones. CAcert's statement is the same as above but with an additional "If code signed by a CAcert certificate does significant damage to you we'll try to help you find the certificate's owner". Especially, this school wants increased traceability.

• In the past, scanned IDs were kept, perhaps following above logic. but these are now dropped as CAcert-wide policy.

• if the user intentionally wants to cheat, then a scanned ID may not help traceability very much.

• the Assurance Policy includes a range of additional measures for High Risk Applications that can be considered.

• There is a problem with "traceability" in that we need to decide traceability to what end?

• for civil issues, we want to bring the person to Arbitration. Therefore we should choose methods that make that more likely.

• for criminal purposes, we want to bring the person to court. However, this is economically impractical in all but the simplest, local jurisdiction cases. E.g., IMHO, cross-border cases will likely need 6 figure damages. [iang]

Notes: the current DRAFT CPS is not very specific on code signing certificates, so if we want to keep code signing certs, the answers to these questions will need to be documented. Either here in this Code Signing Policy, or in the CPS.

Objectives for policy control

Depending on the debate above, we need to discover the objective that we wish to pursue. Then, we can design some measures to achieve that objective. E.g., choose from the below.

Objective of increased chance of Prosecution

• Additional assurance to determine address for jurisdiction / summons / arrest?
• record photo-id (dropped by policy)
• record details similar to photo Id, such as record photo only
• enter into separate contract, permitting prosecutor to pursue civilly (lower barrier to success).

Other Stuff

> > PART THREE :
> > You can look at the details of the cert and only here you can see the
> > name of the CA
> >
> > => Only the name of the User is stated first.
> >
> > Give you a try there (you need to install Sun Java first):
> > http://wiki.cacert.org/wiki/JavaCodeSigningTest
> >
> > Don't forget one thing (as stated by Bernhard), in java case, once you
> > have accepted (the user action) a "trusted" certificate (CA validated),
> > the program can wipe your harddisk quite fast ! As mentioned in the wiki
> > http://wiki.cacert.org/wiki/CodesigningCert#head-f2bb3b4889f7b59f2621e85605406e43ab023eff
> >
> > "When done properly, code signing proves the authenticity and integrity
> > of code. However, code signing provides no guarantee of the codes
> > safety or reliability. So, the joke is that, at least, the end-user will
> > know your name just before he/she let you erase all their hard disk
> > content. ;-)"
lol... ok, so that's a fairly clear description of how
standard assurance is potentially not strong enough for
code-signing.
> > ****************
> >
> > To come back to the current issue, I would like to have as requirement :
> > - ID copy dropped (ok it is less work for support@ people! and safer as
> > the paper cannot be stolen)
> > - a minimum of 100 trust points and optionaly : Assurer status (assurer
> > test passed when available) => must be stated asis in the policy
To me it looks silly to say that it is optional.  If you
make them be a full Assurer, then we know that the testing
shows that these people are known to understand the risks,
liabilities and obligations, in excess of their simple
acceptance of the CAcert Community Agreement which they may
not have read.  That's valuable for code-signing and it is
an easy win.
There is no especial necessity with code-signing to make the
process easy, as far as I can see.  People who are doing
things that are potentially damaging will need to take
potentially time consuming steps.  CAcert exists to support
*all* its users, not just the lazy ones  :)
> > - a manual check on user records from support@ to allow codesigning
> > - a procedure of exception as a last resort.
> >
> > When support@ checks the profile of the user, it can appreciate if the
> > "Assurance records/history" of the CAcert user is credible : Dates,
> > Places and Assurers met before approving the codesigning ability (Does
> > the records make sense or is there something strange ?)
> >
> > So the more points we require for codesigning the more history we have
> > to give an appreciation on the level of trust/credibility of the user.
> >
> > I would add a procedure of exception if any doubts exist on the user
> > records :
> > - requesting the assurers of the user to provide a scanned copy of the
> > CAP forms  and if not credible enough,
> > - after privacy officer approval (or committee), the support could
> > request a copy of the ID (which will be destroyed asap after use). If
> > the user cannot provide the ID within a reasonable time (24-48 hours),
> > the support will refuse to grant the ability.

Old (removed) Tools

Old Removed Tools - Removed: (as per reason)

• a. must be a full Assurer (implicit by 100 + Assurer challenge but that may change and rest of comments address that).
• b. manual check on records by Support personnel (not maintainable)
• c. signed agreement not to abuse (becomes part of obligation in policy/training)
• d. exceptional procedures,... (make this a norm service rather than an exception. exceptions require arbitration afaik)

• Note a. retain copy of Id, was dropped by consensus in policy group plus m20080422.3

Industry Practice

Jac reports that industry practice is to check and claim the identity of the individual only, no trust or reliability is assumed. Cybertrust (is) Verisign.

Deeper Traceability

Nelson B reports:

Possibilities:

• this policy requires the Member to clearly identify herself in the software About or similar, including to the extent that the CAcert identity is clear (by use of Name, email or some nickname).
• perhaps a URL to file dispute, including the identity?

just random whiteboarding by iang.

---

• CategoryAudit

• CategoryPolicy

• CategoryAssurance