• OrganisationAssurance
• Manual
• DE

---

• česky | deutsch | english

---

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

---

Organisations-Assurance-Handbuch

• v0.1 status is "First Draft"

Inhaltsverzeichnis

• Contents

  1. Organisations-Assurance-Handbuch
     1. Inhaltsverzeichnis
     2. Einführung: Warum Organisationen assuren
     3. Was kann ein Unternehmen tun, wenn es einmal durch CAcert assurt ist?
     4. Was ein Unternehmen wissen sollte, wenn es CAcert Zertifikate verwendet
  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

Einführung: Warum Organisationen assuren

• Viele Unternehmen, Firmen, Schulen, Vereine (im folgenden "Organisationen" genannt) möchten eine PKI-Infrastruktur nutzen, entweder um ihre internen Prozesse zu sichern oder um ihren Kunden sichere Webseiten zu präsentieren.
• Derzeit ist der übliche Weg für solche Organisationen, ihre Website-Zertifikate von kommerziellen Zertifizierungsstellen zu erhalten, die ein Vermögen verlangen und gleichzeitig fragwürdige Sicherheit bieten.
• Eine weitere Möglichkeit, interne Netzwerke eines Unternehmens kostengünstiger zu sichern, besteht darin, eine organisationsinterne Zertifizierungsstelle zu schaffen, was jedoch erhebliche Anforderungen an die Administratoren stellt, sowohl in technischen als auch in administrativen und logistischen Bereichen.
• Da CACert immer bekannter wird, haben viele IT-Administratoren damit begonnen, Zertifikate für Websites zu erstellen, die sie über ihre persönlichen CACert-Konten verwalten. Dies hat jedoch einige immense Nachteile:

Was passiert, wenn der Administrator geht?

• Wenn ein Administrator die Organisation verlässt, bleiben die von ihm erstellten Zertifikate weiterhin gültig. In der Regel wird das Problem bei Ablauf der Zertifikate bemerkt, was bis zu zwei Jahre später geschehen kann, wenn der ehemalige Administrator für das Unternehmen weit außerhalb der Reichweite liegt.
• Da der Administrator die Firmendomain zu seinem persönlichen Account hinzugefügt hat, muss die Domain beanstandet werden, wenn der alte Administrator nicht erreichbar ist oder nicht bereit ist, sie freiwillig zu übergeben.
• So muss der neue Administrator den mühsamen Prozess der Ausstellung neuer Zertifikate mit seinem persönlichen Konto wieder aufnehmen.

Der Name der Organisation kann nicht in das Zertifikat aufgenommen werden

• Wenn der Administrator sein persönliches Konto bei CAcert verwendet, kann er den Namen der Organisation nicht in das Zertifikat eintragen. Während die meisten Leute nicht einmal den Unterschied bemerken werden, werden diejenigen, die etwas Erfahrung mit digitaler Sicherheit haben, bald erkennen, dass ein Administrator ein persönliches Zertifikat ausgestellt hat und keinen Beweis dafür erbringen kann, dass die Website tatsächlich von dem Unternehmen betrieben wird oder der Mitarbeiter wirklich bei diesemm Unternehmen arbeitet.
• Ob eine solche Regelung vertrauenswürdig ist, kann diskutiert werden.

Organisationen sind auch Personen

• In den meisten Jurisdiktionen sind Organisationen Rechtspersonen, genau wie jedes menschliche Individuum. Sie genießen nicht alle Privilegien des Menschen und haben nicht alle Verpflichtungen, aber normalerweise kann eine Organisation so ziemlich alles tun, was ein Mensch tun kann. Organisationen sind auch das, was unsere Gesellschaften antreibt. Sogar CACert hat sich entschieden, eine Organisation zu werden, die sich den Herausforderungen einer Gruppe von engagierten Personen stellt, die eine freie und offene Zertifizierungsstelle sein wollen.
• Als solche sollten juristische Personen wie jedes andere Individuum sich assurenen lassen können.

Wenn Zertifikate zur Sicherung der E-Mail-Kommunikation verwendet werden sollen, müssen alle Mitarbeiter der Organisation durch die Standard-CAcert-Assurances assurt sein

• Während dies für kleine Unternehmen mit einer sehr geringen Mitarbeiterfluktuation überschaubar sein mag, wird es wirklich ärgerlich, wenn es mehr als eine Handvoll sind.

Was kann ein Unternehmen tun, wenn es einmal durch CAcert assurt ist?

• Es kann eine beliebige Anzahl von Server-, Client- und Code-Signing-Zertifikate für von der Firma registrierte Domains ausstellen.
• Es kann den Firmennamen, den Standort (Stadt und Land) und die Abteilungsinformationen in die Zertifikate aufnehmen.
• Personen, die sich auf ein Zertifikat verlassen, können sicher sein, dass das Zertifikat von der Firma autorisiert ist, wie durch den Firmennamen und die Ortsangabe angegeben.
• Mehrere Administratoren können einem Organisationskonto zugeordnet werden. So können sie die Arbeit teilen und der Administrator ist kein "Single Point of Failure" bei der Ausstellung von Organisationszertifikaten.
• Administratoren können vom Unternehmen hinzugefügt und entfernt werden, indem einfach eine Nachricht an CAcert gesendet wird. Es handelt sich nicht um ein Streitschlichtungsverfahren oder andere komplizierte Prozesse.

Server-Zertifikate für ihre Domains inklusive des Namens ihrer Organisation ausstellen

• Während einzelne Benutzer mit einem individuellen Konto nur ihren persönlichen Namen in ein Zertifikat aufnehmen können, kann eine Organisation auch den Namen der Organisation sowie ihren Standort und eine optionale Abteilung ("Organisationseinheit") in das Zertifikat aufnehmen.
• Jemand, der ein Zertifikat prüft, kann sich darauf verlassen, dass CAcert die Tatsache überprüft hat, dass das Zertifikat von der Organisation autorisiert ist, dass CAcert überprüft hat, dass die Organisation als juristische Person existiert und den Administrator autorisiert hat.
• So kann das CAcert-Zertifikat verwendet werden, um die Identität der Webserver und digitalen Ressourcen eines Unternehmens sicherzustellen.

Ausstellung von Client-Zertifikaten für Mitarbeiter einschließlich des Namens der Organisation

• Während Standard-CAcert-Anwendern sich mindestens 50 Vertrauenspunkte erwerben müssen, um ihren Namen in ihrem Client-Zertifikat zu haben und niemals einen Organisationsnamen in ihrem Zertifikat eingetragen haben können, kann ein Unternehmen für jede seiner Domänen Client-Zertifikate ausstellen, die den Namen des Mitarbeiters und den Namen des Unternehmens sowie eine optionale Abteilungsbezeichnung enthalten.
• Dies unterscheidet Unternehmenszertifikate von persönlichen Zertifikaten. Den Mitarbeitern werden eigentlich keine Trustpunkte zugewiesen, sie haben sogar keinen eigenes CAcert-Konto. Dennoch werden ihre Zertifikate weiterhin ihren Namen enthalten, da der Name vom Administrator der Organisation bestätigt wird.

E-Mail-Signatur

• Der Absender eines unsignierten Mail kann sehr einfach durch die Eingabe eines anderen Namens als Absender in einem Mailprogramm gefälscht werden. Ein perfektes Beispiel dafür ist die Fülle an Spam, die ich erhalte und die angeblich von mir selbst an mich geschickt wurde.
• Während dies für einen Privatanwender weniger problematisch ist, kann die Überprüfung der Identität eines Absenders in einem Unternehmen durchaus relevant sein, in dem Dritte E-Mails versenden können, um einen Empfänger davon zu überzeugen, dass bestimmte Handlungen von seinem Vorgesetzten genehmigt wurden.
• Ein Beispiel aus dem wirklichen Leben: In einer Organisation, zu der ich Zugang hatte, schickte (vermutlich) ein Wettbewerber ein E-Mail an einen Kundenbetreuer im Namen seines Vorgesetzten, der die Ausschreibungsunterlagen für ein Großangebot anforderte. Die Antwort-Adresse zeigte auf ein anonymes Hotmail-Konto. Der Kundenbetreuer drückte den Antwort-Button und dachte, er antworte seinem Vorgesetzten. Glücklicherweise hat er das Dokument nicht als Anhang in das E-Mail eingefügt, sondern als Link zu einem internen Server, der nur vom Büro aus zugänglich ist. Beim nächsten Gespräch mit seinem Vorgesetzten fragte er, ob er das E-Mail erhalten habe. Nur das dumme Glück verhinderte, dass dies zu einer großen Katastrophe wurde.
• Die digitale Signatur ist zwar nicht absolut narrensicher, kann aber in solchen Situationen eine wichtige Hilfe sein, da sie eine Aussage über die Identität des Absenders macht, vorausgesetzt, grundlegende Routinen zur Handhabung von Schlüsseln werden eingehalten.

Verschlüsselte E-Mails für vertrauliche Kommunikation verwenden

• Die Fähigkeit, die Kommunikation zwischen Menschen, die auf gegenüberliegenden Seiten der Erde arbeiten, zu verschlüsseln; Kommunikation, die durch die inhärent unsicheren "Rohre des Internets" geht, ist eine enorme Verbesserung für Menschen, die erfolgreich sind, um die Sicherheit ihrer Organisation zu verbessern.

Sicheres Single Sign-On

• Passwörter, insbesondere solche, die auf einer Post-It Notiz an der Seite eines Bildschirms angebracht sind, sind einer der wichtigsten Fehler in der organisatorischen IT-Sicherheit. Wenn Mitarbeiter Token mit digitalen Zertifikaten, Smartcards und dergleichen verwenden, verbessert dies in der Regel die IT-Sicherheit, indem es den Faktor Menschliches Versagen deutlich reduziert.

• Auch die Verwendung von Client-Zertifikaten, die im Sicherheitsmodul eines Browsers gespeichert sind (dasjenige, das keine Smartcards als Speicher verwendet), kann die Anmeldeverfahren vereinfachen und die Sicherheit erhöhen, da kein Passwort im Netzwerk gesendet werden muss, nicht einmal ein verschlüsseltes.

Ausstellung von Code-Signing-Zertifikaten mit dem Namen der Organisation

• Um Software zu vertreiben, benötigen viele Infrastrukturen die Signierung des Codes. Um dies zu erreichen, benötigen sie ein Code-Signing-Zertifikat. Diese Code-Signing-Zertifikate sind in der heutigen Welt recht teuer und verhindern, dass viele kleinere Unternehmen sie erhalten. Anschließend signieren sie ihren Code mit selbstsignierten Zertifikaten.
• Während dies auf technischer Ebene funktioniert, zerstört es das gesamte Konzept der Code-Signatur, indem es das Zertifikat und damit den Code nicht nachprüfbar macht.

Verbesserung der Zuverlässigkeit ihrer Software

• Die Möglichkeit zu überprüfen, ob der Code tatsächlich aus der Quelle stammt, von der Sie denken, dass er stammen sollte, ist ein wichtiger Schritt, um der Organisation zu vertrauen, dass sie sich auch bei der Entwicklung ihres Codes verantwortungsbewusst verhält.
• Während die Code-Signatur die Qualität des Codes nicht gewährleistet, bestätigt sie jedoch, dass der Code vom Inhaber des Zertifikats stammt. Es reduziert auch die Wahrscheinlichkeit einer unentdeckten Virusinfektion während der Codeverteilung, da jede Änderung des Codes seine Signatur ungültig macht.
• Ein Unternehmen, das verifizierte Zertifikate zur Unterzeichnung seines Codes verwendet, gleicht einem Geschäftsmann, der in einem Prozess zur Bank geht und auf die gestellten Fragen vorbereitet ist. Es sagt zwar nichts über den Charakter des Mannes aus, aber ein wenig darüber, dass er das Problem ernst nimmt.
• Während die Verbesserung der Sicherheit nicht gigantisch ist, ist es eine signifikante Verbesserung des emotionalen Vertrauens, das man in eine Organisation hat.

Verbesserung der internen Systemsicherheit

• Einer der Hauptvorteile der Code-Signatur in vielen Unternehmen liegt in der Sicherheit ihrer internen Systeme. Es ist möglich, installierbare Software und Updates auf solche zu beschränken, die von einem bestimmten Zertifikat signiert sind. Auf diese Weise wird verhindert, dass Software installiert wird, die nicht von der Organisation für die Verwendung auf ihren Systemen genehmigt wurde.
• Code Signing kann also ein Mittel sein, um die interne Systemsicherheit viel stärker zu kontrollieren als ohne sie.

Mehrere Administratoren

• Da einem Organisationskonto mehr als ein Administrator zugeordnet werden kann, ist es möglich, die Arbeit auf mehrere Schultern zu verteilen. Jetzt ist es kein Problem mehr, wenn ein Client anruft, dass ein Zertifikat gerade abgelaufen ist, aber der eine Administrator krank ist oder im Urlaub ist. Sein Stellvertreter kann die Aufgabe auch übernehmen, wenn er auch als Organisationsadministrator registriert ist.
• Wenn ein Administrator die Organisation verlässt oder in einen anderen Bereich wechselt, genügt eine einfache Nachricht an die CAcert-Organisations-Assurer, um einen neuen zu ernennen. Der neue Administrator kann alle Organisationszertifikate, die von einem anderen Administrator der Organisation erstellt wurden, bearbeiten und widerrufen und sofort neue Zertifikate für die Domänen der Organisation ausstellen.

Was ein Unternehmen wissen sollte, wenn es CAcert Zertifikate verwendet

• CAcert Zertifikate sollten nicht für hochwertige Finanztransaktionen verwendet werden. CAcert kann keine Versicherung für den Missbrauch seiner Zertifikate anbieten.
• CAcert kann die Verfügbarkeit seiner Dienste nicht garantieren. Da die Server von Freiwilligen betrieben werden, kann es vorkommen, dass sie für längere Zeit nicht erreichbar sind. Dies kann sehr schmerzhaft werden, wenn z.B. zertifikatsbasierte Anmeldungen die Funktionsfähigkeit des CAcert OCSP-Servers erfordern.

• Die Stammzertifikate von CAcert sind derzeit nicht in Standardbrowsern enthalten (siehe InclusionStatus). Dies ist bei bekannten Geschäftspartnern in der Regel kein Problem, die darüber informiert werden können, dass die Organisation ein CAcert Zertifikat verwendet. Der "typische unbekannte Internetnutzer" kann jedoch irritiert sein, wenn der Browser eine Warnung ausgibt, wenn beispielsweise die sichere Website des Unternehmens besucht wird.

• Die Organisation muss der CAcert Community-Vereinbarung (CCA) zustimmen und ist somit in das CAcert Arbitrationssystem eingebunden. Wird beispielsweise ein Zertifikat der Organisation missbraucht, haftet die Organisation bis zu einem Höchstbetrag von 1000 EUR für Schäden, die durch ein solches Zertifikat verursacht werden.

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