diff --git a/CertificationPracticeStatement.html b/CertificationPracticeStatement.html index 561227d..60a43df 100755 --- a/CertificationPracticeStatement.html +++ b/CertificationPracticeStatement.html @@ -1,4028 +1,4142 @@ - - -
- --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. -
- --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. -
- --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. -
- --Pseudonymous 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 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. -
--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. -Certificates have been signed until 2004 with MD5, since 2005 SHA-1 or better algorithms are used. -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". -
- --The Signing Server receives the time through the serial link, but the synchronisation has to be done manually by a sysadmin. -All other servers synchronise with NTP or HTTPDATE. -CAcert might offer a Timestamping Service, or might approve an existing Timestamping Service. -
- - - - --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. -
- --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.1 - | -- 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. -
- --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 -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.
-
-2nd half of this section can be transfered over to PoP, only a reference to PoP 5.4 to remain (depends on p20130223)
-
-The rights within CCA may not be ordinarily assigned. -
- --No stipulation. -
- --The Arbitrator will specify fees and remedies, if any. -
- --No stipulation. -
- -
+
+
+
WARNING:
+ The proper policy document is located
+
+ on the CAcert website .
+
+ This document is a working draft to include
+ future revisions only, and is currently
+ only relevant for the [policy] group.
+ Suggested additions in BLUE, strikes in blue.
+
+ Michael Tänzer 20111113: CPS #7.1.2 "Certificate Extensions" adjustments
+ Ulrich Schroeter 20130309: several minor fixes according to PoP 2.5 and Bug #1131
+
Name: CAcert CPS and CP COD6 +Status: DRAFT p20091108, DRAFT p20111113 +Caveat: this document is already on the main website in DRAFT. p20111113. +Creation date: 20060726 +Changes: p20111113, 20130309 +Licence: CC-by-sa+DRP + |
+
+ ![]() |
+
+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 +Root Distribution License +(COD14). +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 + Root Distribution License (COD14). +
++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 +Root Distribution License (COD14). +
+ ++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. +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/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/AuditDirectives +documents issued directives and actions. +
+ ++Current and past Audit information is available at +wiki.CAcert.org/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/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/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 +Root Distribution License (COD14). + +
+ ++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 +Root Distribution License (COD14). + +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.
+
+2nd half of this section can be transfered over to PoP, only a reference to PoP 5.4 to remain (see Changes to PoP p20130223)
+
+The rights within CCA may not be ordinarily assigned. +
+ ++No stipulation. +
+ ++The Arbitrator will specify fees and remedies, if any. +
+ ++No stipulation. +
+ +