• OrganisationAssurance
• Manual

---

• česky | deutsch | english

---

• To CAcert.org Education & Training - To Organisation Assurer - To Organisation Assurance Overview

---

Organisation Assurance Manual

• v0.1 status is "First Draft"

Table of Contents

• Contents

  1. Organisation Assurance Manual
     1. Table of Contents
     2. Introduction: Why Assure Organisations
     3. What can an organisation do once it is assured by CAcert?
     4. Things a company should know when using CAcert certificates
  2. The Organisation Assurer's Job
     1. What are the challenges in assuring an organisation
     2. What needs to get verified during assurance?
     3. What are you liable for when assuring an organisation?
  3. Process
     1. Process of documentation (WIP)
     2. Procedures for specific countries
  4. Online Interface Main Features
  5. Questions to be dealt with
     1. Consequences of the changes in the life of the assured Organisation
  6. Inputs & Thoughts

Introduction: Why Assure Organisations

• Many organisations wish to to make use of a PKI infrastructure, either to secure their internal processes or to present their clients with secure web-pages.
• Currently the usual way for such organisations is to obtain their website certificates from commercial Certificate Authorities that charge a fortune while providing questionable security.
• Another option to secure internal networks of a company more cheaply is to create an organisation internal Certificate Authoritiy, but this imposes significant demands on Administrators, in technical as well as administrative and logistical areas.
• As CACert is becoming more known, many IT-Administrators have started to create certificates for sites they handle by using their personal CACert accounts. This, however, has some immense drawbacks:

What happens if the administrator leaves?

• When an administrator leaves the certificates he has created remain valid. Usually the problem is noticed when the certificates expires, which may happen up to two year later, when the ex-administrator is well out of reach for the company.
• Since the admin has added the company domain to his personal account, the domain has to be disputed if the old administrator is not reachable or not willing to surrender it voluntarily.
• So the new administrator has to take on the tedious process of issuing new certificates, using his personal account once again.

The organisation's name cannot be included in the certificate

• Because the administrator is using a personal account at CAcert, he is not able to add the organisation name into the certificate. While most people will not even notice the difference, those who have some experience with web server security will soon realize that an administrator has issued a personal certificate and can not provide any evidence that the site is indeed operated by the company.
• Whether such an arrangement is trustworthy is open to debate.

Organisations are People too

• In most jurisdictions organisations are persons of law, just like any human individual. They do not enjoy all the privileges of human beings, and do not have all the obligations, but usually an organisation can do just about anything a human being can do. Organisations are also what drives our societies. Even CACert has decided to become an organisation to take on the challenges faced by a group of dedicated individuals intending to be a free and open Certificate Authority.
• As such they should be able to be assured just like any other individual.

If certificates are to be used for securing eMail communication all employees of the organisation have to be assured by standard CAcert Assurances

• While this might be manageable for small organisations with a very low employee turnover, it becomes really annoying once there are more than a handful.

What can an organisation do once it is assured by CAcert?

• It can issue an arbitrary number of server, client and code signing certificates for domains registered by the company.
• It can include the company name, location (city and country) and department information in the certificates.
• People relying on a certificate can be sure that the certificate is authorised by the company, as identified by the company name and loaction.
• Multiple adminitrators can be assigned to an organisation account. So they can share the work and the administrator is no "single point of failure" when it comes to issuing organisation certificates.
• Administrators can be added and removed by the company by sending a message to CAcert. No dispute or other complicated process is involved.

Issue Server-Certificates for their domains including their organisation's name

• While individual users with an individual account may only include their personal name in a certificate, an organisation may also include the organisation's name, as well as its location and an optional department ("Organisational Unit") in the certificate.
• Someone checking a certificate can rely on the fact that CAcert has verified the fact that the certificate is authorised by the organisation since CAcert has checked that the organisation does exist as a juristic person and has authorised the administrator.
• So CAcert certificate can be used to ensure the identity of an organisation's web servers and intranet resource.

Issue Client-Certificates for their employees including their organisation's name

• While standard CAcert users have to be assured to at least 50 points in order to have their name in their client certificate and may never have an organisation name in it at all, an organisation may issue client-certificates for any of its domains that include the person's name and the name of the organisation, plus an optional department designation.
• This distinguishes organisation certificates from personally assured certificates. The employees will actually not have any trust-points assigned to them, they even do not have their own CAcert Account. Yet their certificates will still include their name, since the name is assured by the organisation's administrator.

E-Mail Signing

• The sender of an unsigned mail can very easily be forged by simply entering another name as sender in a mailer program. A perfect example of this is the plethora of spam I receive that has been supposedly sent to me by myself.
• While this is less of a problem for a private user, verifying the identity of a sender can be quite relevant in a corporate setting, where third parties may send e-mails in order to convince a recipient certain actions have been approved by their superior.
• An example from real life: In an organisation I had access to, a competitor (presumably) sent an email to an account manager in the name of his superior requesting the bid document for a major bid. The Reply-To header pointed to an anonymous hotmail account. The account manager hit the reply button in his outlook, thinking he was replying to his superior. Luckily, he did not put the document into the email as an attachment, but rather a link to an internal server accessible only from within the office. When next speaking to his superior he asked whether he had received the email. Only dumb luck prevented this to become a major catastrophe.
• Digital Signature, while not being absolutely fool-proof, can be a significant help in situations such as these, since they do make a statement about the senders identity, provided basic key handling routines are followed.

Use encrypted e-mails for confidential communication

• The ability to encrypt communications between people working on opposite sides of the earth; communications that go through the inherently insecure "pipes of the internet" is a huge improvement for man companies thriving to improve the security of their organisation.

Employ secure single sign-on

• Passwords, especially the kind written on a post-it note stuck to the side of a screen are one of the key failures to organisational IT-Security. Having employees use tokens with digital certificates, smart cards and the like, generally improves IT-Security by significantly reducing the human failure factor.
• Even using client certificates stored in a browser's software security module (the one not using smart cards as storage) can simplify login procedures and increase security since no password has to be sent on the network, not even an encrypted one.

Issue Code-Signing-Certificates including the organisation's name

• In order to distribute software many infrastructures require the code to be signed. In order to be able to do that they will need a code-signing-certificate. These code-signing certificates are quite expensive in todays world and preclude many smaller companies from getting them. They then sign their code with self signed certificates.
• While this works on a technical level, it destroys the whole concept of code-signing by making the certificate and therefore the code unverifiable.

Improve reliability of their software

• Being able to verify, that code actually comes from the source you think it should come from is a significant step in trusting the organisation to behave in a responsible way when developing their code as well.
• While code-signing does not ensure the quality of the code, it does confirm that the code originated from the owner of the certificate. It also reduces the probability of undetected virus infection during code distribution, since any modification of the code invalidates its signature.
• A company that uses verified certificates to sign their code is akin to a business man going to the bank in a suit and being prepared for the questions asked. While it does not say anything about the character of the man, it does say a bit about the fact that he takes the problem seriously.
• While the improvement in security is not gigantic, it is a significant improvement in the emotional trust one has in an organisation.

Improve internal system security

• One of the key benefits of code-signing in many organisations is in the security of their internal systems. It is possible to restrict installable software and updates to ones signed by a specific certificate. Doing so prevents software not approved by the organisation for use on its systems from bein installed.
• So code signing can provide a means to control internal system security to a much greater degree than without it.

Multiple Administators

• Since more than one administrator can be assigned to an organisation account it is possible to distribute the work to more shoulders. Now it's not a problem if a client calls that a certificate has just expired but the one administrator is sick or on holiday. His deputy can do the job as well if he's also registered as an organisation administrator.
• If an administrator leaves the organisation or changes to another area, just a simple message to the CAcert Organisation Assurers is needed to appoint a new one. The new administrator can handle and revoke all organisation certificates created by any other of the organisation's admins, and immediately issue new certificates for the organisation's domains.

Things a company should know when using CAcert certificates

• CAcert certificates should not be used for high value financial transactions. CAcert can offer no insurance for abuse of its certificates.
• CAcert cannot guarantee availability of its services. Since the servers are operated by volunteers it may happen that they are down for a longer time. This could become quite painful if, for example, certificate based logins require the CAcert OCSP server to work.

• CAcert's root certificates currently are not included in standard browsers (see InclusionStatus). This is usually not a problem with known business partners, which can be notified that the organisation is using a CAcert certificate. But the "typical unknown Internet User" might be irritated if the browser issues a warning when, for example, the organisation's secure web site is visited.

• The organisation has to agree the CAcert community agreement and is therefor bound into the CAcert Arbitration system. So, for example, if a certificate of the organisation is abused the organisation is liable to a maximum amount of 1000 EUR for damage done by such a certificate.

The Organisation Assurer's Job

What are the challenges in assuring an organisation

• Organisations don't have a photo ID
• This may at first seem like a minor point, yet it is actually one of the bigger challenges. Organisations, unlike human individuals, do not have a photo ID. There is nothing alike that you can just hold up to an organisation and verify that "The Organisation is who it says it is".
• To complicate things further, the documentation an organisation will have varies widely from jurisdiction to jurisdiction as well as from one type of organisation to another. While any average human being, having a photo ID themselves, is likely to know what a valid photo ID will look like, it takes some more detailed expertise to identify and correctly validate the diverging documentation an organisation may provide.
• As an example: In Austria a company will have a "Firmenbuchauszug" while an association will have an "Vereinsregisterauszug". In some of the United States a company will get a "Letter of good standing" while in others it will get nothing of the sort. Some charitables will have a letter certifying that they have one of 28 501(c) tax status, while non tax-exempt organisations will have another completely different set of documents all together.
• This is why it takes someone knowledgeable in the local organisational structures to verify an organisation.
• You cannot meet an organisation
• Contrary to common terminology, you cannot meet with an organisation. You can only meet with a representative of that organisation. While this might seem like a trivial difference at first, it becomes highly relevant when it comes to having an organisation "sign" a legal agreement.
• In any jurisdiction there are different rules for who may sign for and legally bind an organisation.
• While it is generally true that the CEO of a company may sign on behalf of the company, this is not always the case. As an example, Austrian law allows associations to define their own signing powers in their own bylaws. So an association may require any legally binding document to be signed by at least 2 people or it may permit any board member's spouse to perform a legally binding signature. It is up to the bylaws of the association. On the other hand there are quite strict rules of who may sign for a company. Generally every one that may sign for a company in Austria is listed in the "Firmenbuch". However this may not only be the CEO, it may also be a "Prokurist". And his or her signing powers will be specifically noted and defined in the "Firmenbuch" as well as the law itself. So determining that a representative you meet may actually legally bind the organisation is a non-trivial task at best.

What needs to get verified during assurance?

• The first and most important thing for an organisation assurer to know is what to verify. If he does not know what to verify a good assurance cannot be accomplished.
• The signer of the COAP Form
• The signer of the COAP form binds the organisation to the CACert user agreements. In order for this binding to be valid, the signer of the COAP form needs to be verified.
• The signer is authorized to sign for the Organisation
• The first step in assuring an organisation is to verify that the person requesting the assurance and signing the COAP form is actually entitled to sign for the organisation. This is usually accomplished by comparing the name of the person signing the COAP form with the provided documentation for the organisation. Depending on the jurisdiction you are in, this may take different forms.
• As an example: When you have an "Firmenbuchauszug" it will state who is entitled to sign for the company. One reason why CACert requires organisation assurers to be experienced with organisation law is because this statement is nat always clearly discernible. An organisation assurer has to know for what company types which positions may sign for the company by default and which additional people may have that right and where to find that information.
• The person actually signing is the person he says he is
• Once you have determined that the person signing has the right to speak for the organisation, you will need to verify that the person signing actually is the person he says he is.
• This is the equivalent of why a notary public will sign off that he checked ID and certifies that the person signing actually signed the papers when buying real estate in Austria and Germany. When important matters are at stake this is required by law. CACert requires something similar for organisation assurance.
• The policy is deliberately vague on what exactly provides adequate proof. This is because different jurisdictions have different possibilities. This is why sub-policies may permit or deny certain options for the jurisdictions they cover. This is also why organisation assurers have an immense amount of leeway in deciding.
• In Austria for example it may well be acceptable to rely on a notarized signature, since a notary public is legally liable for verifying the identity of the signing person. While this is not in the policy or the sub-policy, it is up to the assurer to accept this as sufficient proof or not.
• The Organisation being assured
• Now that we know who signed the COAP form, and that the person is entitled to sign for the organisation, we need to verify the organisation itself.
• The organisation legally exists
• The first thing to make sure of is that the organisation actually exists as a legal entity. As with many things, this depends entirely on the jurisdiction you are in.
• However you are required to make sure, that the organisation exists as a legal entity. Some ways you can do this is to look at some government issued document. In Austria, as an example, a company may provide you, or ask you to request from the authorities, a "Firmenbuchauszug" which is the government telling you that the entity in question is currently an existing legal entity.
• Be aware that if you do not acquire this document directly from the government yourself, it may have been altered. So it is also your job to make sure that the document is actually valid. There are some provisions in policy such as that the document may not be older than 4 weeks. Sub-policies may make additional provisions for what constitutes legal proof.
• The organisation is entitled to name specified
• The second thing about an organisation that you need to check is whether the organisation is actually entitled to the name it wishes to use with CACert. This is actually more tricky due to the fact, that many organisations carry a different name for common use than their company name in the register.
• So you need to be aware that policy states: "Alternative names for organisations can be added as long as they are proven independently. ... This means that the anglo law tradition of unregistered 'doing business as' is not accepted without further proof."
• This means that IBM cannot request to be called IBM but only "International Business Machines Corporation" unless it independently proves that it owns the Trademark "IBM" or that it has registered that it is doing business as "IBM"
• What exactly constitutes proof is up to the specific sub-policy you are working under as well as your own discretion. You need to be aware however, that you will be held responsible for "your own discretion" during arbitration or legal proceedings.
• The domains requested for inclusion
• An organisation goes through the trouble of getting assured in order to have domains added to their profile. It is highly important to verify that the domain is actually owned by the organisation.
• The organisation actually owns the domains
• The easiest way to do this is to look at the whois database. Often times however you will find that the organisation requesting assurance does not match the whois record.
• You need to be aware that different top level domains define domain ownership differently. Most often however you will find that it is defined in terms of the Admin-C record in the database.
• If the information does not match you will need to request either additional proof of ownership or that the domain is transferred to the organisation (i.E. the Admin-C is corrected) What exactly is acceptable as "different proof of ownership" is specified in the sub-policies or is left up to your discretion. Again you need to be aware that you will be held responsible for "your discretion".
• The Organisational Administrator(s)
• The organisation administrators are the ones that are actually going to do the work for the organisation on a day to day basis. They are the ones that will issue certificates and revoke them.
• CACert requires of organisation administrators to be assurers. This is required in order to make sure that the people issuing certificates are aware of the implications of their actions. Any assurer for CACert is required to pass an online test and have at least 100 Assurance Points issued to their account.
• If you find that the persons named by the organisation as administrators do not meet the requirements, you have several options open to you. First you can refuse to assure the organisation at this time. However it may be more practical to help the organisation and its future administrators to meet the requirements. You are allowed to assure the future administrators yourself as well as call upon other CACert assurers to do so. It is important however that the standard procedures are followed.
• While you may also train the future administrators and give advice to them and the organisation, you need to be aware that doing so for any personal gain creates a "conflict of interest" which s problematic according to policy (point 5.a) and will definitely need to be declared in the assurance.
• The better route to go may be to recommend another organisation assurer to complete any training needed.

What are you liable for when assuring an organisation?

• As with any other assurance you do, you are liable in arbitration and legal proceedings for any statements you make.
• Generally you state during an organisation assurance:
• The organisation existed as a legal entity on the day of the assurance
• The person signing the COAP form is entitled to sign for the organisation and are who they say they are
• The organisation administrators are current CACert assurers
• The domains included for the organisation actually belong to the organisation
• The organisation was entitled to use the name requested on the day of the assurance

Uncomfortable?

• If you are not uncomfortable with the entire process you do not understand what it means. It means that you will need extensive knowledge of law for your jurisdiction, that you are taking on a liability, that you are making a statement about an organisation.
• However the process of getting organisations assured is also a very rewarding one. It means that more entities world wide will use CACert for their security needs. It means that security is taken from the often incompetent hands of corrupt corporations and put into the hands of the internet community. It means doing your piece to enhance the experience of modern communications and computers.
• So if you feel that you are still willing to become an organisation assurer, and you think you can handle the difficulties entailed, CACert invites you to get the training and testing required and to do a good job.

Process

• (old notes copied from the wip CPS.)

• The general process is:

• An Organisation Assurer is allocated to do the assurance under a selected Subsidiary Policy ("SubPol"). As there are many distinct forms of Organisations, Organisational Assurance delegates to local arrangments by means of SubPols, which are approved through the normal policy process. These are generally (but not always) organised on country lines, and managed by teams of local Organisation Assurers.

• The organisation must authorise in writing an Organisation Administrator ("OrgAdmin") to act for the organisation within the Community. The OrgAdmin is generally a person who is employed by the organisation, and must be a natural person (that is, an Individual not a Corporate) and a full Assurer.

• The OrgAdmin presents the following to the Organisation Assurer, supported by documentation:

  1. proof of existence of the organisation,
  2. the correct form of the name,

  3. the authorisation to act as OrgAdmin, and

  4. the Organisation's agreement with CCA.

• The Organisation Assurer verifies the above and conducts other appropriate checks, as covered in the SubPol.

• The Organisation Assurer enables the OrgAdmin's account to add the Organisation. The OrgAdmin's account is the method of authentication for certificate requests.

• Each domain is verified manually by the Organisation Assurer.

• The OrgAdmin may now act for the Organisation to manage creation of certificates. OrgAdmin may directly vary the Common Name (CN) and OrganisationUnit (OU) into a certificate.

• The Organisation Administrator is responsible for the Organisation and for verifying the names of the users within.

Process of documentation (WIP)

The German OA try to do the documentation of an Organisation Assurance in the CAcert Ticket System OTRS to have the chance to keep track of all German Organisation Assurances.

For the required steps see Manual OTRS.

Procedures for specific countries

• You should know CAcert's policies for Organisation Assurance. The master policy is located at http://www.cacert.org/policy/OrganisationAssurancePolicy.php.

• Subpolicies for specific countries or regions can be looked up at http ://svn.cacert.org/CAcert/Policies/OrganisationAssurancePolicy/ in the Controlled Document List. The trade office is listed in each SubPol.

• (Following copied from main OA page! needs further review...)

• For Europe there is a (DRAFT) Subsidiary Policy which covers countries with an official trade office Registry. Those countries covered and incorporated are listed in Appendix 1.

• For some countries, status is WiP only, and OAs cannot be currently completed. The process of completion is to secure acknowledgment of 2 regional Assurers on policy group for that SuPol.

• An overview of trade office registries in Europe accepted, being accepted and in consideration, as well details on company search and registry extracts can also be found on EuropeanTradeOffices. No, use the proper SuPol for the lookup, as it is a formal Policy Group document, not a community page.

  Where there is no infrastructure (sub-policy, OA) a bootstrap procedure has been put in place whereby normal assurers can be used. Iang: does this mean, OAs from other countries can do it? Without a SupPol how is this possible?

For the up to date list see Organisation Assurers List Ditto, use the SupPols!

I think we can delete this table and refer to the newer working page?

• Country	Sub-Policy	Organisation Assurer(s) (ordered by priority)	Sample Forms (pdf)	Other
  Australia	DRAFT	Robert Cruikshank, Sam Johnston, Andrew Barnes	Company
  Austria	DRAFT	Philipp Dunkel, Philipp Gühring
  Belgium	N/A	Alexander Prinsier		BE Checklist
  France	Requested
  Germany	DRAFT	Mario Lipinski, Sebastian Küppers		DE, DE form
  Ireland	DRAFT	Andrew Barnes, Sam Johnston
  Netherlands	DRAFT	Maurice Kellenaers, Teus Hagen
  Norway	DRAFT
  Sweden	WiP
  Pakistan	In Progress			what does this mean?: Refer to Server 4 Sale
  Switzerland	Requested / WIP	Andereas Bürki, Ernestine Schwob
  United Kingdom	WIP
  USA	In Progress	Refer to Greg Stark, Lance Jauron

see newer list

Online Interface Main Features

• (old notes transferred from PolicyDrafts/OrganisationAssurance).

• Each organisation is assigned a special Organisation Master Account (OMA). With this account the following administrative tasks can be done:
  • adding a domain (with verified by email request)

    • We should note that all email communications should be authenticated by encryption with a CAcert or other acceptable certificate. SH

  • adding a organisation unit (OU)

  • adding normal CAcert accounts as Organisation Branch Accounts (OBA)

  • allocation of OU to OBAs
  • signing of server certificates
  • generating client certificates
  • signing of PGP keys
• The Organisation Branch Accounts (OBA) can do the following administrative tasks under use of the organisation data and domains as well as the assigned organisation units:
  • signing of server certificates
  • generating client certificates
  • signing of PGP keys

Questions to be dealt with

• (old noted transfered from PolicyDrafts/OrganisationAssurance).

Consequences of the changes in the life of the assured Organisation

• If changes occur in the agency authorisation (existence or legal form of the organisation?), the new agency-authorised (organisation?) is justified (entitled?) to request the allocation (transfer?) of the organisation to another OMA or the deletion of the organisation in the CAcert systems and then to revoke of all the certificates issued for the organisation.

• How about If the assured organisation ceases to exist CAcert may at its discretionn immediately add any certificates issued to the assured organisation to its Certificate Revocation List (CRL). Transfer of an assured organisational identity to some other individual or organisation will be made at CAcert's discretion only after the receipt of proof of legal title to the assured identity. Basically I'm trying to say that mergers and takeovers are acceptable, arbitrary changes aren't. But we also need to say who decides, a question I have not addressed as I was not a party to the discussion. SH

• Easy answer: In the event of any change to nature of the entity (e.g., name change or M&A), the Assurance should be redone or updated at the discretion of the Organisation Assurer. If the Assurance is not redone or updated, as it is always subject to dispute resolution, a ruling may strike it down. iang

---

Inputs & Thoughts

Inputs and thoughts for the prove of the signature of the COAP applicant

• 20091206-PhilippGuehring / DieterHennig by e-mail

• Activate Code-Signing for Organisations
  
  > Nachdem Code-Signing freigeschalten wurde, müsst ihr nun ein neues Zertifikat ausstellen, und beim ausstellen darauf aufpassen, dass ihr Code-Signing für das Zertifikat aktiviert. Ich glaube Code-Signing ist bei Javascript-fähigen Browsern derzeit unter "Erweiterte Optionen" versteckt.
  
  > Schöne Grüße,
  > Philipp Gühring
  
  Der Ablauf ist wie folgt.
  
  1.) Ich als Org-Admin muss mir ein persönliches Zertifikat ausstellen lassen *mit* der Code-Signing-Eigenschaft.
  
  2.) Danach kann ich bei Org-Client-Zertifikaten *auch* diese Eigenschaft schalten.
  
  Das habe ich getan und ich habe in beiden (neuen) Zertifikaten die notwendigen Informationen.
  
  Genauer:
  1.) Man muss tatsächlich das Recht zum Signieren als Einzelperson beantragen.
  
  2.) Dann muss man es wiederum als Einzelperson einmal benutzten für
  einen Antrag für (s)ein Client-Zertifikat.
  
  3.) Dann hat man als Org-Admin die Möglichkeit, dass im Dialog für die Org-Client-Zertifikate einzuschalten.
  
  
  
  Danke für die Unterstützung und mit freundlichen Grüssen
  Dieter Hennig

---

• YYYYMMDD-YourName

• Text / Your Statements, thoughts and e-mail snippets, Please

---

• CategoryOrganisationAssurance

• CategoryAssurance