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