+This document is the Certification Practice Statement (CPS) of +CAcert, the Community Certification Authority (CA). +It describes rules and procedures used by CAcert for +operating its CA, +and applies to all CAcert PKI Participants, +including Assurers, Members, and CAcert itself. +
+ ++
+ ++This document is the Certification Practice Statement (CPS) of CAcert. +The CPS also fulfills the role of the Certificate Policy (CP) +for each class of certificate. +
+ +.x will change to .1 in the first approved instance.
++The CPS is an authoritive document, +and rules other documents +except where explicitly deferred to. +See also 1.5.1 Organisation Administering the Document. +
+ ++The CA is legally operated by CAcert Incorporated, +an Association registered in 2002 in +New South Wales, Australia, +on behalf of the wider Community of Members of CAcert. +The Association details are at the +CAcert wiki. +
+ ++CAcert is a Community formed of Members who agree to the + +CAcert Community Agreement. +The CA is technically operated by the Community, +under the direction of the Board of CAcert Incorporated. +(The Members of the Community are not to be confused +with the Association Members, which latter are +not referred to anywhere in this CPS.) +
+ ++CAcert does not issue certificates to external +intermediate CAs under the present CPS. +
+ ++Registration Authorities (RAs) are controlled under Assurance Policy +(COD13). +
+ ++CAcert issues certificates to Members only. +Such Members then become Subscribers. +
+ + ++A relying party is a Member, +having agreed to the +CAcert Community Agreement +(COD9), +who, in the act of using a CAcert certificate, +makes a decision on the basis of that certificate. +
+ ++Member. +Membership of the Community is as defined in the +COD9. +Only Members may RELY or may become Subscribers. +Membership is free. +
+ ++Arbitrator. +A senior and experienced Member of the CAcert Community +who resolves disputes between Members, including ones +of certificate reliance, under +Dispute Resolution Policy +(COD7). +
+ ++Vendor. +Software suppliers who integrate the root certificates of CAcert +into their software also assume a proxy role of Relying Parties, +and are subject to another licence. + +At the time of writing, the +"3rd Party Vendor - Disclaimer and Licence" +is being worked upon, but is neither approved nor offered. + +
+ ++Non-Related Persons (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. +Their relationship with CAcert +is described by the +Non-related Persons - Disclaimer and Licence +(COD4). +No other rights nor relationship is implied or offered. +
+ + +CAcert serves as issuer of certificates for +individuals, businesses, governments, charities, +associations, churches, schools, +non-governmental organisations 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 certificates 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 +unreliable applications in +§1.4.3 +and risks, liabilities and obligations in +§9. +
+ + +| General | +Protocol | +||
|---|---|---|---|
| TLS | +web server encryption | +enables encryption | +|
| embedded | +embedded server authentication | +mail servers, IM-servers | +|
| 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. | +|
| "Digital Signing" | +for human signing over documents | +Only within a wider application and rules + such as by separate policy, + as agreed by contract, etc. + See §1.4.4. + | +|
| Authenticode, ElfSign, Java | +Code Signing | +Signatures on packages are evidence of their Membership and indicative of Identity | +|
| OpenPGP | +Key Signing | +Signatures on Member Keys are evidence of their Membership and indicative of Identity | +|
| X.509 | +OCSP, Timestamping | +Only available to CAcert Systems Administrators, as controlled by Security Policy | +|
+General uses. +
+ ++CAcert certificates are not designed, intended, or authorised for +the following applications: +
++CAcert certificates are not designed nor intended for use in +the following applications, and may not be reliable enough +for these applications: +
+ ++By contract or within a specific environment +(e.g. internal to a company), +CAcert Members 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 signing applications. + CAcert client certificates + may be used by Assured Members in + applications that provide or support the human signing of documents + (known here as "digital signing"). + This must be part of a wider framework and set of rules. + Usage and reliance + must be documented either under a separate CAcert digital signing + policy or other external regime agreed by the parties. +
+ ++Named Certificates. +Assured Members 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 Members. +All Names are verified, either by Assurance or another defined +method under policy (c.f. Organisations). +
+ ++Anonymous Certificates. +Members can be issued certificates that are anonymous, +which is defined as the certificate with no Name included, +or a shared name such as "Community Member". +These may be considered to be somewhere between Named certificates +and self-signed certificates. They have serial numbers in them +which is ultimately traceable via dispute to a Member, but +reliance is undefined. +In this role, CAcert provides the +infrastructure, saving the Members from managing a difficult +and messy process in order to get manufactured certificates. +
+ ++Psuedonymous Certificates. +Note that CAcert does not currently issue pseudonymous certificates, +being those with a name chosen by the Member and not verifiable +according to documents. +
+ ++Advanced Certificates. +Members who are as yet unassured are not permitted to create +advanced forms such as wildcard or subjectAltName +certificates. +
+ + ++ Roots. +The (new) CAcert root layout is as below. +These roots are pending Audit, +and will be submitted to vendors via the (Top-level) Root. +
+| + | + | |||||
|---|---|---|---|---|---|---|
| + | ||||||
| Class of Root | +Anon | +Name | +Anon | +Name | +Name+Anon | +|
Root |
+ | | |
+ |
+ |
+ Signs other CAcert SubRoots only. | +
SubRoot |
+ |
+ | |
+ |
+ |
+ † For Members meeting basic checks in §4.2.2 (Reliance is undefined.) |
+
SubRoot |
+ | | |
+ |
+ |
+ Assured Members only. Fully intended for reliance. |
+
SubRoot |
+ | | |
+ |
+ |
+ Assured Organisation Members only. Fully intended for reliance. |
+
| Expiry of Certificates | +||||||
| Types | +(Inclusive to the left.) | +|||||
+Following information on OLD roots here for +descriptive and historical purposes only. +When CPS goes to DRAFT, this needs to be +converted into a short summary of the way +OLD roots are used and its relationship to +this CPS. E.g., "OLD roots are used for +testing and other purposes outside this CPS." +Because ... they still exist, and people will +look at the CPS to figure it out. +
+ +| + | + | ||||
|---|---|---|---|---|---|
| + | |||||
| Class of Root | +Anonymous | +Named | +Anonymous | +Named | +|
1 |
+ |
+ |
+ |
+ |
+ Available for all Members, reliance is undefined. |
+
3 |
+ | | |
+ |
+ Assured Members only. Intended for Reliance. |
+
| Expiry of Certificates | +|||||
| Types available | +|||||
+ Old Roots. +The old CAcert root layout is as below. These roots are Audit Fail +and will only be used where new roots do not serve: +
+See 1.2 Document Name and Identification + for general scope of this document.
+ ++This document is administered by the policy group of +the CAcert Community under Policy on Policy (COD1). +
+ ++For questions including about this document: +
+ ++This CPS and all other policy documents are managed by +the policy group, which is a group of Members of the +Community found at policy forum. See discussion forums above. +
+ ++CPS is controlled and updated according to the +Policy on Policy +(COD1) +which is part of +Configuration-Control Specification (COD2). +
+ ++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 POLICY status. +The process is modelled after some elements of +the RFC process by the IETF. +
+ ++As per above. +
+ + ++Certificate. + A certificate is a piece of cryptographic data used + to validate certain statements, especially those of + identity and membership. +
++CAcert. + CAcert is a Community certificate authority as defined under + §1.2 Identification. +
++Member. + Everyone who agrees to the + CAcert Community Agreement + (COD9). + This generally implies having an account registered + at CAcert and making use of CAcert's data, programs or services. + A Member may be an individual ("natural person") + or an organisation (sometimes, "legal person"). +
++Community. + The group of Members who agree to the + CAcert Community Agreement + (COD9) + or equivalent agreements. +
++Unassured Member. + A Member who has not yet been Assured. +
++Subscriber. + A Member who requests and receives a certificate. +
++Assured Member. + A Member whose identity has been sufficiently + verified by Assurers or other + approved methods under Assurance Policy.
+ ++Assurer. + An Assured Member who is authorised under Assurance Policy + to verify the identity of other Members. +
++Name. + As defined in the + Assurance Policy + (COD13), + to describe a name of a Member + that is verified by the Assurance process. +
+Organisation Administrator. + ("O-Admin") + An Assurer who is authorised to act for an Organisation. + The O-Admin is authorised by an organisation + to vouch for the identity of other users of the organisation. +
++Organisation Assurer. + An Assurer who is authorised to conduct assurances on + organisations. +
++Non-Related Persons. + ("NRPs") + are general users of browsers and similar software. + The NRPs are generally unaware of + CAcert or the certificates that they may use, and + are unaware of the ramifications of usage. + They are not permitted to RELY, but may USE, under the + Non-Related Persons - Disclaimer and Licence (COD4). +
++Reliance. + An industry term referring to + 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. + An industry term refering to someone who relies + (that is, makes decisions or takes risks) + in part or in whole on a certificate. +
++ Subscriber Naming. + The term used in this CPS to + describe all naming data within a certificate. + Approximately similar terms from Industry such as + "Subject naming" and "Distinguished Name" + are not used here. +
++Verification. + An industry term referring to + the act of checking and controlling + the accuracy and utility of a single claim. +
++Validation. + An industry term referring to the process of + inspecting and verifying the information and + subsidiary claims behind a claim. +
++Usage. + The event of allowing a certificate to participate in + a protocol, as decided and facilitated by a user's software. + Generally, Usage does not require significant input, if any, + on the part of the user. + This defers all decisions to the user software, + thus elevating the software as user's only and complete + Validation Authority or Agent. +
++CAcert Relying Party. + CAcert Members who make decisions based in part or in whole + on a certificate issued by CAcert. + Only CAcert Members are permitted to Rely on CAcert certificates, + subject to the CAcert Community Agreement. +
++Vendors. + Non-members 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. + Vendors are covered under a separate licence. + As of the moment, this licence is not written. +
++Configuration-Control Specification "CCS". + The audit criteria that controls this CPS. + The CCS is documented in COD2, itself a controlled document under CCS. +
++
+CAcert Official Document (COD). + Controlled Documents that are part of the CCS. +
+ + + + ++CAcert operates no repositories in the sense +of lookup for non-certificate-related information +for the general public. +
+ ++Under the Assurance Policy (COD13), +there are means for Members to search, retrieve +and verify certain data about themselves and others. +
+ ++CAcert publishes: +
+ ++CAcert does not expressly publish information on issued certificates. +However, due to the purpose of certificates, and the essential +public nature of Names and email addresses, all information within +certificates is presumed to be public and published, once +issued and delivered to the Member. +
+ ++Root and Intermediate Certificates and CRLs are +made available on issuance. +
+ +No stipulation.
+ + + + ++Client Certificates. +The Subscriber Naming consists of: +
++Individual Server Certificates. +The Subscriber Naming consists of: +
++Certificates for Organisations. +In addition to the above, the following applies: +
+ ++Except for the OU and CN, fields are taken from the Member's +account and are as verified by the Organisation Assurance process. +Other Subscriber information that is collected and/or retained +does not go into the certificate. +
+ ++Each Member's Name (CN= field) +is assured under the Assurance Policy (COD13) +or subsidiary policies (such as Organisation Assurance Policy). +Refer to those documents for meanings and variations. +
+ +
+Anonymous certificates have the same subject
+field common name.
+See §1.4.5..
+
+Email addresses are verified according to +§4.2.2. +
+ + + ++See §1.4.5. +
+ ++Interpretation of Names is controlled by the Assurance Policy, +is administered by means of the Member's account, +and is subject to change by the Arbitrator. +Changes to the interpretation by means of Arbitration +should be expected as fraud (e.g., phishing) +may move too quickly for policies to fully document rules. +
+ ++Uniqueness of Names within certificates is not guaranteed. +Each certificate has a unique serial number which maps +to a unique account, and thus maps to a unique Member. +See the Assurance Statement within Assurance Policy +(COD13). +
+ ++Domain names and email address +can only be registered to one Member. +
+ ++Organisation Assurance Policy +(COD11) +controls issues such as trademarks where applicable. +A trademark can be disputed by filing a dispute. +See +§9.13. +
+ ++Certificates containing International Domain Names, being those containing a +ACE prefix (RFC3490 +Section 5), will only be issued to domains satisfying one or more +of the following conditions: +
Email address containing International Domain Names in the domain portion of +the email address will also be required to satisfy one of the above conditions. +
+ ++The following is a list of accepted TLD Registrars: +
| .ac | +Registry | +Policy | +
| .ar | + +Registry | +Policy | +
| .at | +Registry | +Policy (character list) | + +
| .biz | +Registry | +Policy | +
| .br | +Registry | +Policy | +
| .cat | +Registry | + +Policy | +
| .ch | +Registry | +Policy | +
| .cl | +Registry | +Policy | +
| .cn | + +Registry | +Policy (JET Guidelines) | +
| .de | +Registry | + +Policy | +
| .dk | +Registry | +Policy | +
| .es | +Registry | +Policy | +
| .fi | + +Registry | +Policy | +
| .gr | +Registry | +Policy | + +
| .hu | +Registry | +Policy (section 2.1.2) | +
| .info | +Registry | +Policy | +
| .io | + +Registry | +Policy | +
| .ir | +Registry | +Policy | + +
| .is | +Registry | +Policy | +
| .jp | +Registry | +Policy | +
| .kr | +Registry | + +Policy (JET Guidelines) | +
| .li | +Registry | +Policy (managed by .ch registry) | + +
| .lt | +Registry | +Policy (character list) | + +
| .museum | +Registry | +Policy | +
| .no | +Registry | +Policy (section 4) | +
| .org | + +Registry | +Policy | +
| .pl | +Registry | +Policy | + +
| .pr | +Registry | +Policy | +
| .se | +Registry | +Policy (character list) | +
| .sh | +Registry | +Policy | +
| .th | +Registry | + +Policy | +
| .tm | +Registry | +Policy | +
| .tw | +Registry | +Policy (JET Guidelines) | +
| .vn | +Registry | +Policy (character list) | +
+This criteria will apply to the email address and server host name fields for all certificate types. +
+ ++The CAcert Inc. Board has the authority to decide to add or remove accepted TLD Registrars on this list. +
+ ++Identity verification is controlled by the + +Assurance Policy (COD13). +The reader is refered to the Assurance Policy, +the following is representative and brief only. +
+ + ++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, +SPKAC 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. +
+ ++Agreement. +An Internet user becomes a Member by agreeing to the +CAcert Community Agreement +(COD9) +and registering an account on the online website. +During the registration process Members are asked to +supply information about themselves: +
++The online account establishes the method of authentication +for all service requests such as certificates. +
+ ++Assurance. +Each Member is assured according to Assurance Policy +(COD13). +
+ + + + + ++Certificates. +Based on the total number of Assurance Points +that a Member (Name) has, the Member +can get different levels of certificates. +See §1.4.5. +See Table 3.2.b. +When Members have 50 or more points, they +become Assured Members and may then request +certificates that state their Assured Name(s). +
+ + +| Assurance Points | +Level | +Service | +Comments | +
|---|---|---|---|
| 0 | +Unassured Member | +Anonymous | +Certificates with no Name, under Class 1 Root. Limited to 6 months expiry. | +
| 1-49 | +Unassured Member | +Anonymous | +Certificates with no Name under Member SubRoot. Limited to 6 months expiry. | +
| 50-99 | +Assured Member | +Verified | +Certificates with Verified Name for S/MIME, web servers, "digital signing." + Expiry after 24 months is available. | +
| 100++ | +Assurer | +Code-signing | +Can create Code-signing certificates | +
+Verification of organisations is delegated by +the Assurance Policy to the +Organisation Assurance Policy +(COD11). +The reader is refered to the Organisation Assurance Policy, +the following is representative and brief only. +
+ ++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. +
+ ++Organisation Assurance achieves the standard +stated in the OAP, briefly presented here: +
+ ++All information in the certificate is verified, +see Relying Party Statement, §4.5.2. +
+ + ++The authorisation to obtain a certificate is established as follows: +
+ ++Addresses. +The member claims authority over a domain or email address +when adding the address, §4.1.2. +(Control is tested by means described in §4.2.2.) +
+ ++Individuals. +The authority to participate as a Member is established +by the CAcert Community Agreement +(COD9). +Assurances are requested by means of the signed CAP form. +
+ ++Organisations. +The authority for Organisation Assurance is established +in the COAP form, as signed by an authorised representative +of the organisation. +The authority for the +Organisation Administrator +(O-Admin) is also established on the +COAP form. +See Organisation Assurance Policy. +
+ + ++CAcert does not currently issue certificates to subordinate CAs +or other PKIs. +Other CAs may become Members, and are then subject to the +same reliance provisions as all Members. +
+ ++Via the Member's account. +
+ ++Via the Member's account. +In the event that the Member has lost the password, +or similar, the Member emails the support team who +either work through the lost-password questions +process or file a dispute. +
+ + + + ++The general life-cycle for a new certificate for an Individual Member is: + +
+(Some steps are not applicable, such as anonymous certificates.) +
+ + ++Members may submit certificate applications. +On issuance of certificates, Members become Subscribers. +
+ ++The Member can claim ownership or authorised control of +a domain or email address on the online system. +This is a necessary step towards issuing a certificate. +There are these controls: +
+Members generate their own key-pairs. +The CAcert Community Agreement +(COD9) +obliges the Member as responsible for security. +See CCA2.5, §9.6. +
+ ++The Certificate Signing Request (CSR) is prepared by the +Member for presentation to the automated system. +
+ ++The CA's certificate application process is completely automated. +Requests, 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. +
+ + + ++ The Member logs in to her account on the CAcert website + and thereby authenticates herself with username + and passphrase or with her CAcert client-side digital certificate. +
+ ++In principle, at least two controls are placed on each address. +
+ ++Email-Ping. +Email addresses are verified by means of an +Email-Ping test: +
+ ++Email Control. +Email addresses for client certificates are verified by passing the +following checks: +
++Domain Control. +Domains addresses for server certificates are verified by passing two of the +following checks: +
++Notes. +
+The Member has options available: +
+ ++For an individual client certificate, the following is required. +
+For a server certificate, the following is required: +
+Code-signing certificates are made available to Assurers only. +They are processed in a similar manner to client certificates. +
+ ++Organisation Domains are handled under the Organisation Assurance Policy +and the Organisation Handbook. +
+ ++Key Sizes. +Members 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 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. +
+ + ++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 following the process: +
+ +| Verified Name | +Unverified Name |
+ Empty Name |
+ |
| Verified email |
+ |||
| Unverified email | +|||
| Empty email |
+
+Once signed, the certificate is +made available via the Member's account, +and emailed to the Member. +It is also archived internally. +
+ ++There is no need for the Member to explicitly accept the certificate. +In case the Member does not accept the certificate, +the certificate has to be revoked and made again. +
+ ++CAcert does not currently 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 Member's options. +However note that certificates that are issued +and delivered to the Member are presumed to be +published. See §2.2. +
+ ++There are no external entities that are notified about issued certificates. +
+ ++All Members (subscribers and relying parties) +are obliged according to the +CAcert Community Agreement +(COD9) +See especially 2.3 through 2.5. +
++Subscribers should use keys only for their proper purpose, +as indicated by the certificate, or by wider agreement with +others. +
+ ++Relying parties (Members) may rely on the following. +
+ +|
+ + Relying Party Statement +
+ Certificates are issued to Members only. |
+The following notes are in addition to the Relying Party Statement, +and can be seen as limitations on it. +
+ ++The term Verification as used in the Relying Party Statement means one of +
+| Type | How | Authority | remarks | +
|---|---|---|---|
| Assurance | under CAcert Assurance Programme (CAP) | +Assurance Policy | +only information assured to 50 points under CAP is placed in the certificate | +
| Evaluation | under automated domain and email checks | +this CPS | +see §4.2.2 | +
| Controlled | programs or "profiles" that check the information within the CSR | +this CPS | +see §7.1 | +
+Members may rely. +Relying parties are Members, +and as such are bound by this CPS and the +CAcert Community Agreement +(COD9). +The licence and permission to rely is not assignable. +
+ ++Suppliers of Software. +CAcert roots may be distributed in software, +and those providers may +enter into agreement with CAcert by means of the +Third Party Vendor - Disclaimer and Licence +(wip). +This licence brings the supplier in to the Community +to the extent that ...WIP comment: +they agree to dispute resolution +within CAcert's forum. +
+ ++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. +For more details, see the +NRP - Disclaimer and Licence (COD4). +
+ ++Decision making. +Reliance means taking a decision that is in part or in whole +based on the information in the certificate. + +A Relying Party may incorporate +the information in the certificate, +and the implied information such as Membership, +into her decision-making. +In making a decision, +a Relying Party should also: +
+ ++Examining the Certificate. +A Relying Party must make her own decision in using +each certificate. She must examine the certificate, +a process called validation. +Certificate-related information includes, +but is not limited to: +
++Keeping Records. +Records should be kept, appropriate to the import of the decision. +The certificate should be preserved. +This should include sufficient +evidence to establish who the parties are +(especially, the certificate relied upon), +to establish the transaction in question, +and to establish the wider agreement that +defines the act. +
+ ++Wider Protocol. +In principle, reliance will be part of a wider protocol +(customary method in reaching and preserving agreement) +that presents and preserves sufficient of the evidence +for dispute resolution under CAcert's forum of Arbitration. +The protocol should be agreed amongst the parties, +and tuned to the needs. +This CPS does not define any such protocol. +In the absence of such a protocol, reliance will be weakened; +a dispute without sufficient evidence may be dismissed by an Arbitrator. +
+ ++As Compared to Usage. +Reliance goes beyond Usage. The latter is limited to +letting the software act as the total and only Validation +Authority. When relying, the Member also augments +the algorithmic processing of the software with her own +checks of the business, technical and certificate aspect. +
+ ++Roots and Naming. +Where the Class 1 root is used, +this Subscriber may be a new Member +including one with zero points. +Where the Name is not provided, +this indicates it is not available. +In these circumstances, +reliance is not defined, +and Relying parties should take more care. +See Table 4.5.2. +
+ +| + | ||||
| Class of Root | +(all Members) |
+ (Assured Members only) |
+ ||
1 |
+
+ Do not rely. + Relying party must use other methods to check. |
+
+ Do not rely.
+ Although the named Member has been Assured by CAcert,
+ reliance is not defined with Class 1 root. + (issued for compatibility only). |
+ ||
SubRoot |
+ ||||
3 |
+ + Do not rely on the Name (being available). + The Member has been Assured by CAcert, + but reliance is undefined. | ++ The Member named in the certificate has been Assured by CAcert. | +||
SubRoot |
+ ||||
+Software Agent. +When relying on a certificate, relying parties should +note that your software is responsible for the way it +shows you the information in a certificate. +If your software agent hides parts of the information, +your sole remedy may be to choose another software agent. +
+ ++Malware. +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. +
+ ++In the event that an issue arises out of the Member's reliance, +her sole avenue is to file dispute under DRP. +See §9.13. + +For this purpose, the certificate (and other evidence) should be preserved. +
+ ++Which person? +Members may install certificates for other individuals or in servers, +but the Member to whom the certificate is issued +remains the responsible person. +E.g., under Organisation Assurance, an organisation is issued +a certificate for the use by individuals +or servers within that organisation, +but the Organisation is the responsible person. +
+ + ++Software Agent. +If a Member is relying on a CAcert root embedded in +the software as supplied by a vendor, +the risks, liabilities and obligations of the Member +do not automatically transfer to the vendor. +
+ ++A certificate can be renewed at any time. +The procedure of certificate renewal is the same +as for the initial certificate issuance. +
+ ++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. +
+ ++Certificate "modifications" are not offered nor supported. +A new certificate has to be requested and issued instead. +
+ ++Certificates may be revoked under the following circumstances: +
+ ++These are the only three circumstances under which a +revocation occurs. +
+ ++As above. +
+ ++The Subscriber logs in to her online account through +the website at http://www.cacert.org/ . +
+ ++In any other event such as lost passwords or fraud, +a dispute should be filed +by email at + < support AT cacert DOT org > +
+ +No stipulation.
+ ++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 five business days, however the Arbitrator has discretion. +
+ ++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 certificate for the intended reliance. +
+ ++A new CRL is issued after every certificate revocation. +
+ ++The maximum latency between revocation and issuance of the CRL is 1 hour. +
+ ++OCSP is available at +http://ocsp.cacert.org/ . +
+ ++Relying parties must check up-to-date status before relying. +
+ ++None. +
+ ++Subscribers are obliged to revoke certificates at the earliest opportunity. +
+ ++Suspension of certificates is not available. +
+ ++Not applicable. +
+ ++Not applicable. +
+ ++Not applicable. +
+ + + ++OCSP is available +at http://ocsp.cacert.org/ . +
+ ++OCSP is made available on an experimental basis. +
+ ++No stipulation. +
+ ++Certificates include expiry dates. +
+ ++CAcert does not generate nor escrow subscriber keys. +
+ ++No stipulation. +
+ + + + ++Refer to Security Policy (COD8) +
+Refer to Security Policy 2.1.2 (COD8) +
++Refer to Security Policy 2.1.4 (COD8) +
++Refer to Security Policy 2.1.4 (COD8) +
++Refer to Security Policy 4.3 (COD8) +
++No stipulation. +
++Refer to Security Policy 4.3 (COD8) +
+ ++CAcert operates to the principles of four eyes and dual control. +All important roles require a minimum of two persons. +The people may be tasked to operate +with an additional person observing (four eyes), +or with two persons controlling (dual control). +
+ ++All important roles are generally required to be assured +at least to the level of Assurer, as per AP. +Refer to Assurance Policy (COD13). +
+ ++Technical. +Refer to Security Policy 9.1 (COD8). +
+ ++Roles strive in general for separation of duties, either along the lines of +four eyes principle or dual control. +
+ +| Role | Policy | Comments | +
| Assurer | +COD13 | ++ Passes Challenge, Assured to 100 points. + | +
| Organisation Assurer | +COD11 | ++ Trained and tested by two supervising OAs. + | +
| Technical | +SM => COD08 | ++ Teams responsible for testing. + | +
| Arbitrator | +COD7 | ++ Experienced Assurers. + | +
+Refer to Security Policy 9.1.3 (COD8). +
+ + +No stipulation.
+No stipulation.
+ +No stipulation.
+ ++Any actions that are questionable +- whether uncertain or grossly negligent - +may be filed as a dispute. +The Arbitrator has wide discretion in +ruling on loss of points, retraining, +or termination of access or status. +Refer to DRP. +
+ +No stipulation.
+ +No stipulation.
+ ++Refer to Security Policy 4.2, 5 (COD8). +
+ ++The standard retention period is 7 years. +Once archived, records can only be obtained and verified +by means of a filed dispute. +Following types of records are archived: +
+ +| Record | +Nature | +Exceptions | +Documentation | +
| Member | +username, primary and added addresses, security questions, Date of Birth | +resigned non-subscribers: 0 years. | +Security Policy and Privacy Policy | +
| Assurance | +CAP forms | +"at least 7 years." as per subsidiary policies |
+ Assurance Policy 4.5 | +
| Organisation Assurance | +COAP forms | +as per subsidiary policies | +Organisation Assurance Policy | +
| certificates and revocations | +for reliance | +7 years after termination | +this CPS | +
| critical roles | +background check worksheets | +under direct Arbitrator control | +Security Policy 9.1.3 | +
+Refer to Security Policy 9.2 (COD8). +
+ ++Refer to Security Policy 5, 6 (COD8). +(Refer to §1.4 for limitations to service.) +
+ + + +
+
+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 CAcert Inc. Board.
+
+
+In the event of operational termination, the +Roots (including SubRoots) +and all private Member information will be secured. +The Roots will be handed over to a responsible +party for the sole purpose of issuing revocations. +Member information will be securely destroyed. +
+ + ++The CA cannot be transferrred to another organisation. +
+ + +
+
+In the event of takeover,
+the Board will decide if it is in the interest
+of the Members to be converted to the
+new organisation.
+Members will be notified about the conversion
+and transfer of the Member information.
+Such takeover, conversion or transfer may involve termination
+of this CPS and other documents.
+See §9.10.2.
+Members 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. +
+ + + ++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. +
+ + + + + + ++Subscribers generate their own Key Pairs. +
+ ++There is no technical stipulation on how Subscribers generate +and keep safe their private keys, +however, CCA 2.5 provides for general security obligations. +See §9.6. +
+ ++Members login to their online account. +Public Keys are delivered by cut-and-pasting +them into the appropriate window, + +or through browser-specific CSR protocols. + +Public Keys are delivered in signed-CSR form +for X.509 and in self-signed form for OpenPGP. +
+ ++The CA root certificates are distributed by these means: +
+ +Third Party Vendor Agreement is early wip, only
+ ++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. +
+ ++No stipulation. +
+ ++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. +
+ + + + + ++SubRoot keys are stored on a single machine which acts +as a Cryptographic Module, or signing server. +It operates a single daemon for signing only. +The signing server has these security features: +
+ ++See §5. and the Security Policy 9.3.1. +
+ ++(Hardware-based, commercial and standards-based cryptographic +modules have been tried and tested, and similar have been tested, +but have been found wanting, e.g., for short key lengths and +power restrictions.) +
+ ++Subscriber certificates, including public keys, +are stored in the database backing the online system. +They are not made available in a public- or subscriber-accessible +archive, see §2. +They are backed-up by CAcert's normal backup procedure, +but their availability is a subscriber responsibility. +
+ ++The operational period of a certificate and its key pair +depends on the Assurance status of the Member, +see §1.4.5 and Assurance Policy (COD13). +
+ ++The CAcert (top-level) Root certificate +has a 30 year expiry. +SubRoots have 10 years, and are to be rolled over more quickly. +The keysize of the root certificates are chosen +in order to ensure an optimum security to CAcert +Members based on current recommendations from the +cryptographic community +and maximum limits in generally available software. +At time of writing this is 4096 bits. +
+ +No stipulation.
+ ++Refer to Security Policy. +
+ ++Refer to SM7 "Software Development". +
+ ++Refer to SM3.1 "Logical Security - Network". +
+ ++Each server synchronises with NTP. +No "timestamping" service is currently offered. +
+ ++CAcert defines all the meanings, semantics and profiles +applicable to issuance of certificates and signatures +in its policies, handbooks and other documents. +Meanings that may be written in external standards or documents +or found in wider conventions are not +incorporated, are not used by CAcert, and must not be implied +by the Member or the Non-related Person. +
+ +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. +
+ ++Client certificates include the following 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. +
+ + ++No stipulation. +
+ ++Refer to §3.1.1. +
+ ++Refer to §3.1.1. +
+ ++The following OIDs are defined and should be incorporated +into certificates: +
+ +| + OID + | ++ Type/Meaning + | ++ Comment + | +
| + 1.3.6.1.4.1.18506.4.4 + | ++ Certification Practice Statement + | ++ (this present document) + | +
+Versions are defined by additional numbers appended such as .1. +
+ ++No stipulation. +
+ ++No stipulation. +
+ ++No stipulation. +
+ + ++CRLs are created in X.509 v2 format. +
+ ++No extensions. +
+ ++The OCSP responder operates in Version 1. +
++No stipulation. +
+ + + + ++There are two major threads of assessment: +
+ ++See the Audit page at + +wiki.cacert.org/wiki/Audit/ +for more information. +
+ ++The first audits started in late 2005, +and since then, assessments have been an +ongoing task. +Even when completed, they are expected to +be permanent features. +
+ ++Systems Auditors. +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, IT management. +
+ + + ++Code Auditors. +See Security Policy, sections 7, 9.1. +
+ ++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 CAcert Inc. Board. +
+ ++Systems Audits are generally conducted to criteria. +CAcert requires that the criteria are open: +
+ ++See +DRC +for the current criteria. +If Auditor determines that a criteria fails to +follow the meet the above requirements, then the criteria +should be reworked to conform, or should be dropped +(both with explanatory notes). +
+ ++See the current +Audit Done list +for work completed, and +Audit Todo list +for work in progress. +
+ ++Auditor may issue directives instructing changes, +where essential to audit success or other extreme +situations. +Directives should be grounded on criteria, +on established minimum or safe practices, +or clearly described logic. +Adequate discussion with Community +(e.g., CAcert Inc. Board and with Policy Group) +should precede any directive. +They should be presented to the same standard +as the criteria, above. +
+ ++The + +wiki.cacert.org/wiki/AuditDirectives +documents issued directives and actions. +
+ ++Current and past Audit information is available at +wiki.CAcert.org/wiki/Audit/. +CAcert runs an open disclosure policy and +Audit is no exception. +
+ ++This CPS and other documents are subject to +the process in Policy on Policy (COD1). +Audits cover the overall processes more +than any one document, and documents may vary +even as Audit reports are delivered. +
+ + + + + ++The current fees structure is posted at +wiki.cacert.org/wiki/Price. +Changes to the fees structure will be announced +from time to time on the blog. +CAcert retains the right to charge fees for services. +All fees are non-refundable. +
+ + ++Financial risks are dealt with primarily by +the Dispute Resolution Policy +(COD7). +
+ ++No stipulation. +
+ ++No stipulation. +
+ ++No stipulation. +
+ ++CAcert has a policy of transparency and openness. +The default posture is that information is public +to the extent possible, +unless covered by specific policy provisions +(for example, passwords) +or rulings by Arbitrator. +
+ ++Privacy is covered by the +CCA (COD9) +and the Privacy Policy +(COD5). +
+ +No stipulation.
++Member's Date of Birth and "Lost Password" questions are treated as fully private. +
++To the extent that information is put into an issued certificate, +that information is not deemed private, +as it is expected to be published by the Member as part of routine use of +the certificate. +Such information generally includes +Names, domains, email addresses, and certificate serial numbers. +
++Under Assurance Policy +(COD13) +the Member's status (as Assured, Assurer, etc) is available +to other Members. +
++Information placed in forums outside the online system +(wiki, blogs, policies, etc) is not deemed private, and is +generally deemed to be published as contributions by Members. +See +CCA1.3 (COD9). +
++CAcert is a privacy organisation +and takes privacy more seriously. +Any privacy issue may be referred to dispute resolution. +
++Members are permitted to rely on certificates of other Members. +As a direct consequence of the general right to rely, +Members may read and store the certificates +and/or the information within them, where duly presented in +a relationship, and to the extent necessary for +the agreed relationship. +
++Any disclosure pursuant to process from foreign courts +(or similar) +is controlled by the Arbitrator. +
++None. +
+ ++CAcert is committed to the philosophy of +an open and free Internet, +broadly as encapsulated by open and free source. +However, due to the strict control provisions +imposed by the audit criteria (CCS), +and the general environment and role of CAs, +and the commitment to security of Members, +some deviations are necessary. +
+ + + ++Assets that fall under the control of CCS +must be transferred to CAcert. +See PoP 6.2 +(COD1), +CCA 1.3 +(COD9). +That is, CAcert is free to use, modify, +distribute, and otherwise conduct the business +of the CA as CAcert sees fit with the asset. +
+ ++The brand of CAcert +is made up of its logo, name, trademark, service marks, etc. +Use of the brand is strictly limited by the Board, +and permission is required. +See +m20070917.5. +
+ ++CAcert owns or requires full control over its documents, +especially those covered by CCS. +See PoP 6.2 +(COD1). +Contributors transfer the rights, +see CCA 1.3 +(COD9). +Contributors warrant that they have the right to transfer. +
+ ++Documents are generally licensed under free and open licence. +See + +wiki.cacert.org/wiki/PolicyDrafts/DocumentLicence. +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. +See PoP 6.4 +(COD1), +CCA 1.3 +(COD9). +
+ ++CAcert owns its code or requires full control over code in use +by means of a free and open licence. +See CCS. +
+ ++See the (new, wip) + +SourceCodeManifesto. +Maybe this can replace these two paras? +
+ ++CAcert licenses its code under GPL. +CAcert extends back to contributors a +non-exclusive, unrestricted perpetual +licence, permitting them to to re-use +their original work freely. +
+ ++CAcert asserts its intellectual property rights over certificates +issued to Members and over roots. +See CCA 4.4 +(COD9), +CCS. +The certificates may only be used by Members under +COD9, +and, +by others under the licences offered, +such as +Non-Related Persons - Disclaimer and Licence +(COD4). +
+ ++Members. +All Members of the Community agree to the +CAcert Community Agreement +(COD9), +which is the primary document for +representations and warranties. +Members include Subscribers, Relying Parties, +Registration Agents and the CA itself. +
+ ++RAs. +Registration Agents are obliged additionally by Assurance Policy, +especially 3.1, 4.1 +(COD13). +
+ ++CA. +The CA is obliged additionally by the CCS. +
+ ++Third Party Vendors. +Distributors of the roots are offered the +wip +3rd-Party Vendors - Disclaimer and Licence +(3PV-DaL => CODx) +and are offered +wip +the same deal as Members to the extent that they agree +to be Members in the Community. +wip +
+ ++Persons who have not accepted the above Agreements are offered the +Non-Related Persons - Disclaimer and Licence +(COD4). +Any representations and +warranties are strictly limited to nominal usage. +In essence, NRPs may USE but must not RELY. +
+ ++In today's aggressive fraud environment, +and within the context of CAcert as a community CA, +all parties should understand that CAcert +and its Subscribers, Assurers and other roles +provide service on a Best Efforts basis. +See §1.4. +CAcert seeks to provide an adequate minimum +level of quality in operations for its Members +without undue risks to NRPs. +See +Principles. +
+ ++CAcert on behalf of the Community and itself +makes no Warranty nor Guarantee nor promise +that the service or certificates are adequate +for the needs and circumstances. +
+ ++CAcert on behalf of related parties +(RAs, Subscribers, etc) and itself +disclaims all liability to NRPs +in their usage of CA's certificates. +See COD4. +
+ ++Liabilities between Members +are dealt with by internal dispute resolution, +which rules on liability and any limits. +See +§9.13. +
+ + ++No stipulation. +
+ ++No stipulation. +
+ ++Members file a dispute to terminate their agreement. +See §9.13 and CCA 3.3 +(COD9). +
+ ++Documents are varied (including terminated) under COD1. +
+ ++For termination of the CA, see §5.8.1. +
+ ++No stipulation. +
+ ++All participants are obliged to keep their listed +primary email addresses in good working order. +See CCA 3.5 +(COD9). +
+ + ++Amendments to the CPS are controlled by COD1. +Any changes in Member's Agreements are notified under CCA 3.4 +(COD9). +
+ ++CAcert provides a forum and facility for any Member +or other related party to file a dispute. +
+ ++Members agree to file all disputes through CAcert's +forum for dispute resolution. +The rules include specific provisions to assist +non-Members, etc, to file dispute in this forum. +
+ + ++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, +but this is unlikely because it may create results +that are at odds with the Community. +
+ ++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 "digital signing" certificates. +These applications may impose significant +obligations, risks and liabilities on the parties. +
+ ++See the Privacy Policy +(COD5). +
+ ++CAcert will provide information about +its Members 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 Policy +See +§9.13 +and +COD7. +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 +Members or not +(and are therefore subject to Dispute Resolution Policy). +
+ ++All Members of the Community agree to the +CAcert Community Agreement +(COD9). +This agreement also incorporates other key +documents, being this CPS, DRP and PP. +See CCA 4.2. +
+ ++The Configuration-Control Specification +is the set of policies that rule over the +Community, of which the above documents are part. +See COD2. +Documents that have reached full POLICY status +are located at + +www.cacert.org/policy/. +Although detailed practices may +be found in other places on the website +and on the wiki, the CCS documents that +have reached DRAFT and POLICY status are +the ruling documents. +
+ ++The rights within CCA may not be ordinarily assigned. +
+ ++No stipulation. +
+ ++The Arbitrator will specify fees and remedies, if any. +
+ ++No stipulation. +
+ +