CodesigningAssurancePolicy Work In Progress

0. Preamble

We need to do this GR, Teus.

Quotes of general process:

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

"a user who is issued a code-signing certificate can be traced with the intention of supporting official prosecution in the event of misuse of the certificate."

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

"a user who is issued a code-signing certificate must not use it for malware."

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

1.3 Understanding code-signing responsibly

"a user who is issued a code-signing certificate must understand differences between identity in authorization when using and promoting code-signing certificates."

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

"a user with a code from a code signing certificate should know what it means"

1.5 Consequences of misuse

"a user who is issued a code-signing certificate must comply with all policies

2. Tools.

2.1 Identity

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

Points of view on points:

Summary of votes for number of assurance points required:

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):

To understand the consequences of breaching CPS


2.3 Understanding code-signing responsibly

Codesigner training:


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.



TODO is there any other confirmation/not here?

2.4.1 certificate fields

What fields can the certificate use?

CPS 7.1

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


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


2.6 Other Controls


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.

3. Changes to implement requirements

3.1 Proposed CPS changes 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

==== Expiry ====


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

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

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

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.

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

Other Stuff

> > 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):
> >
> >
> > 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
> >
> >
> > "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
> > ****************
> >
> > 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)

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:

It is also an issue for the use of the certificates and signatures on which the user relies when deciding to accept/allow a download to be installed and/or executed on his computer system. Many think that signed installable packages give the user some ability to at least identify the party who harms him, if he is harmed by the thing he downloads, but typically it only gives the user momentary control, at the moment he makes a decision based on his browser's validation of that signature. There is typically no record kept. After the fact, it can be difficult to find the certificate upon which the user relied. The full solution to that problem is beyond the scope of a mere browser however. (The term "audit trail" comes to mind.)


just random whiteboarding by iang.

PolicyDrafts/CodesigningAssurancePolicy (last edited 2010-10-11 11:46:51 by SunTzuMelange)