CAcert.org Certification Practice Statement - CPS


Purpose - Certification Practice Statement


General Section - Certification Practice Statement



Text - Certification Practice Statement


1. Introduction

1.1. Overview

1.2. Document name and identification

1.3. PKI participants 1.3.1. Certification authorities

CAcert does not issue certificates to external intermediate CA's under the present policy. 1.3.2. Registration authorities

Entitled "CAcert Assurer" or "Trusted third Parties" report the identification of users to CAcert. In addition, CAcert accepts CAs which are not operated by CAcert as RAs, by acknowledging a certificate with a certain amount of trust depending on the CPS of the other CA. CAcert retains 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, satisfying CAcert minimum standards in all cases. 1.3.3. Subscribers

CAcert issues certificate to unassured users, who fulfil 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.4. Relying parties

Everyone who uses certificates issued by CAcert either directly or indirectly can be a relying party. 1.3.5. Other participants

Software vendors who integrate the certificate of CAcert into its software are also relying parties with a special role in the "Internet PKI". Please consult the licenses/policies/... of the root key distribution service you are using, before relying on a certificate. 1.4. Certificate usage

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

CAcert operates 2 root certificates, one for assured users and one for unassured users. The root certificate for assured users is signed by the root certificate for unassured users (it is a sub-certificate). Relying parties can decide to trust only the assured certificates (by selecting the root for assured users as trust anchor), or all certificates (by selecting the root for unassured users as trust anchor).

Each of the root certificates signs all of the different types of certificatese/p>

Each type of Certificate is generally appropriate 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 entities 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 non-repudiation 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. Alternatively, 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 vote 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 a reason to do 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, grammar or html errors are not considered policy changes, but rather policy updates. CAcert retains 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 these 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 subscriber, 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 whose identity is verified by an Assurer or other registration authorities. CAcert Assurer

A CAcert assured user who is authorized by CAcert to verify 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. Relying party

Anyone who bases their decisions on a certificate. CAcert cert redistributors

CAcert users, who distribute CAcert's 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

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, CRLs and new information will be published as soon as they are issued. The subscribers acceptance of a certificate is not required. 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 pseudonym 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 existence 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 assured. 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 CA's 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 expire after 6 Month

(* imp) Client Certificates of non-assured people expire 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


4. Certificate Life-Cycle Operational Requirements (11)

4.1. Certificate Application 4.1.1. Who can submit a certificate application

Anyone who has web-browser capabilities and internet-access is eligible to request CAcert's services. 4.1.2. Enrolment process and responsibilities

The user has to generate a key-pair, either with his browser (for client certificates), or manually (for server certificates). The user can decide to store the key-pair on the computer or on a hardware token. The private key is never sent to the CA, or anyone else. 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 The user is authenticated on the web-interface either with his username/passphrase or with his digital certificate. The user's identity is checked by an assurer or a trusted third party. The digital identity of the user is automatically checked by an email probe either to the email address for client certificates, or to one of the administrative email addresses for the domain in question. 4.2.2. Approval or rejection of certificate applications 4.2.3. Time to process certificate applications The certificate application process is completely automated, and should be finished in less than a minute. 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 There are no special actions during the certificate issuance. 4.3.2. Notification to subscriber by the CA of issuance of certificate The CA notifies the subscriber via email about the issuance of the certificate. 4.4. Certificate acceptance 4.4.1. Conduct constituting certificate acceptance The user does not need to explicitly accept the certificate. If the user does not accept the certificate, he has to revoke the certificate. 4.4.2. Publication of the certificate by the CA The CA may publish the issued certificates in a repository (Keyserver, LDAP, X.500, ...). 4.4.3. Notification of certificate issuance by the CA to other entities There are no external entities that are notified about issued certificates. 4.5. Key pair and certificate usage 4.5.1. Subscriber private key and certificate usage There are no special restrictions or responsibilities for the usage of the private key or the certificate usage. 4.5.2. Relying party public key and certificate usage

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 the liability of CAcert. 4.6. Certificate renewal 4.6.1. Circumstance for certificate renewal A certificate can be renewed anytime. 4.6.2. Who may request renewal For personal certificates, the person issued the certificate may request the renewal of the certificate. For organisational certificates, any of the organisation-administrator my request the renewal of the certificate. 4.6.3. Processing certificate renewal requests The procedure of certificate renewal is similar to the initial certificate issuance. The user has to login into the web-interface, and start the request there. The subject of the certificate is checked, whether the necessary conditions are still fulfilled. 4.6.4. Notification of new certificate issuance to subscriber The subscriber is notified with an email about the renewal of his certificate. 4.6.5. Conduct constituting acceptance of a renewal certificate There is no need to explicitly accept the renewed certificate. 4.6.6. Publication of the renewal certificate by the CA The CA may publish the renewed certificates in a repository. 4.6.7. Notification of certificate issuance by the CA to other entities There are no external entities that are notified of certificate renewal. 4.7. Certificate re-key 4.7.1. Circumstance for certificate re-key

A re-key request is a normal new-certificate request. 4.7.2. Who may request certification of a new public key

N/A 4.7.3. Processing certificate re-keying requests

N/A 4.7.4. Notification of new certificate issuance to subscriber

N/A 4.7.5. Conduct constituting acceptance of a re-keyed certificate

N/A 4.7.6. Publication of the re-keyed certificate by the CA

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

N/A 4.8. Certificate modification 4.8.1. Circumstance for certificate modification There is no way to modify a certificate. A new certificate has to be issued instead. 4.8.2. Who may request certificate modification

N/A 4.8.3. Processing certificate modification requests

N/A 4.8.4. Notification of new certificate issuance to subscriber

N/A 4.8.5. Conduct constituting acceptance of modified certificate

N/A 4.8.6. Publication of the modified certificate by the CA

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

N/A 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 The revocation in the Web Interface for users is automated, so the request should be handled in less than a minute. The notice of a fraudulent user must be processed by CAcert in less than one week. 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)

CRLs are issued after every certificate revocation 4.9.8. Maximum latency for CRLs (if applicable)

The maximum latency between revocation and CRL issuing is 1 hour. 4.9.9. On-line revocation/status checking availability

A full OCSP responder is provided by CAcert under http://ocsp.cacert.org/ 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

An OCSP Responder is provided unter http://oscp.cacert.org/ . 4.10.2. Service availability

OCSP is generally available on the internet. Due to the structure of the internet, the availability of the OCSP service can not be guaranteed at any client computer. 4.10.3. Optional features

N/A 4.11. End of subscription

The certificates expire automatically, if necessary, the certificates can be revoked by the user. 4.12. Key escrow and recovery 4.12.1. Key escrow and recovery policy and practices

CAcert does not offer a key escrow service. 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

The power is maintained with a UPS and a power generator. Air conditioning is available 5.1.4. Water exposures

The geographical region is not at risk of water exposures 5.1.5. Fire prevention and protection

Fire detectors are installed 5.1.6. Media storage

Sensitive data is always encrypted on external media. 5.1.7. Waste disposal

Paper has to be shredded and burnt. Digital files have to be wiped with secure wipe programs. 5.1.8. Off-site backup

CAcert has encrypted off-site backups 5.2. Procedural controls 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

5.2.2. Number of persons required per task

For assurance, a minimum number of 2 Assurers are needed. 5.2.3. Identification and authentication for each role

5.2.4. Roles requiring separation of duties

An audit (WebTrust, ...) of the CA must not be done by someone affiliated with CAcert (Board, Assurer, ...). 5.3. Personnel controls 5.3.1. Qualifications, experience, and clearance requirements

5.3.2. Background check procedures

Support Personnel, Developers and System administrators have to undergo a detailed background check:

5.3.3. Training requirements

There are no training requirements. 5.3.4. Retraining frequency and requirements

N/A 5.3.5. Job rotation frequency and sequence

There is no planned job rotation yet. 5.3.6. Sanctions for unauthorized actions

In case of unauthorized, grossly negligent or otherwise damaging actions, CAcert can revoke the authorization of a person, and the taken actions that were done, as far as possible. 5.3.7. Independent contractor requirements

There are no independent contractors. 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 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 log files 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 log-files are automatically backup´d 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

The users, organisations, all issued certificates and signatures, and all assurances are recorded 5.5.2. Retention period for archive

The data retention period is planned to be 30 years, to be usable for digital signature applications 5.5.3. Protection of archive

The data is stored in a live-database 5.5.4. Archive backup procedures

The data is regularly backup´d on encrypted media 5.5.5. Requirements for time-stamping of records

The records are timestamped with a time-synchronized server 5.5.6. Archive collection system (internal or external) 5.5.7. Procedures to obtain and verify archive information

There are no special procedures to obtain archive information 5.6. Key changeover 5.7. Compromise and disaster recovery 5.7.1. Incident and compromise handling procedures

In case of emergency, the system administrators may shut-down the services, until the integrity and security of the system is ensured again

All passwords of the affected systems have to be changed.

The log-files and the data of the backups have to be compared with the current data to detect modifications.

The identity of the intruder has to be determined.

The motives of the intruder have to be determined.

In case of a leak, all unauthorized copies of the data have to tracked down, and securely deleted (wiped, ...). 5.7.2. Computing resources, software, and/or data are corrupted

In the case of corrupted data, a backup can be restored, and the users have to be informed that any changes in the mean time are gone. 5.7.3. Entity private key compromise procedures

In the unlikely case of a private key compromise, first an investigation of the security leak has to be done. Afterwards, a new key is generated, published on the website, and distributed to known relying parties like the browser vendors, ... 5.7.4. Business continuity capabilities after a disaster

In case of a disaster, a new system will have to be setup, and the off-site backups restored. 5.8. CA or RA termination


6. Technical Security Controls (11)

N/A 6.3.2. Certificate operational periods and key pair usage periods

N/A 6.4. Activation data 6.4.1. Activation data generation and installation

N/A 6.4.2. Activation data protection

N/A 6.4.3. Other aspects of activation data

N/A 6.5. Computer security controls 6.5.1. Specific computer security technical requirements

N/A 6.5.2. Computer security rating

N/A 6.6. Life cycle technical controls 6.6.1. System development controls

N/A 6.6.2. Security management controls

N/A 6.6.3. Life cycle security controls

N/A 6.7. Network security controls

There are both network firewalls and server based firewalls to secure the systems. 6.8. Time-stamping

CAcert uses at least NTP time-synchronisation on every sub-component as a trusted time sources.

7. Certificate, CRL and OCSP Profiles

(imp): X.509 v2 7.2.2. CRL and CRL entry extensions 7.3. OCSP profile 7.3.1. Version number(s)

OCSP Version 1 7.3.2. OCSP extensions

N/A

8. Compliance Audit and Other Assessments

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.

There are no certificate access fess. 9.1.3. Revocation or status information access fees

There are no revocation or status information access fees. 9.1.4. Fees for other services

A trusted third party assurance directly from CAcert.org costs 10.- USD 9.1.5. Refund policy

A refund of the membership fees is not possible.

No financial responsibility is accepted. 9.2.1. Insurance coverage

N/A 9.2.2. Other assets

N/A 9.2.3. Insurance or warranty coverage for end-entities

N/A 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. 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 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 and 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

End of Certification Practice Statement


Inputs & Thoughts


Category or Categories

CategoryPolicy

Brain/PoliciesAndSignificantTechnicalStandards/CertificationPracticeStatement (last edited 2018-01-17 19:14:34 by EtienneRuedin)