CAcert CPS and CP

  1. INTRODUCTION
  2. PUBLICATION AND REPOSITORY RESPONSIBILITIES
  3. IDENTIFICATION AND AUTHENTICATION
  4. CERTIFICATE LIFE-CYCLE OPERATIONAL REQUIREMENTS
  5. FACILITY, MANAGEMENT, AND OPERATIONAL CONTROLS
  6. TECHNICAL SECURITY CONTROLS
  7. CERTIFICATE, CRL, AND OCSP PROFILES
  8. COMPLIANCE AUDIT AND OTHER ASSESSMENTS
  9. OTHER BUSINESS AND LEGAL MATTERS

1. INTRODUCTION

1.1. Overview

This document is the Certificate Practice Statement (CPS) of CAcert, the community Certification Authority (CA). It describes the set of rules and procedures used by CAcert, and applies to all CAcert PKI Participants, including Assurers, Customers, Resellers, Subscribers, Relying Parties and CAcert itself.

1.2. Document name and identification

This document is the Certificate Practice Statement (CPS) of CAcert. The CPS also fulfils the role of the Certificate Policy (CP) for each class of certificate.

The CPS is an authoritive document, and rules other documents except where explicitly deferred to. This document itself is under the control of the Configuration-Control Specification ("CCS"). See also 1.5.1 Organisation Administering the Document.

The CA is operated by CAcert Incorporated, an association registered in New South Wales, Australia. More details on the association are found at www.cacert.org.

1.3.1. Certification authorities

CAcert does not issue certificates to external intermediate CAs under the present CPS.

1.3.2. Registration authorities

Three forms of Registration Authorities (RAs) are primarily used to verify the identification of Users:

  1. "CAcert Assurer" are Users within CAcert who are assured, trained and authorised to conduct assurances,
  2. "Trusted Third Parties" are professionals that are approved by CAcert for bootstrapping country networks of Assurers,
  3. "Third Party Certificate Authorities" are CAs approved by CAcert to provide assurance by means of their issued certificates.

The process of Assurance is subject to continuous improvement, and other forms of Registration Authority may be introduced as part of that process.

1.3.3. Subscribers

CAcert issues certificates to Users who have registered at the CAcert website. Such Users then become Subscribers.

1.3.4. Relying parties

A relying party is a Registered user of CAcert, who in the act of using a CAcert certificate makes a decision on the basis of that certificate.

1.3.5. Other participants

Vendor. Software suppliers who integrate the root certificates of CAcert into their software also assume a proxy role of Relying Parties.

Non-related Parties (NRPs). These are users of browsers and similar software who are unaware of the CAcert certificates they may use, and are unaware of the ramifications of usage. The only legal or contract relationship with CAcert and their only rights are described by the NRP Disclaimer and Licence. If they rely on a relationship, it must be with their vendor.

1.4. Certificate usage

CAcert serves as issuer of certificates for individuals, businesses, governments, charities, associations, churches, schools, non-governmental organizations or other groups. CAcert certificates are intended for low-cost community applications especially where volunteers can become Assurers and help CAcert to help the community.

Types of Certificate and their appropriate and corresponding applications are defined in §1.4.1. Prohibited applications are defined in §1.4.2. Specialist uses may be agreed by contract or within a specific environment, as described in §1.4.4. Note also the unreliability caveats in §1.4.3 and risks, liabilities and obligations in §9.

Type
Appropriate Certificate uses
General Protocol
Description
Comments
Server
 TLS Webserver encryption Enables encryption
embedded embedded server authentication mailservers, IM-servers
Client
 S/MIME email encryption "digital signatures" employed in S/MIME are not legal / human signatures, but instead enable the encryption mode of S/MIME
TLS client authentication the nodes must be secure
TLS web based signature applications the certificate authenticates only. See §1.4.3.
"Advanced Signing" for document signature uses only within a wider application such as mandated by regulations, as agreed by contract. See §1.4.4.
Code
 ??? Code Signing Signatures on packages are indicative of Identity
PGP
 OpenPGP Key Signing Signatures on User Keys are indicative of Identity
Table 1.4. Types of Certificate

1.4.1. Appropriate certificate uses

General uses.

1.4.2. Prohibited certificate uses

CAcert certificates are not designed, intended, or authorised for the following applications:

1.4.3. Unreliable Applications

CAcert certificates are not designed nor intended for use in the following applications, and may not be reliable enough for these applications:

1.4.4. Limited certificate uses

By contract or within a specific environment (e.g. internal to a company), CAcert users are permitted to use Certificates for higher security, customised or experimental applications. Any such usage, however, is limited to such entities and these entities take on the whole responsible for any harm or liability caused by such usage.

Digital signature applications. CAcert "advanced signing" client certificates can be used by Assured Users to digitally sign certain forms of documents, as part of a wider application and set of rules. This use is restricted to:

  1. A specific environment exists. Examples of this might be that invoices must be digitally signed by regulation, or where contracts are exchanged for purchase/supply agreements.
  2. The meaning of the signature is well understood by all parties.
  3. Sender and recipients agree on the meanings and uses.
  4. The "advanced signing" certificate is only used within the environment for that limited purpose.
  5. The usage is not solely secured by the digital signature.
  6. The risks, liabilities and obligations are understood by all parties.
  7. The certificate is encrypted and stored on hardware controlled by the Subscriber, and is never delegated.

"Advanced signing" certificates are only available to Assured Users in named form using the Class 3 root.

1.4.5. Roots and Names

Assured Users may be issued certificates with their verified names in the certificate. In this role, CAcert operates and supports a network of Assurers who verify the identity of the users.

All Users can be issued certificates that are anonymous, which is defined to be that there is no user name in the certificate. These may be considered to be similar to self-signed certificates. In this role, CAcert provides the infrastructure only, saving the users from managing a difficult and messy process in order to get manufactured certificates.

Level of Assurance
unassured Users
Assured Users
Class of Root Anonymous Id. Anonymous Identity
Class
1
Class
3
Table 1.4.4. Types of Certificate

CAcert operates these 2 roots:

The Class 3 root is signed by the Class 1 root (the former is a sub-certificate of the latter, hence the Class 3 root is technically an intermediate certificate of the Class 1 root).

Relying parties can decide to trust only certificates for Assured Users (by selecting the Class 3 root for Assured Users as trust anchor), or all certificates (by selecting the Class 1 root for unassured Users as trust anchor). Assured Users have the option of using the Class 1 root but this facility is intended for compatibility rather than as a feature in its own right.

1.5. Policy administration

See 1.2 Document Name and Identification for general scope of this document.

1.5.1. Organization administering the document

This document is administered by CAcert Incorporated. CAcert Incorporated is an association registered in New South Wales, Australia.

1.5.2. Contact person

Further information on CAcert is found on the CAcert.org website. For questions including about this document:

1.5.3. Person determining CPS suitability for the policy

This CPS is managed by the CAcert community on the policy forum. See discussion forums above.

1.5.4. CPS approval procedures

CPS is controlled and updated according to the Configuration-Control Specification ("CCS").

In brief, the policy forum prepares and discusses. After a last call, the document moves to DRAFT status for a defined period. If no challenges have been received in the defined period, it moves to DOCUMENT ("approved") status. The process is modelled after IETF's RFC process.

1.5.5 CPS updates

As per above.

1.6. Definitions and acronyms

Certificate. A certificate is a piece of cryptographic data used to validate certain statements, especially those of identity.

CAcert. CAcert is a community certificate authority as defined under §1.2 Identification.

CAcert User. Everyone who registers an account at CAcert and makes use of CAcert's data, programs or services. Only individuals and not legal entities can register.

CAcert unassured User. A CAcert User who has registered at CAcert, but is not yet Assured.

CAcert Subscriber. A registered User who requests and receives a certificate.

CAcert Assured User. A CAcert User whose identity is verified by Assurers or other approved Registration Authorities.

CAcert Assurer. A CAcert Assured User who is authorised by CAcert to verify the identity of other users.

CAcert Domain Masters. A CAcert Subscriber who has some level of control over the Internet domain name that is the subject of a request for certificates to CAcert.

Organisation Agent. An Assured User who is authorised to act for an Organisation. (Same as Organisation Administrator.)

Organisation Counseller. An Assurer who is appointed to interface and work with an Organisation.

CAcert Organisation Administrator. A CAcert assurer who is authorised by an organisation to vouch for the identity of others users of the organisation. (Same as Agent.)

Reliance. The act of making a decision, including taking a risk, which decision is in part or in whole informed or on the basis of the contents of a certificate.

Relying Party. Anyone who relies (that is, makes decisions or takes risks) in part or in whole on a certificate.

Usage. The event of allowing a certificate to participate in a protocol, as decided and facilitated by a user's software. Generally, does not require significant input, if any, on the part of the user.

CAcert Relying Party. CAcert Users who make decisions based in part or in whole on a certificate issued by CAcert. Only Registered Users are permitted to Rely on CAcert certificates.

CAcert certificate 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. Submissions into CAcert's 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.

CAcert "Advanced Signing" Certificate. A certificate created for the express purpose of signing a limited range of documents within a community that expressely agrees and regulates these documents.

Configuration-Control Specification (CCS). The document that controls changes to this CPS.

"Trusted Third Parties" (TTPs). Professionals that are approved by CAcert for bootstrapping country networks of Assurers. Generally, drawn from bank managers, notaries public, and other professions with substantial reputational capital.

"Third Party Certificate Authorities". Other certificate authorities that are approved by CAcert to provide assurance by means of their issued certificates.

2. PUBLICATION AND REPOSITORY RESPONSIBILITIES

2.1. Repositories

CAcert operates no repositories in the sense of lookup for non-certificate-related information.

2.2. Publication of certification information

CAcert publishes:

CAcert does not publish information on issued certificates.

2.3. Time or frequency of publication

Root and Intermediate Certificates and CRLs are made available on issuance.

2.4. Access controls on repositories

All information described above is available on the basis of read-only.

3. IDENTIFICATION AND AUTHENTICATION

3.1. Naming

3.1.1. Types of names

Client Certificates. The DN contains both of:

Server Certificates. The DN contains:

Certificates for Organisations. The following additional fields are used:

Other Subscriber information that is collected and/or retained does not go into the certificate.

3.1.2. Need for names to be meaningful

No stipulation.

3.1.3. Anonymity or pseudonymity of subscribers

Unassured Users may only request anonymous certificates. Assured Users can choose between identified or anonymous certificates. CAcert does not currently offer pseudonymous certificates (those with a name that does not relate to the Assured User's verified name).

3.1.4. Rules for interpreting various name forms

Names are administered by means of the User's account. The rules themselves may be varied on short notice by CAcert as fraud such as phishing is moving too quickly for 'policy' documents.

3.1.5. Uniqueness of names

For Individual certificates, uniqueness is provided primarily by email addresses or domain names. For Organisation certificates, uniqueness is provided by the corporate naming system.

Each domain name, email address, or corporate name can only be registered to one user. A user may generate multiple certificates for the names they have registered.

3.1.6. Recognition, authentication, and role of trademarks

The process of Organisation Assurance controls issues such as trademarks. As each country is distinct, Organisational Assurance may defer to local arrangments, when approved and established by country organisational assurance teams.

A trademark is disputed by means of filing a dispute. See §9.13. CAcert can reject or suspend any certificate without liability in case of a dispute.

3.2. Initial Identity Verification

Identity is verified by CAcert's Assurance process. Assurers allocate to Users a number of points on a scale from 0 to 200, as described in Table 3.2.a.

Points Level Services
0-49 User anonymous certificates only
50-99 Assured User Identified and anon certificates for S/MIME, web servers, "advanced signing."
Agent Can act as Corporate Agent (insider)
100++ Assurer Conduct verifications of Users
Counseller Can act as Corporate counseller (outsider)
100++
ID on file		 Code-signer Can create Code-signing certificates
IDN Can create International Domain Name (IDN) certificates
Table 3.2.a Points for Assurance

Users can get points by the programs described in Table 3.2.b:

Program Process Points
Web-of-Trust Assurance Assurers, who have at least 100 points themself verify the identity of User at a personal meeting 10-35
Trusted Third Party Assurance Bank managers or Public notaries verifiy the identify of a User at a personal meeting 75
Table 3.2.b Assurance programs

The level at which each User is Assured is public data. The number of points for each User is not published.

3.2.1. Method to prove possession of private key

CAcert uses industry-standard techniques to prove the possession of the private key.

For X.509 server certificates, the stale digital signature of the CSR is verified. For x.509 client certificates for "netscape" browsers, SPCAK uses a challenge-response protocol to check the private key dynamically. For x.509 client certificates for "explorer" browsers, ActiveX uses a challenge-response protocol to check the private key dynamically.

No technique is used for OpenPGP currently, in line with OpenPGP practice.

3.2.2. Authentication of Individual Identity

All Users are required to register an account with CAcert. During the registration process Users are asked to supply information about themselves:

CAcert runs an Assurance process that allocates points according to the strength of the validation. When a User is allocated 50 or more points, they become an Assured User and may then issue named certificates.

Relying Party Statement
A relying party may rely on the User named in a certificate having been assured to at least 50 points by the Assurers or Trusted Third Parties.

The following general statements about Assurance are averred by CAcert and may be relied upon by the relying party:

3.2.3. Authentication of organization identity

Organisations present special challenges. The Assurance process for Organisations is intended to permit the Organisational Name to appear in certificates. The process relies heavily on the Individual process described above.

The general process is:

  1. The organisation must authorise in writing a named natural person (that is, a human being) to act as Agent for the purposes of CAcert's relationship with the Organisation.
  2. The Agent must become Assured.
  3. An Assurer is appointed as Organisational Counseller.
  4. The Agent presents the following documentation to the Counseller:
  5. The Counseller verifies the above documentation and conducts other appropriate checks such as verifying the location of the business.
  6. The Counseller enables the Agent's account to add the Organisation.
  7. The Agent may now act for the Organisation and add the common name (CN) into a certificate.

The Organisational Assurance achieves this standard:

  1. One Assurer verifies the Organisation's existance.
  2. An Assured User takes responsibility for the Organisation.
  3. The Organisation authorises the relationship.

3.2.4. Non-verified subscriber information

No stipulation.

3.2.5. Validation of authority

The authority over a domain is tested by means of the Email-ping test to at least one of the email addresses recorded in the whois records, or to a known and accepted standard name.

3.2.6. Criteria for interoperation

CAcert does not currently issue certificates to subordinate CAs or other PKIs.

3.3. Identification and Authentication

Users are authenticated when they login to their accounts.

4. CERTIFICATE LIFE-CYCLE OPERATIONAL REQUIREMENTS

4.1. Certificate Application

4.1.1. Who can submit a certificate application

Registered Users may submit certificate applications. On issuance of certificates, Users become Subscribers.

4.1.2. Enrolment process and responsibilities

Users generate their own key-pairs and maintain their private keys secure and private. See §9.6.

4.2. Certificate application processing

The certificate application process is completely automated. Applications, approvals and rejections are handled by the website system. Each application should be processed in less than a minute.

Where certificates are requested for more than one purpose, the requirements for each purpose must be fulfilled.

4.2.1. Performing identification and authentication functions

Users are authenticated by logging in to CAcert's website.

4.2.2. Verifying Control of Email Addresses

Email-Ping test. Email addresses are verified in the following manner:

4.2.3. Email and Client Certificate Procedures

Email accounts are verified for client certificates in the following manner:

4.2.4. Server Certificate Procedures

Domains are verified for server certificates in the following manner:

4.2.5. Code-signing Certificate Procedures

Code-signing certificates are processed in a similar manner to client certificates. A User must have 100 Assurance points. A scanned copy of photo ID needs to be sent to CAcert, and this ID must be checked and recorded.

4.2.6. OpenPGP Signatures

OpenPGP signatures are processed in the following manner:

4.3. Certificate issuance

4.3.1. CA actions during certificate issuance

Key Sizes. Users may request keys of any size permitted by the key algorithm. Many older hardware devices require small keys.

Algorithms. CAcert currently only supports the RSA algorithm for x.509 user keys. X.509 signing uses the SHA-1 message digest algorithm. OpenPGP Signing uses RSA signing over RSA and DSA keys.

Process for Certificates: All details in each certificate are verified by the website issuance system. Issuance is based on a 'template' system that selects profiles for certificate lifetime, size, algorithm.

  1. The CSR is verified.
  2. Data is extracted from CSR and verified (Name, Emails, Domains).
  3. Certificate is generated from template.
  4. Data is copied from CSR.
  5. Certificate is signed.
  6. Certificate is stored as well as mailed.

Process for OpenPGP key signatures: All details in each Sub-ID are verified by the website issuance system. Issuance is based on the configuration that selects the profile for signature lifetime, size, algorithm.

  1. The key is verified.
  2. Data is extracted from the key and verified (Name, Emails).
  3. OpenPGP Key Signature is generated.
  4. Key Signature is applied to the key.
  5. The signed key is stored as well as mailed.

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

Once signed, the certificate is mailed to the User, as well as being stored in the system and available via the User's account.

4.4. Certificate acceptance

4.4.1. Conduct constituting certificate acceptance

There is no need for the user to explicitly accept the certificate. In case the user does not accept the certificate, the certificate has to be revoked again.

4.4.2. Publication of the certificate by the CA

CAcert does not yet publish the issued certificates in any repository. In the event that CAcert will run a repository, the publication of certificates and signatures there will be at the users options.

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

See §9.6-9.

4.5.1. Subscriber private key and certificate usage

Subscribers are obliged to:

See §9.6.3.

4.5.2. Relying Party Public Key and Certificate Usage

The Relying Party must make their own decision in using each certificate. They must examine the certificate and other sources of information for that purpose. This includes, but is not limited to checking:

Statements of Reliance for Registered Users
Class of Root
Anonymous
Identity
Class
1
 None.
Relying party must use other methods to check. 		The named User has been Assured by CAcert
(issued for compatibility only).
Class
3
 The User has been Assured by CAcert.
(The Identity is not available.)		 The User named in the certificate has been Assured by CAcert.
Table 4.5.2. Statements of Reliance

With a CAcert anonymous certificate, the Relying Party may only rely that the certificate was issued by CAcert on behalf of a User, but the name is not provided.

With a CAcert Class 3 certificate, the relying party may rely that the identity has been verified and assured by CAcert RAs according to this CPS.

Additional information may only be sought by means of dispute resolution. See §9.13.

If a product that the relying party uses includes an embedded root from CAcert, then the relying party's responsibilities and liabilities do not automatically transfer to the supplier of that product.

Who may rely. Relying parties are generally registered users, and as such are bound by this CPS. Other parties may enter into agreement with CAcert by means of third party agreements (for suppliers of software), etc, and thus also become Relying Parties. The licence and permission to rely is not assignable.

NRPs may not rely. If not related to CAcert by means of an agreement that binds the parties to dispute resolution within CAcert's forum, a person is a non-related-person (NRP). An NRP is not permitted to rely and is not a Relying Party. See the CAcert NRP Disclaimer and Licence for more details.

4.6. Certificate renewal

A certificate can be renewed at any time. The procedure of certificate renewal is the same as for the initial certificate issuance.

4.7. Certificate re-key

Certificate "re-keyings" are not offered nor supported. A new certificate with a new key has to be requested and issued instead, and the old one revoked.

4.8. Certificate modification

Certificate "modifications" are not offered nor supported. A new certificate has to be requested and issued instead.

4.9. Certificate revocation and suspension

4.9.1. Circumstances for revocation

Certificates may be revoked under the following circumstances:

  1. As initiated by the Subscriber on the website.
  2. As initiated in an emergency action by a core support team member. Such action will immediately be referred to dispute resolution for ratification.
  3. Under direction from the Arbitrator in a duly ordered ruling from a filed dispute.

These are the only three circumstances under which a revocation occurs.

4.9.2. Who can request revocation

The Subscriber may initiate at any time via the website.

The Arbitrator may direct revocation pursuant to a duly filed dispute.

4.9.3. Procedure for revocation request

The User logs in to the Web Interface.

In any other event such as lost passwords or fraud, a dispute should be filed at support at CAcert.org.

4.9.4. Revocation request grace period

No stipulation.

4.9.5. Time within which CA must process the revocation request

The revocation automated in the Web Interface for subscribers, and is handled generally in less than a minute.

A filed dispute that requests a revocation should be handled within a week, however the Arbitrator has discretion.

4.9.6. Revocation checking requirement for relying parties

Each revoked certificate is recorded in the certificate revocation list (CRL). Relying Parties must check 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)

A new CRL is issued after every certificate revocation.

4.9.8. Maximum latency for CRLs (if applicable)

The maximum latency between revocation and issuance of the CRL is 1 hour.

4.9.9. On-line revocation/status checking availability

OCSP is available at http://ocsp.cacert.org/ .

4.9.10. On-line revocation checking requirements

Relying parties must check up-to-date status before relying.

4.9.11. Other forms of revocation advertisements available

None.

4.9.12. Special requirements re key compromise

Subscribers are obliged to revoke certificates at the earlist opportunity.

Tie in with Obligations §4.5.1 and Reps §9.6.3.

4.9.13. Circumstances for suspension

Suspension of certificates is not available.

4.9.14. Who can request suspension

Not applicable.

4.9.15. Procedure for suspension request

Not applicable.

4.9.16. Limits on suspension period

Not applicable.

4.10. Certificate status services

4.10.1. Operational characteristics

OCSP is available at http://ocsp.cacert.org/ .

4.10.2. Service availability

OCSP is made available on an experimental basis.

4.10.3. Optional features

No stipulation.

4.11. End of subscription

Certificates include expiry dates.

4.12. Key escrow and recovery

4.12.1. Key escrow and recovery policy and practices

CAcert does not generate nor escrow subscriber keys.

4.12.2. Session key encapsulation and recovery policy and practices

No stipulation.

5. FACILITY, MANAGEMENT, AND OPERATIONAL CONTROLS

The following sections need to be clarified / aligned with the security manual.

5.1. Physical controls

5.1.1. Site location and construction

Servers are housed in a secure colocation facility.

5.1.2. Physical access

Does the Colocation facility have an audit/standard rating?

The facility operates a system of door-locks and personnel.

5.1.3. Power and air conditioning

The facility provides UPS protected power, and a standby generator.

5.1.4. Water exposures

The facility is not at risk of external flooding.

5.1.5. Fire prevention and protection

The facility has fire detection installed.

5.1.6. Media storage

Nature of keys? Readback provisions? Re-read?

Backups are encrypted onto physical media.

5.1.7. Waste disposal

No stipulation.

5.1.8. Off-site backup

This section deals with location and physical security of offsite backups.....

TBD

5.2. Procedural controls

5.2.1. Trusted roles

5.2.2. Number of persons required per task

CAcert operates to the 4 eyes principle. All important roles require a minimum of 2 people. The people may be tasked to operate in parallel or in serial.

5.2.3. Identification and authentication for each role

Assurers. New Assurers are generally required to be Assured by at least three Assurers.

Trusted-Third-Party Assurance Programme. Where a community lacks any Assurers within reasonable distance, CAcert uses its Trusted-Third-Party (TTP) Assurance Programme to bootstrap the community. Bank managers or Notaries act as TTPs and are trusted to verify the identity of a few initial Assurers. Identification and Authentication of the TTPs is generally checked by conventional means (phone, fax) by CAcert.

All others. All others are required to be assured at least to the level of Assurer.

5.2.4. Roles requiring separation of duties

The only role not subject to four eyes principle is that of TTP, by definition. At the earliest convenience, the activities and assurances of this role are confirmed by Assurers from other communities.

5.3. Personnel controls

5.3.1. Qualifications, experience, and clearance requirements

Assurers. Once a User is Assured, and has gained experience, they are encouraged to advance to the level of Assurer. To be accepted as Assurer, Users need:

TTPs. There is no specific qualification for TTPs. They are generally selected and approved by the board on the basis of country conditions. Notary Publics and bank managers are generally acceptable, however country conditions vary dramatically.

A pack of information is sent to each TTP. The subjects need to provide a copy of all documents to CAcert, notarised by TTP. CAcert then accepts the subjects as Assurers. As soon as possible, those accepted in this programme are likewise Assured by Assurers from other communities.

Developers and System administrators. Roles that impact the systems are all subject to the background check in the Security Manual. The existing teams test for technical knowledge. Developers are more extensively grilled on security practices. Quasi-formal qualifications on security are considered but are not required.

Arbitrators. CAcert maintains a list of Arbitrators, drawn from the pool of experienced Assurers.

All others. No stipulation.

5.3.2. Background check procedures

The Security Manual describes the background check for Support Personnel, Developers and System administrators.

5.3.3. Training requirements

The training programme for Assurers is to be described

5.3.4. Retraining frequency and requirements

No stipulation.

5.3.5. Job rotation frequency and sequence

No stipulation.

5.3.6. Sanctions for unauthorized actions

Any actions that are questionable - whether mild or grossly negligent - are filed as a dispute. The Arbitrator has wide discretion in ruling on loss of points, retraining, or termination of access or status.

5.3.7. Independent contractor requirements

No stipulation.

5.3.8. Documentation supplied to personnel

CAcert supplies the Security Handbook and the Security Manual to core team personnel.

5.4. Audit logging procedures

5.4.1. Types of events recorded

The following events are recorded:

5.4.2. Frequency of processing log

No stipulation.

5.4.3. Retention period for audit log

Event records are retained for at least 6 months.

5.4.4. Protection of audit log

There is no external access to the event logs. Internal access is only possible for system administrators.

5.4.5. Audit log backup procedures

The log-files are backed up daily to a backup-server.

5.4.6. Audit collection system (internal vs. external)

No stipulation.

5.4.7. Notification to event-causing subject

Any action beyond routine analysis requires filing a dispute and direction from the arbitrator.

5.4.8. Vulnerability assessments

5.5. Records archival

5.5.1. Types of records archived

Following types of records are archived:

5.5.2. Retention period for archive

Records that assist in digital signature verification (certificate revocation date) are indicated for retention over 30 years, based on conventions from certain sectors with high retention needs. Other records are indicated for 7 years.

How are paper forms archived?

Clashes with §1.4. Should be limited to "advanced signing" certs?

5.5.3. Protection of archive

Live data is protected by access controls. Offline backups are protected by encryption.

5.5.4. Archive backup procedures

Data is backed up in encrypted form onto physical media. Backups are done nightly.

Say more... What is covered by backups? copies where? how many duplicates? what testing and read-back procedures recovery procedures?

5.5.5. Requirements for time-stamping of records

Timestamps are automatically affixed by software onto archived records.

What protection from interference?

5.5.6. Archive collection system (internal or external)

No stipulation.

5.5.7. Procedures to obtain and verify archive information

Archive information can only be obtained and verified by means of a filed dispute.

5.6. Key changeover

Routine key changeovers are authorised under control of the CCS.

Non-routine key changeovers can only be conducted by dispute resolution processes, however this is unlikely as the effort required would almost certainly mean that the CCS could be invoked.

The mechanism for Key changeover is described in the Security Manual.

5.7. Compromise and disaster recovery

5.7.1. Incident and compromise handling procedures

All handling procedures are either routine, in which case they are dealt with directly by the website services, or they are disputes, in which case they go through DR and are dealt with according to Arbitrator's direction.

System administrators may take emergency measures, but then must enter into arbitration to confirm.

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

No stipulation.

5.7.3. Entity private key compromise procedures

Refer to Security Manual.

5.7.4. Business continuity capabilities after a disaster

Refer to Security Manual.

5.8. CA or RA termination

5.8.1 CA termination

If CAcert should terminate its operation or be taken over by another organisation, the actions will be conducted according to a plan approved by the board.

In the event of operational termination, the root keys and all private user information will be secured. The root keys will be handed over to a responsible party for the sole purpose of issuing revocations. User information will be securely destroyed.

In the event of takeover, the board will decide if it is in the interest of the Users to be converted to the new organisation. Registered Users will be notified about the conversion and transfer of the user information. Such takeover, conversion or transfer may involve termination of this CPS and other documents. See §9.10.2. Users will have reasonable time in which to file a related dispute after notification (at least one month). See §9.13.

New root keys and certificates will be made available by the new organisation as soon as reasonably practical.

5.8.2 RA termination

When an Assurer desires to voluntarily terminates her responsibilities, she does this by filing a dispute, and following the instructions of the Arbitrator.

In the case of involuntary termination, the process is the same, save for some other party filing the dispute.

6. TECHNICAL SECURITY CONTROLS

6.1. Key Pair Generation and Installation

6.1.1. Key Pair Generation

Subscribers generate their own Key Pairs. There is no technical stipulation on how Subscribers generate and keep safe their private keys. However, see §9.6 for general Obligations.

6.1.2. Private key delivery to subscriber

Not applicable.

What does this mean? ... "Idea: Anonymous certificates can be published, Personal certificates have to be kept secret"

6.1.3. Public Key Delivery to Certificate Issuer

Users login to the secure account server, protected by TLS and their password. Public Keys are delivered by cut-and-pasting them into the appropriate window. Public Keys are delivered in signed-CSR form for x.509 and in self-signed form for OpenPGP.

6.1.4. CA Public Key delivery to Relying Parties

The CA public keys (Class 1,3 roots) are distributed by these means:

Name of agreement, location?

6.1.5. Key sizes

No limitation is placed on Subscriber key sizes.

CAcert x.509 root and intermediate keys are currently 4096 bits. X.509 roots use RSA and sign with the SHA-1 message digest algorithm. See 4.3.1.

OpenPGP Signing uses both RSA and DSA (1024 bits).

CAcert adds larger keys and hashes in line with general cryptographic trends, and as supported by major software suppliers.

6.1.6. Public key parameters generation and quality checking

No stipulation.

6.1.7. Key Usage Purposes

CAcert roots are general purpose. Each root key may sign all of the general purposes - client, server, code.

The website controls the usage purposes that may be signed. This is effected by means of the 'template' system.

6.2. Private Key Protection and Cryptographic Module Engineering Controls

Root keys are stored on a single machine which operates a single daemon for signing only. See CAcert Root key protection. It has these security features:

Security of access to the machine is critical.

OK, so there are obviously lots of questions here.

  1. Is SSHD running on the machine? -- No.
  2. How often is the machine power-cycled? -- Rarely?
  3. How are the logs extracted from the machine?
  4. What monitors are looking at the root server?
  5. Are CSRs sent over? Are they verified for validity in any way?
  6. Has this been analysed against a set of criteria for e.g., HSMs? Which presumably should be extractable from papers, etc.

6.2.1. Cryptographic module standards and controls

No stipulation.

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

Not applicable.

6.2.3. Private key escrow

Not applicable.

6.2.4. Private key backup

Private root keys are backed up off-site in encrypted form.

6.2.5. Private key archival

Not applicable.

6.2.6. Private key transfer into or from a cryptographic module

Describe in brief.

Private Key generation and transfer off the signing machine is done according to the Security Manual.

6.2.7. Private key storage on cryptographic module

The signing server is the cryptographic module. Hardware based HSMs and similar have been tested, but have been found wanting, e.g., for short key lengths.

6.2.8. Method of activating private key

No stipulation.

6.2.9. Method of deactivating private key

No stipulation.

6.2.10. Method of destroying private key

No stipulation.

6.2.11. Cryptographic Module Rating

No stipulation.

6.3. Other aspects of key pair management

6.3.1. Public key archival

On website.

6.3.2. Certificate operational periods and key pair usage periods

How long is it?

No stipulation.

6.4. Activation data

6.4.1. Activation data generation and installation

No stipulation.

6.4.2. Activation data protection

No stipulation.

6.4.3. Other aspects of activation data

No stipulation.

6.5. Computer security controls

Refer to Security Manual.

6.5.1. Specific computer security technical requirements

No stipulation.

6.5.2. Computer security rating

No stipulation.

6.6. Life cycle technical controls

Refer to Security Manual for controls on System Development.

6.6.1. System development controls

No stipulation.

6.6.2. Security management controls

No stipulation.

6.6.3. Life cycle security controls

No stipulation.

6.7. Network security controls

Firewalls at network and server levels are used.

6.8. Time-stamping

How does the signing server syncronise if only connected over serial? How is timestamping done on records?

Each server synchronises with NTP.

7. CERTIFICATE, CRL, AND OCSP PROFILES

7.1. Certificate profile

7.1.1. Version number(s)

What versions of PGP are signed? v3? v4?

Issued X.509 certificates are of v3 form. The form of the PGP signatures depends on several factors, therefore no stipulation.

7.1.2. Certificate extensions

Client certificates do not include extensions.

Server certificates include the following extensions:

Code-Signing certificates include the following extensions:

OpenPGP key signatures currently do not include extensions. In the future, a serial number might be included as an extension.

7.1.3. Algorithm object identifiers

No stipulation.

7.1.4. Name forms

Refer to §3.1.1.

7.1.5. Name constraints

Refer to §3.1.1.

7.1.6. Certificate policy object identifier

No stipulation

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)

CRLs are created in X.509 v2 format.

7.2.2. CRL and CRL entry extensions

7.3. OCSP profile

7.3.1. Version number(s)

The OCSP responder operates in Version 1.

7.3.2. OCSP extensions

No stipulation.

8. COMPLIANCE AUDIT AND OTHER ASSESSMENTS

CAcert declares to operate in compliance with this CPS and other documents under the CCS. CAcert further declares that all other documentation is derivative and is ruled by the controlled document set.

Current and Past Audit information is available at CAcert.org/Audit/. It is CAcert policy to publish all final reports, directives and other major work results of all audits as soon as they are signed off by the Auditor.

As this CPS is itself subject to a current Business Systems Audit, by definition, that latter audit may issue directives that are not reflected in the version of the CPS that is audited.

8.1. Frequency or circumstances of assessment

The first audits started in late 2005, and since then, assessments have been an ongoing task. There are two major threads of assessment:

8.2. Identity/qualifications of assessor

CAcert uses business systems auditors with broad experience across the full range of business, information systems and security fields. In selecting a business systems auditor, CAcert looks for experience that includes but is not limited to cryptography, PKI, governance, auditing, compliance and regulatory environments, business strategy, software engineering, networks, law (including multijurisdictional issues), identity systems, fraud.

Code auditors have deep experience in secure code. In selecting a code auditor, CAcert looks for experience that includes but is not limited to cryptography, software engineering, PHP, C, networks, security engineering.

8.3. Assessor's relationship to assessed entity

Specific internal restrictions on audit personnel:

Specific external restrictions on audit personnel:

An Auditor may convene an audit team. The same restrictions apply in general to all members of the team, but may be varied. Any deviations must be documented and approved by the board.

8.4. Topics covered by assessment

Audits are generally conducted to criteria. CAcert requires that the criteria are open:

See Audit Page for the specific criteria for any given audit.

If an Auditor determines that a criteria fails to follow the above requirements, then the criteria should be reworked to conform, or should be dropped (both with explanatory notes).

8.5. Actions taken as a result of deficiency

See Audit Page.

8.6. Communication of results

See Audit Page.

9. OTHER BUSINESS AND LEGAL MATTERS

9.1. Fees

Changes to the Fees structure will be announced from time to time on the Policy mailing list. The current Fees structure is posted at wiki.cacert.org/wiki/Price.

9.1.1. Certificate issuance or renewal fees

Registration and basic certificate lifetime services (issuance, revocation, checking) are free.

9.1.2. Certificate access fees

None.

9.1.3. Revocation or status information access fees

None.

9.1.4. Fees for other services

CAcert retains the right to charge fees for additional services.

Assurance. Assurers have the option of charging a fee for an assurance of a User. However, the price must be set and notified to the User before the meeting, otherwise the assurance must be done free of charge.

TTP Assurance. A trusted third party assurance directly from CAcert costs $10.- USD.

Dispute Resolution. The Arbitrator has the right to specify fees and to specify monetary damages up to limits specified herein and in the dispute resolution policy.

Association Membership. Membership of the CAcert Association is appreciated but not required to use CAcert services. Membership fees apply.

9.1.5. Refund policy

All fees are non-refundable.

9.2. Financial responsibility

Financial risks are dealt with primarily by the dispute resolution policy.

9.2.1. Insurance coverage

CAcert does not disclose nor make representation of any Insurance policies.

9.2.2. Other assets

No stipulation.

9.2.3. Insurance or warranty coverage for end-entities

See above.

9.3. Confidentiality of business information

9.3.1. Scope of confidential information

No stipulation.

9.3.2. Information not within the scope of confidential information

No stipulation.

9.3.3. Responsibility to protect confidential information

No stipulation.

9.4. Privacy of personal information

Privacy is covered by the CAcert Privacy Policy, which is available on the website. This document is part of the CCS and is subject to the same controls as the CPS. All of the remaining sub-headings are "refer to Privacy Policy."

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

This whole area of IP statement needs to be revisited, once the R/L/O statement is defined. It may be that IP is the way to push this out, and it may be that this issue is really what this section is about.

CAcert is committed to the philosophy of free and/or open source however, due to the strict control provisions imposed by the CCS and audit criteria, some deviations are necessary.

9.5.x. Ownership versus Licence

Maybe just assume ownership and licence-back.

For assets controlled by the CCS, ownership will remain with CAcert, or, contributors extend to CAcert a non-exclusive unrestricted perpetual licence. Contributors transfer all rights to CAcert, and Licensors transfer by licence these rights.

That is, CAcert is free to use, modify, distribute, and otherwise conduct the business of the CA as CAcert sees fit with the asset.

Contributors warrant that they have the right to transfer ownership and licencors warrant the or by licence. Except where explicitly negotiated, CAcert extends back to contributors a non-exclusive, unrestricted perpetual licence, permitting them to to re-use their original work freely.

9.5.x. Brand

The brand of CAcert is made up of its logo, name, trademark, service marks, etc. Use of the brand is strictly limited to to cases where CAcert certificates and other services are in use.

9.5.x. Documents

documents plus code might be more properly stated in the CCS:

The terms of unknown licence pending discussion will apply to all content which contains such a comment.

9.5.x. Code

The terms of unknown licence pending discussion will apply to all code which contains such a comment.

9.5.x. Certificates and Roots

Pending discussion. It may be that Certs and Roots invite IP protections, so as to deliver a licence and/or disclaimer.

9.6. Representations and warranties

9.6.1 Obligations

All parties are responsible for, and represent and warrant that they take responsibility for:

  1. The security of their computers. When using certificates in any way, parties should note that platforms that are vulnerable to viruses or trojans or other weaknesses may not process any certificates properly and may give deceptive or fraudulent results.
  2. The privacy / security of their private keys. If keys are compromised then the validity of any statement or security is compromised.
  3. The quality of random numbers. Generation and usage of certificates and other cryptographic operations require good random numbers.

9.6.1. CA representations and warranties

CAcert represents and warrants that it operates the certificate authority and coordinates the Assurer process on the basis of this CPS and other documents in the CCS.

CACert is obliged to store any additional assurance documentation, and make that documentation available according to routine operations and on the order of an Arbitrator in a duly filed dispute. See §9.13.

9.6.2. RA representations and warranties

RAs (Assurers and Trusted Third Parties) represent and warrant that they will conduct a good faith effort at identifying potential subscribers (the process of assurance), and that they will maintain the documentation on each assurance for the period applicable. RAs are responsible for making available such Assurance documentation as ordered by the Arbitrator.

9.6.3. Subscriber representations and warranties

See §4.5.1.

Subscribers represent and warrant that the identity information they provide to CAcert via the assurance process is correct and truthful.

9.6.4. Relying Party representations and warranties

When relying on a certificate, relying parties should note that platforms that are vulnerable to viruses or trojans or other weaknesses may not process any certificates properly and may give deceptive or fraudulent results. It is your responsibility to ensure you are using a platform that is secured according to the needs of the application.

9.7. Disclaimers of Warranties

In today's aggressive fraud environment, all parties should understand that CAcert and its Users, Subscribers and Assurers provide service on a Best Efforts basis. CAcert seeks to provide an adequate minimum level of quality in operations.

CAcert on behalf of related parties and itself makes no Warranty nor Guarantee nor promise that the service or certificates are adequate for the needs and circumstances.

9.8. Limitations of liability

9.8.1 NRP Disclaimer on Liabilities

CAcert on behalf of related parties (RAs, Subscribers, etc) and itself disclaims all liability to NRPs in their usage of CA's certificates. See NRP-Licence and Disclaimer.

Need to add AND AGENTS to disclaimer NRP.

9.8.2 Liabilities Between Registered Users

Liabilities between related parties are dealt with by internal dispute resolution, which rules on liability and any limits. See §9.13. Related parties are Registered Users and other parties that have entered an agreement that refers disputes to internal dispute resolution.

9.9. Indemnities

No stipulation.

9.10. Term and termination

9.10.1. Term

No stipulation.

9.10.2. Termination

This CPS and other documents are under control of the CCS. Termination of this document is controlled by that policy, including notice provisions. Changes will generally involve replacement of this document with a newer, approved version. Exception - §5.8.1.

Users retain the right to file a dispute for a reasonable time after notification under any change (at least one month). See §9.13.

9.10.3. Effect of termination and survival

No stipulation.

9.11. Individual notices and communications with participants

All participants are obliged to keep their listed primary email addresses in good working order.

9.12. Amendments

Amendments to the CPS are controlled by the CCS.

9.13. Dispute resolution provisions

Note - this section subject to the Dispute Resolution Policy.

From 4.5. A person may file a dispute and seek any additional details recorded by CAcert, but cannot rely on the dispute being resolved in their favour. In particular, details may not be revealed. The dispute will be resolved according to CAcert's dispute resolution rules, and may be awarded for or against the filing person. See §9.13.

From 4.5. If a product that the relying party uses includes an embedded root from CAcert, then the relying party's responsibilities and liabilities do not automatically transfer to the supplier of that product.

CAcert provides a forum and facility for any User or other related party to file a dispute.

Users agree to file all disputes through this CAcert's internal dispute resolution forum. According to specific agreement, or to the extent possible and reasonable, other related parties also agree to file all disputes through CAcert's forum for dispute resolution.

Non-related parties ("NRPs") are also encouraged to file. The rules include specific provisions to assist.

9.14. Governing law

The governing law is that of New South Wales, Australia. Disputes are generally heard before the Arbitrator under this law. Exceptionally, the Arbitrator may elect to apply the law of the parties and events, where in common.

9.15. Compliance with Applicable Law

9.15.1 Digital Signature Law

The Commonwealth and States of Australia have passed various Electronic Transactions Acts that speak to digital signatures. In summary, these acts follow the "technology neutral" model and permit but do not regulate the use of digital signatures.

This especially means that the signatures created by certificates issued by CAcert are not in and of themselves legally binding human signatures, at least according to the laws of Australia. See §1.4.3. However, certificates may play a part in larger signing applications. See §1.4.1 for "advanced signing" certificates. These applications may impose significant obligations, risks and liabilities on the parties.

9.15.2 Privacy Law

See the Privacy Policy.

9.15.3 Legal Process from External Forums

CAcert will provide information about its Users only under legal subpoena or equivalent process from a court of competent jurisdiction. Any requests made by legal subpoena are treated as under the Dispute Resolution Rules provisions in §9.13. That is, all requests are treated as disputes, as only a duly empanelled Arbitrator has the authorisation and authority to rule on the such requests.

A subpoena should include sufficient legal basis to support an Arbitrator in ruling that information be released pursuant to the filing, including the names of claimants in any civil case and an indication as to whether the claimants are Registered Users or not (and are therefore subject to Dispute Resolution Policy).

9.16. Miscellaneous provisions

9.16.1. Entire agreement

The CCS is the ruling policy, of which this CPS is one part. Although detailed policy may be found on the website, the CCS documents rule.

If any term of this policy should be found invalid under applicable laws, the term should be replaced by the closest match according to the applicable law. A dispute should be filed against (the editor of) the document to effect this change. The validity of the other terms should not be affected.

9.16.2. Assignment

The rights under this document may not be ordinarily assigned.

9.16.3. Severability

No stipulation.

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

The Arbitrator will specify fees and remedies, if any.

By registering, Users agree to arbitrate internally any disputes, and waive rights to resolve disputes elsewhere such as in a court of law.

9.16.5. Force Majeure

No stipulation.

---This is the end of the Policy---