CA Policy and CPS

Copyright/License

This policy is structured according to RFC 3647 chapter 4.

TBD: "To be discussed" or "to be done": Sections in green require some discussion or someone to fill the blanks.

  • 1. INTRODUCTION
  • 2. PUBLICATION AND REPOSITORY RESPONSIBILITIES
  • 3. IDENTIFICATION AND AUTHENTICATION
  • 4. CERTIFICATE LIFE-CYCLE OPERATIONAL REQUIREMENTS (11)
  • 5. FACILITY, MANAGEMENT, AND OPERATIONAL CONTROLS (11)
  • 6. TECHNICAL SECURITY CONTROLS (11)
  • 7. CERTIFICATE, CRL, AND OCSP PROFILES
  • 8. COMPLIANCE AUDIT AND OTHER ASSESSMENTS
  • 9. OTHER BUSINESS AND LEGAL MATTERS
  • Appendix A. Definitions
  • Appendix B. Other Services
  • 1. INTRODUCTION

    This document based on the structure suggested by the RFC 3647.

    Version 0.2 2004/11/15

    1.1. Overview

    This document describes the set of rules and procedures used by CAcert, the community Certificate Authority (CA).

    1.2. Document name and identification

    1.3. PKI participants

    CAcert issues certificate to unassured users, who fulfill the requirements for proper identification as defined in this document.

    CAcert issues certificates for individuals, businesses, governments, charities, associations, churches, schools, non-governmental organizations or other legitimate groups.

    1.3.1. Certification authorities

    CAcert doesn't plan to issue certificates to subordinate Certification Authorities at this time.

    1.3.2. Registration authorities

    CAcert doesn't run RAs in a technical sense, but in a legal sense: Entitled "CAcert Assurer" or "Trusted third Parties" report the identification of users to CAcert. In addition, CAcert accepts foreign CAs as RAs, by acknowledging a foreign certificate with a certain amount of trust depending on the CAs policy. CAcert witholds the right to introduce further methods of identification, but ensures, that either a single identification is made reliable enough or multiple less reliable identifications have to be combined in a way defined by CAcert.

    1.3.3. Subscribers

    CAcert issues:

    1.3.4. Relying parties

    Everyone who uses CAcert products either directly or indirectly can be a relying party.

    1.3.5. Other participants

    N/A

    1.4. Certificate usage

    The CPS applies to all CAcert PKI Participants, including CAcert, Assureres, Customers, Resellers, Subscribres and Relying Parties.

    Each type of Certificate is generally appropirate for use with the corresponding applications defined in 1.4.1, unless prohibited in 1.4.2. Additionally, by contract or within a specific environment (e.g. company-internally), CAcert users are permitted to use Certificates for higher security applications. Any such usage, however, is limited to such entities and these entitites shall be responsible for any harm or liability caused by such usage.

    See 1.3.3 End entities

    1.4.1. Appropriate certificate uses

    1.4.2. Prohibited certificate uses

    CAcert certificates are not designed, intended, or authorized for use or resale as control equipment in hazardous circumstances or for uses requiring fail-safe performance such as the operation of nuclear facilities, aircraft navigation or communication systems, air traffic control systems, or weapons control systems, where failure could lead directly to death, personal injury, or severe environmental damage.

    Also, anonymous client certificates from CAcert unassured users shall not be used as proof of identity or as support of nonrepudiation of identity or authority.

    CAcert certificates should not be used directly for digital signature applications. CAcert is working on the issue, to support the digital signature application in the future. Alternativley, CAcert users can use external digital signature services, which use the CAcert certificate only for realtime-authentication.

    1.5. Policy administration

    See 1.2 Identification

    1.5.1. Organization administering the document

    See 1.2 Identification

    1.5.2. Contact person

    See 1.2 Identification

    1.5.3. Person determining CPS suitability for the policy

    See 1.2 Identification

    1.5.4. CPS approval procedures

    Changes are approved by a majority consensus of the board members.

    If a rule has been made stricter than before, the status of affected people is not automatically degraded and their certificates are not invalidated, unless there is evidence to to so.

    If a rule has been relaxed, the status of affected people is not automatically upgraded unless they apply for this change.

    1.5.5 CPS updates

    Paragraphs marked "(* imp)" are implementation details as of the time when this policy was written or updated. They are provided just for information and shall not be legally binding.

    Change of such an implementation section or correction of spelling, grammer or html errors are not considered policy changes, but rather policy updates. CAcert withholds the right to do them beyond the procedures defined in chapter 2.7.

    1.6. Definitions and acronyms

    Certificate

    A certificate is a piece of data used for cryptographic purposes, especially digital signature and encryption in association with appropriate software, which has to be provided by the user.

    CAcert

    CAcert is a community project as defined under section 1.2 Identification

    CAcert user

    Everyone who visits CAcert or makes use of CAcert's data, programs or services.

    CAcert unassured user

    A CAcert user, who registers at CAcert, but is not assured yet. The email address of theses users is checked by simple technical means. Currently only individuals, not legal entities can register.

    CAcert subscriber

    A registered user who requests and receives a certificate

    CAcert domain masters

    A CAcert user, who has some level of control over the Internet domain name he requests certificates for at CAcert.

    CAcert organisation administrator

    A CAcert assurer, who is entitled by an organisation to vouch for the identity of others users of the organisation.

    CAcert assured user

    A CAcert registered user, who's identity is assured by an assurer or other means as defined by CAcert.

    CAcert Assurer

    A CAcert assured user, who is entitled by CAcert to vouch for the identity of other users.

    CAcert relying party

    CAcert users, who base their decisions on the fact, that they have been shown a certificate issued by CAcert.

    CAcert cert redistributors

    CAcert users, who distribute CAcerts' root or intermediate certificates in any way, including but not limited to delivering these certificates with their products, e.g. browsers, mailers or servers.

    CAcert Contributions

    Contributions are any kind of intellectual property which find their way into the CAcert project with the consent of the copyright holder. Contributions can be code or content, whole modules, files or just a few lines in a larger file.

    Contributions can be submitted via any electronic or material path. Entries in CAcerts' systems, including, but not limited to the Content Management System or the Bug Tracking System are considered Contributions.

    CAcert Contributors

    Contributors are people or entities that make contributions to CAcert, either because they have been paid for this services, or donated them. Services include, but are not limited to any of their own graphical design work, any sections of their code, software, articles, files, or any other material given to CAcert, is considered a "contribution".

    CAcert Authorized Contributor

    An authorized Contributor is a CAcert Contributor, who is authorized by CAcert to access one, several or all internal, non-public and potentially confidential parts of the CAcert web site, CAcert mailing lists or any non-public documents about CAcert.

    2. PUBLICATION AND REPOSITORY RESPONSIBILITIES

    2.1. Repositories

    CAcert operates its own repositories for the root certificates, issued certificates and CRLs.

    2.2. Publication of certification information

    CAcert publishes it's root certificate and intermediate certificates if applicable, the latest CRL, a copy of this document, other relevant information.

    2.3. Time or frequency of publication

    Certificates and new information will be published as soon as available. CRLs will be published as soon as issued.

    2.4. Access controls on repositories

    There is read only web-access for everyone for the information mentioned under 2.1. Other information like registration information requires authentication.

    CAcert has implemented logical and physical security measures to prevent unauthorized persons from adding, deleting, or modifying repository entries.

    3. IDENTIFICATION AND AUTHENTICATION

    3.1. Naming

    CAcert assigns a Distinguished Name (DN, X.501) to each entity of a registered user.

    3.1.1. Types of names

    In case of Client certificates the DN contains:

    Other information about the user is collected, but does not go into the certificate.

    In case of server certificates the DN contains:

    For certificates of organisations, the following fields are used:

    3.1.2. Need for names to be meaningful

    no stipulation

    3.1.3. Anonymity or pseudonymity of subscribers

    For unassured people, we are only providing anonym certificates. Assured people can decide, whether they want identifying or pseudoym certificates. In case of pseudonym certificates, the serial number of the certificate is the pseudonym identity.

    3.1.4. Rules for interpreting various name forms

    no stipulation

    3.1.5. Uniqueness of names

    Some check for the uniqueness of users is done during registration (More precisely)

    We never issue the same DN twice, unless a certificate with a DN is expired or revoked.

    3.1.6. Recognition, authentication, and role of trademarks

    The organisation has to present their "Certificate of Incorporation" (or similar document proving the existance of the organisation) to authenticate itself.

    CAcert does not automatically verify the name appearing in the certificate, the domain name or any other fields against trademarks or intellectual property rights. CAcert can reject or suspend any certificate without liability in case of a dispute.

    3.2. Initial identity validation

    3.2.1. Method to prove possession of private key

    no stipulation

    3.2.2. Authentication of organization identity

    c.f. 1.3: There are three steps involved in assuring the identity of an organization:1) The organization must authorize in writing a named real person to obtain a certificate in the common name (CN) of an organization.2) The authorized, named real person must become verified.3) The authorized, named real person must present the following: a) The written authorization to obtain the certificate (item 1 above). b) Proof of legal existence of the organization, in most cases.Items 2 and 3 may be completed simultaneously.

    3.2.3. Authentication of individual identity

    Individuals are assigned a level of trust on a scale from 0 to 200 points. The actual level of trust is not published, only if specified levels are passed.

    When passing 50 points, a registered user becomes an assured user. When passing 100 points an assured user becomes an Assurer.

    The points assigned depend on the trust reported by the RAs. The details how to gain trust points are subjected to change. C.f. 5.2.

    3.2.4. Non-verified subscriber information

    N/A

    3.2.5. Validation of authority

    Domain-owners have to proof the authority over the domain with an Email-ping to one of several standard email addresses of the domain, or one of the email addresses found in the the whois record of the domain.

    3.2.6. Criteria for interoperation

    CAcert doesn't plan to issue certificates to subordinate Certification Authorities or other PKIs at this time.

    3.3. Identification and authentication for re-key requests

    3.3.1. Identification and authentication for routine re-key

    Authentication is done only once and does not expire normally. CAcert registered users will be issued certificates based on their current authentication status.

    (* imp) Server Certificates of assured people expire after 2 Years

    (* imp) Client Certificates of assured people expire after 1 Year

    (* imp) Client Certificates of non-assured people exire after 6 Month

    (* imp) Client Certificates of non-assured people exire after 6 Month

    (* imp) OpenPGP Signatures expire after 1 Year

    3.3.2. Identification and authentication for re-key after revocation

    New request

    3.4. Identification and authentication for revocation request

    Done by the user via web interface.

    4. CERTIFICATE LIFE-CYCLE OPERATIONAL REQUIREMENTS (11)

    4.1. Certificate Application

    4.1.1. Who can submit a certificate application

    Anyone who has webbrowser capabilities and internet-access is eligible to request CAcert's services.

    4.1.2. Enrollment process and responsibilities

    The user has to generate a key-pair, either with his browser (for client certificates), or manually (for server certificates). Then the certificate request is submitted on the CAcert.org website. The resulting certificate can be downloaded on the website, and is additionally sent by email.

    4.2. Certificate application processing

    4.2.1. Performing identification and authentication functions

    4.2.2. Approval or rejection of certificate applications

    4.2.3. Time to process certificate applications

    4.3. Certificate issuance

    Client certificates are issued to registered users (Persona CA) or to authenticated users.

    Server certificates are issued to domain masters.

    4.3.1. CA actions during certificate issuance

    4.3.2. Notification to subscriber by the CA of issuance of certificate

    4.4. Certificate acceptance

    no stipulation

    4.4.1. Conduct constituting certificate acceptance

    4.4.2. Publication of the certificate by the CA

    4.4.3. Notification of certificate issuance by the CA to other entities

    4.5. Key pair and certificate usage

    4.5.1. Subscriber private key and certificate usage

    4.5.2. Relying party public key and certificate usage

    4.6. Certificate renewal

    4.6.1. Circumstance for certificate renewal

    4.6.2. Who may request renewal

    4.6.3. Processing certificate renewal requests

    4.6.4. Notification of new certificate issuance to subscriber

    4.6.5. Conduct constituting acceptance of a renewal certificate

    4.6.6. Publication of the renewal certificate by the CA

    4.6.7. Notification of certificate issuance by the CA to other entities

    4.7. Certificate re-key

    4.7.1. Circumstance for certificate re-key

    4.7.2. Who may request certification of a new public key

    4.7.3. Processing certificate re-keying requests

    4.7.4. Notification of new certificate issuance to subscriber

    4.7.5. Conduct constituting acceptance of a re-keyed certificate

    4.7.6. Publication of the re-keyed certificate by the CA

    4.7.7. Notification of certificate issuance by the CA to other entities

    4.8. Certificate modification

    4.8.1. Circumstance for certificate modification

    4.8.2. Who may request certificate modification

    4.8.3. Processing certificate modification requests

    4.8.4. Notification of new certificate issuance to subscriber

    4.8.5. Conduct constituting acceptance of modified certificate

    4.8.6. Publication of the modified certificate by the CA

    4.8.7. Notification of certificate issuance by the CA to other entities

    4.9. Certificate revocation and suspension

    4.9.1. Circumstances for revocation

    Private key compromised or certificate owner identified as fraudulent.

    4.9.2. Who can request revocation

    The user for his own certificates. CAcert for fraudulent users.

    4.9.3. Procedure for revocation request

    Web Interface for users, notification of CAcert for fraud.

    4.9.4. Revocation request grace period

    not defined

    4.9.5. Time within which CA must process the revocation request

    4.9.6. Revocation checking requirement for relying parties

    A relying party must verify a certificate against the most recent CRL issued, in order to validate the use of the certificate.

    4.9.7. CRL issuance frequency (if applicable)

    not defined

    Alternative: CRLs are issued after every certificate revocation

    4.9.8. Maximum latency for CRLs (if applicable)

    4.9.9. On-line revocation/status checking availability

    (* imp) OCSP under construction

    4.9.10. On-line revocation checking requirements

    no stipulation

    4.9.11. Other forms of revocation advertisements available

    None

    4.9.12. Special requirements re key compromise

    no stipulation

    4.9.13. Circumstances for suspension

    Suspension of certificates is not available, only revocation.

    4.9.14. Who can request suspension

    N/A

    4.9.15. Procedure for suspension request

    N/A

    4.9.16. Limits on suspension period

    N/A

    4.10. Certificate status services

    4.10.1. Operational characteristics

    4.10.2. Service availability

    4.10.3. Optional features

    4.11. End of subscription

    4.12. Key escrow and recovery

    4.12.1. Key escrow and recovery policy and practices

    4.12.2. Session key encapsulation and recovery policy and practices

    5. FACILITY, MANAGEMENT, AND OPERATIONAL CONTROLS (11)

    5.1. Physical controls

    5.1.1. Site location and construction

    The servers are located in a dedicated server housing center.

    5.1.2. Physical access

    Physical access is restricted by door-locks and security-personnel

    5.1.3. Power and air conditioning

    P

    5.1.4. Water exposures

    P

    5.1.5. Fire prevention and protection

    P

    5.1.6. Media storage

    P

    5.1.7. Waste disposal

    P

    5.1.8. Off-site backup

    P

    5.2. Procedural controls

    Is this stated correctly? Aren't there any exceptions (remind the various methods for gaining points) Shouldn't some items be marked "imp"? Should we add "Exceptions from these procedures. can be done on a case by case base by a majority consensus of the board"?

    Registration and Trust Procedures

    PKI doesn't have any inbuilt methods similar to PGP's Web of Trust to provide peer to peer assurances, so to get round this CAcert Inc. was created to over come this short fall and be able to provide a trust model for peer to peer trust.

    This is accomplished by several means.

    Email and Client Certificate Procedures

    Email addresses are verified and certificates issued in the following manner:

    Server Certificate Procedures

    Before the system will issue server certificates to users, the user must prove similar to the email verification system that they have right to control that domain, and any host or subdomains of the domain.

    This is achieved by the following:

    5.2.1. Trusted roles

    For Trusted-Third-Party Assurance, Bank managers and Notaries are trusted to proove the identity of the subjects.

    5.2.2. Number of persons required per task

    For assurance, a mininum number of 2 Assurers are needed.

    5.2.3. Identification and authentication for each role

    5.2.4. Roles requiring separation of duties

    5.3. Personnel controls

    5.3.1. Qualifications, experience, and clearance requirements

    5.3.2. Background check procedures

    5.3.3. Training requirements

    5.3.4. Retraining frequency and requirements

    5.3.5. Job rotation frequency and sequence

    5.3.6. Sanctions for unauthorized actions

    5.3.7. Independent contractor requirements

    P

    5.3.8. Documentation supplied to personnel

    CAcert is supplying documentation about general security and social engineering to its personnel

    5.4. Audit logging procedures

    Duane: Can you write chapter 4.5 and 4.6?

    All discuss: We may be required to keep these records for a long time for security and bookkeeping reasons. We may however be required do delete these records asap for privacy reasons.

    5.4.1. Types of events recorded

    The system is using the common Linux syslog facilities:

    5.4.2. Frequency of processing log

    The events are stored, and only processed on manual demand

    5.4.3. Retention period for audit log

    The logfiles are being archived for at least 6 month.

    5.4.4. Protection of audit log

    The access to the audit logs is secured with file permissions, so that only the system administrators have access to the logs.

    5.4.5. Audit log backup procedures

    The logfiles are automatically backupd daily to a backup-server.

    5.4.6. Audit collection system (internal vs. external)

    N/A

    5.4.7. Notification to event-causing subject

    The administrator decides on a case-by-case basis, whether it makes sense to notify the event-causing subject.

    5.4.8. Vulnerability assessments

    5.5. Records archival

    5.5.1. Types of records archived

    5.5.2. Retention period for archive

    5.5.3. Protection of archive

    5.5.4. Archive backup procedures

    5.5.5. Requirements for time-stamping of records

    5.5.6. Archive collection system (internal or external)

    5.5.7. Procedures to obtain and verify archive information

    5.6. Key changeover

    5.7. Compromise and disaster recovery

    5.7.1. Incident and compromise handling procedures

    5.7.2. Computing resources, software, and/or data are corrupted

    5.7.3. Entity private key compromise procedures

    5.7.4. Business continuity capabilities after a disaster

    5.8. CA or RA termination

    c.f. 9.10

    6. TECHNICAL SECURITY CONTROLS (11)

    6.1. Key pair generation and installation

    6.1.1. Key pair generation

    The Key Pair is always generated by the user, either offline for server certificates, or online with the Browser.

    6.1.2. Private key delivery to subscriber

    CAcert never generates Private Keys for users, or delivers them to users.

    6.1.3. Public key delivery to certificate issuer

    For OpenPGP certificates, the public key together with the certificates is available in th

    6.1.4. CA public key delivery to relying parties

    The CA public key is always published on the website of CAcert.

    Additionally the CA public key can be included in Third-Party Software like Browsers, Email-Clients, ...

    6.1.5. Key sizes

    The minimum keysize for OpenPGP keys is 1024 Bit.

    The minimum keysize for X.509 keys is 1024 Bit.

    6.1.6. Public key parameters generation and quality checking

    P

    6.1.7. Key usage purposes (as per X.509 v3 key usage field)

    P

    6.2. Private Key Protection and Cryptographic Module Engineering Controls

    CAcert Root key protection

    6.2.1. Cryptographic module standards and controls

    6.2.2. Private key (n out of m) multi-person control

    6.2.3. Private key escrow

    6.2.4. Private key backup

    6.2.5. Private key archival

    6.2.6. Private key transfer into or from a cryptographic module

    6.2.7. Private key storage on cryptographic module

    6.2.8. Method of activating private key

    6.2.9. Method of deactivating private key

    6.2.10. Method of destroying private key

    6.2.11. Cryptographic Module Rating

    6.3. Other aspects of key pair management

    6.3.1. Public key archival

    6.3.2. Certificate operational periods and key pair usage periods

    6.4. Activation data

    6.4.1. Activation data generation and installation

    6.4.2. Activation data protection

    6.4.3. Other aspects of activation data

    6.5. Computer security controls

    6.5.1. Specific computer security technical requirements

    6.5.2. Computer security rating

    6.6. Life cycle technical controls

    6.6.1. System development controls

    6.6.2. Security management controls

    6.6.3. Life cycle security controls

    6.7. Network security controls

    6.8. Time-stamping

    7. CERTIFICATE, CRL, AND OCSP PROFILES

    7.1. Certificate profile

    7.1.1. Version number(s)

    (imp): X.509 v3

    7.1.2. Certificate extensions

    no stipulation

    7.1.3. Algorithm object identifiers

    no stipulation

    7.1.4. Name forms

    Is this the same as 3.1.1

    7.1.5. Name constraints

    Is this the same as 3.1.1

    7.1.6. Certificate policy object identifier

    The Policy OID will be a subkey of the key specified under 1.2

    7.1.7. Usage of Policy Constraints extension

    no stipulation

    7.1.8. Policy qualifiers syntax and semantics

    no stipulation

    7.1.9. Processing semantics for the critical Certificate Policies extension

    no stipulation

    7.2. CRL profile

    7.2.1. Version number(s)

    (imp): X.509 v2

    7.2.2. CRL and CRL entry extensions

    7.3. OCSP profile

    7.3.1. Version number(s)

    7.3.2. OCSP extensions

    8. COMPLIANCE AUDIT AND OTHER ASSESSMENTS

    CAcert declares to operate in compliance with this CPS.

    If you want to contribute an audit for free or at a nominal charge, contact CAcert.

    8.1. Frequency or circumstances of assessment

    P

    8.2. Identity/qualifications of assessor

    P

    8.3. Assessor's relationship to assessed entity

    P

    8.4. Topics covered by assessment

    P

    8.5. Actions taken as a result of deficiency

    P

    8.6. Communication of results

    CAcert will publish the results of an audit on the CAcert.org website when it is available.

    9. OTHER BUSINESS AND LEGAL MATTERS

    9.1. Fees

    Registration and certificate lifetime services (issue, revoke, check) are free, but CAcert witholds the right to charge nominal fees for additional services, e.g. the TTP programme. Due to the nominal nature of these fees, refund is usually not provided.

    Membership is appreaciated but not required to use CAcert services. Membership fees apply.

    9.1.1. Certificate issuance or renewal fees

    P

    9.1.2. Certificate access fees

    P

    9.1.3. Revocation or status information access fees

    P

    9.1.4. Fees for other services

    P

    9.1.5. Refund policy

    P

    9.2. Financial responsibility

    No financial responsibility is accepted.

    9.2.1. Insurance coverage

    9.2.2. Other assets

    9.2.3. Insurance or warranty coverage for end-entities

    9.3. Confidentiality of business information

    9.3.1. Scope of confidential information

    9.3.2. Information not within the scope of confidential information

    9.3.3. Responsibility to protect confidential information

    9.4. Privacy of personal information

    c.f privacy statement

    9.4.1. Privacy plan

    9.4.2. Information treated as private

    9.4.3. Information not deemed private

    9.4.4. Responsibility to protect private information

    9.4.5. Notice and consent to use private information

    9.4.6. Disclosure pursuant to judicial or administrative process

    9.4.7. Other information disclosure circumstances

    9.5. Intellectual property rights

    We are committed to the philosophy of free software, but non of the Open Source Initiative OSI - Licensing perfectly matches the mix of various forms of intellectual property this site consists of, including but not limited to code, content, data, images, design elements. Therefore the terms of GPL will apply to all code which contains such a comment and FDL will apply to all content, which contains such a comment. Elements without such a comment are CAcert proprietary and are not free for distribution. This affects especially the CAcert logo and other elements, which give CAcert its identity. In addition to the GPL/FDL rules, you have to ensure your set up is clearly distinguishable from the original CAcert site and cannot be mistaken for the original.

    9.6. Representations and warranties

    9.6.1. CA representations and warranties

    CAcert is freed from any liabilities to the greatest extend permitted by applicable laws. This includes, but is not limited to restricting the liability to gross negligence and intent.

    9.6.2. RA representations and warranties

    RAs are freed from any liabilities to the greatest extend permitted by applicable laws. This includes, but is not limited to restricting the liability to gross negligence and intent.

    9.6.3. Subscriber representations and warranties

    9.6.4. Relying party representations and warranties

    9.6.5. Representations and warranties of other participants

    Paid

    The contributor is at least liable for gross negligence ane intent. Additional liabilities may be set out in an individual contracts.

    unpaid

    The contributor will only be liable for gross negligence and intent.

    9.7. Disclaimers of warranties

    9.8. Limitations of liability

    9.9. Indemnities

    9.10. Term and termination

    9.10.1. Term

    If CAcert should terminate its operation, the root cert and all user information will be deleted.

    If CAcert should be taken over by another organization, the board will decide if it's in the interest of the registered users to be converted to the new organization. Registered users will be notified about this change. A new root certificate will be issued.

    9.10.2. Termination

    9.10.3. Effect of termination and survival

    9.11. Individual notices and communications with participants

    If CAcert should terminate its operation, the root cert and all user information will be deleted.

    If CAcert should be taken over by another organization, the board will decide if it's in the interest of the registered users to be converted to the new organization. Registered users will be notified about this change. A new root certificate will be issued.

    9.12. Amendments

    9.12.1. Procedure for amendment

    A change of this document requires:

    Users will not be warned in advance of changes to this document. Relevant changes will be published in the community as possible.

    Alternatively: All CAcert registered users will be notified 1 month before the change becomes effective.

    Notification of CAcert cert redistributors depends on the contract we may have with them.

    9.12.2. Notification mechanism and period

    This document might be mirrored to other sites or translated into different languages. In case of differences the version on our main site CAcert Inc. is valid.

    9.12.3. Circumstances under which OID must be changed

    9.13. Dispute resolution provisions

    9.14. Governing law

    This policy is applicable under the law of New South Wales, Australia.

    If any term of this policy should be invalid under applicable laws, this term should be replaced by the closest match according to applicable laws and the validity of the other terms should not be affected.

    Legal disputes arising from the operation of the CAcert will be treated according to the laws of NSW Australia.

    Legal disputes arising from the operation of a CAcert Assurer will be treated according to the laws of the Assurers country.

    CAcert will provide information about its users if legally forced to do so.

    9.15. Compliance with applicable law

    9.16. Miscellaneous provisions

    9.16.1. Entire agreement

    9.16.2. Assignment

    9.16.3. Severability

    9.16.4. Enforcement (attorneys' fees and waiver of rights)

    9.16.5. Force Majeure

    TODOTODOTODOTODOTODOTODO

    2. General Provisions

    2.1 Obligations

    CAcert Users

    Users have to agree to the applicable terms specified in the appropriate section of this web site. Users who use material from CAcert for cryptographic purposes assure that cryptography is not illegal according to laws applicable to these users.

    You warrant that the Service shall not be used: (a) fraudulently or in connection with any criminal offence; or (b) to send, receive, upload, download, use or re-use any material which is offensive, abusive, indecent, defamatory, obscene, menacing, or in breach of copyright, confidence, privacy or any other rights; or (c) to cause annoyance, inconvenience or needless anxiety; or (d) to send unsolicited advertising or promotional material or any other unsolicited Information; or (e) other than in accordance with the use policies and rules of your ISP and any local, state, province, territory or federal laws that may be applicable to you. You agree to be liable for all unauthorised use of the Service. In the event of such unauthorised use, CAcert Inc. can suspend or terminate partially or totally this Agreement, at its sole option. You agree to inform CAcert Inc. immediately if you have any reason to believe that there is likely to be a use of the service in any unauthorised way.

    Users will not seek unauthorised access to elements of CAcert's data, site, database and/or information stored by it, beyond the access they have been granted by the CAcert regulations. Information must not be willfully manipulated in any way without the express consent of CAcert or unlawfully altered.

    CAcert registered user

    CAcert registered users that the data they register with CAcert are true and complete.

    CAcert cert redistributors

    CAcert redistributors deliver CAcerts' certificates unmodified. They don't acquire any rights on the certificates.

    CAcert Contributors

    The contributor assures that the material he contributes is his intellectual property or he has the right to use it for his contribution.

    Paid work

    All rights are granted to CAcert, which is covered by payment for services rendered

    Unpaid work

    The contributor grants CAcert Inc. the non-exclusive right to use any contribution, without any obligations of any licenses, such as the GPL's clause about full disclosure. The contributor has the right to reuse any work for other projects and under other licenses, but this right is limited to any actual contribution. Simply making modifications does not give rights over any greater entity or the site in general. (c.f. Contributions

    CAcert Authorized Contributor

    An authorized contributor may not disclose non public information to any 3rd party without CAcert's express written consent. He is entitled to communicate user related information to the affected user if he took reasonable steps to verify his communication partner is actually the legal owner of this information.

    Multiple categories

    If someone should fall under multiple categories of chapter 2.1 and its subchapters, the sum of responsibilities or the strictest responsibility applies

    2.1.1 CA obligations

    CAcert operates their service and distributes material in the hope that it will be useful, but without any warranty; without even the implied warranty of merchantability or fitness for a particular purpose.

    Particularly CAcert issues certificates for CAcert registered users based on the information provided by the RA, revokes certificates based on the certificate owners requests and publishes the Certificate Revocation Lists (CRLs)

    2.1.2 RA obligations

    CAcert Assurer

    CAcert assurers stipulate that they assure CAcert users according to the current assurance rules set up by CAcert.

    2.1.3 Subscriber obligations

    CAcert subscribers will provide accurate Data to CAcert and they issue a revocation request if their private key gets lost or becomes compromised.

    CAcert domain master

    CAcert domain masters assure that they are legal owners of the domains they request certificates for or are given the authority to do so by the domain owner.

    CAcert assured user

    CAcert users assure that the statements they made towards CAcert or the CAcert assurer are true and complete.

    Notification

    Subscribers are notified hereby that electronic signatures can be legally binding. The extent to which they are trusted depends on local legislation. Specifically CAcert certificates do not enable you to do "qualified signatures". That means that jurisdiction will decide on a case by case base whether or not they are legally binding. Because of these legal implications, Subscribers must protect their private keys. This included, that they are not supposed to provide this key to CAcert.

    Digital encryption is not meant to be recovered without the private key. If the private key is lost, all encrypted documents are lost and cannot be recovered. If the certificate expires or is revoked, some software will also refuse to decrypt documents. CAcert does not own this private key (c.f. previous paragraph) and thus cannot recover it. Therefore users are supposed to backup their key or prepare for the loss of encrypted documents.

    2.1.4 Relying party obligations

    CAcert relying party assure that they inquired all details necessary to validate their decision. This includes, but is not limited to the check of the presented certificate against expiry time, current certificate revocation list (CRL), certificate chain and the validity check of the certificates in the chain.

    The relying party is not freed from these responsibilities by the fact that a redistributor included CAcerts' root or intermediate certificate in a product that the relying party uses.

    CAcert does not recommend to use its certificates to secure transactions above $1.000. If subscribers do so anyway, this may further restrict CAcerts' liability.

    2.1.5 Repository obligations

    CAcert will provide technical means to check for revoked certificates.

    (* imp) Currently this is the CRL, OCSP is planned.