From a2b18ee737a1221d0169200b0af267980ad201f8 Mon Sep 17 00:00:00 2001
From: Philipp Dunkel
+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 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.
+
+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.
+
+ 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.CAcert CPS and CP
+
+
+Creation date: 20060726
+Status: DRAFT p20091108
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ 1. INTRODUCTION
+
+1.1. Overview
+
+1.2. Document name and identification
+
+
+
+
+
+
+
+
+
+ None is to be considered part of the policy,
+ and they should disappear in the DRAFT
+ and must disappear in the POLICY.
+
+ 1.3. PKI participants
+1.3.1. Certification authorities
+1.3.2. Registration authorities
+1.3.3. Subscribers
+
+1.3.4. Relying parties
+
+1.3.5. Other participants
+
+1.4. Certificate usage
+
+
+
+
+Table 1.4. Types of Certificate
+
+
+
+
+
+ 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
+ 1.4.1. Appropriate certificate uses
+
+
+
+
+1.4.2. Prohibited certificate uses
+
+
+1.4.3. Unreliable Applications
+
+
+
+
+
+1.4.4. Limited certificate uses
+
+1.4.5. Roots and Names
+
+
+
+
+
+
+
+
+Table 1.4.5.b Certificate under Audit Roots
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ 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.)
+
+
+
+Table 1.4.5. Certificates under Old Roots - Audit Fail
+
+
+
+
+
+
+
+
+
+
+
+
+
+ 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
+
+
+
+
+
+1.5. Policy administration
+
+1.5.1. Organization administering the document
+
+1.5.2. Contact person
+
+
+
+1.5.3. Person determining CPS suitability for the policy
+1.5.4. CPS approval procedures
+1.5.5 CPS updates
+
+1.6. Definitions and acronyms
+
+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. +
+ +`+evoFznJ( z=In+uuIgyl?t(g=%5
~~ftjmHi~zHA8gf%N`%pJl+&tzW%|`1axW=K(lxZ1=wO0^|h?p!FzX&4aM{*^aRz zYmohl;K*tSc5)L{U*RS^8OT}BfG7Q175kqCVA+#D1aSCMucEQC WDi5^eGk+Q ze<`Xref1`TromZv{@t>6CPfHA`y+wQZ6O44-6R~>iNp<{>sU|xLfCzAQ9-4cN1gZu z2%`tS?hn%J073{vw83r^-HsSGvpbJvATkGboTjE2QSt^tkHEoYh(Xg}_VY0Pp$?v^ zFA-AqyjD+gb>hL)d*qRTX-Vi|ELCV&mPAo($GvuE1uJ)yv;9adjiD$B!$cK=px4dd zybR77md8co22qd`v_S?sM{`4ls1-lpP{kyw;xAEkFvb__&nFlN)6|yWj*G`}-PAKM zEs2`klZy3Fy(zUC;d)s6C=}fev!3pmXT|++_jbrX+wQL~g}&q9)tS(G4AwpZGyW6y zFX@;QZG^2aLa&kC*BUyrYjzNAhBXU1cn+z2T5duZ+Ip_%~rEEXwzN(Y_ z=*3T2x2KAPVdB(OoSK57*q+2NEn*1+i6q_U=I&YJdH9AYNNFLGxg$uLtj}pv?%~O& zKgB)l0(R~m#qwom;Yo`U4eLxCS-|=yZc1tVw?fTT;L8DrC)FhZr0h@vA^5ho>rAD` z8hK@92}Q&Da^*S0x+sojSSFgH^7-ycu6cYh4WTIMJ{PK@U|JTTXo5ssM@kb#RS5W8 z_*_m-Hb?k$M;Q;_a2`UaNKC*&;2=YpLbZ|0kVzMEtS*CX#pB8CZ6c)$zuV33ijx!{ zuAyjXUKh(bm81kqN~Dy@4 N@yW%sM&o4o z-B?o67EPcif(yr-#^}>>$@OGXS<}X{?FTv3a2$uKlHm)WQ$q!J5@jE{OrYW=z+hy2 z06X?+y#LWfG&cKjyLH^II4-9}Bp&Cjb^9qAnnx%7>O$>WpbBxycvoH
QziEYUa}E#q2#ekk#u(vTJW44UGX*RbfSO zDG%K+8K2A54Pq&64N4d$n-3mmXW0oV>Y541bX*RNzFB_84C>8 zIIphW&DPRmG=^e!3{eD`0S^;~=5fa*;}|_KHwEC)`VhM->Tqf*R#H
Ut_qG*i$kox=QV%1<;?R@+RP*F`(_5;)!%qO7(F!?X}W*yF3pi{ tEoB!bfN+8OVEI9^=>dEG29R9xXMQ zl|7lcy=HNu9;W^3InuIsp$I4EPcG)7$u%^Go7r4Ef+Z^_vuj5$-g$TybI$FLX$jP% zpKmwC*H-Of(T7_&aIArN!bDMQ^ORB|kvLS9-Wfg?-F^|X&KiPYS|~#B>o-2<$qzQ8 z>n56}lF&^g5~rr(P!+;)oq)&5b9Y_L_2-WO;H6J?@Ppqi!58$9&`sP z%nLpye9a$;Zy3Y g z4Zr=%da^SE=&Fg+p)z4~9_fBJdn)QUT+>8ux{qi~=Z ;dkS4+8W&uiqaH{k?!v(r4<3;n4YqhcqBn6nm}8B_%K#N zCGFFB#0T!e8o!cv2i%D`as_j9=W=FXG!GO!!2ARAxqkQcD4N1+g|FF*qM!&58(ZA` zsPtB@?K2l)IXTd@lpAMP@Ys_VqPUy5?3{t*=lJj@uH?Q4G8r|dfy-vDW8$=jsaJGz z_&%m3&=i$Fe7J>0?{6kI%a4>0iR+~M-ORgS6vOkg3CDGc57n@$qyh{ZM1WN#<@|o} zW^%IvL=y&mGX1>q)7caa%>$q@6y^GbAF^g=1(^X4b Q>EdWzT_NTTf%)YAnln>Vplc9Yx>6;b6v?S5E!SI4?w1$=# zLX}va5NcT=!RkVO@?Z`djK$2|JqNeyW{7tP1?~b`^;Sl>N3f`R5p{YUha-pCAK6dT z2y=a}c|1JmLALG-gYOf(2+AvaVW}3EO(;Z4$=vhuc=}_5BUL#peEJ4_!76@pX9IUk z(b0s5`ql`4_+T@^fCtNx#C4P0G#?*5cr|DA&*>6?_Ew$bwx^b2nD!mTf34h!Oa`D( zG{GOQo|FO?AT!|M7uQT;RY^IfW#M%>*mUq1re(X2c2jS6Q@u0%Nx=MQs>0Fw5Cu7D z0KD__tEi}JVa(lsLI}_lL1QG&U6+pIwwYtP$f-r*hMlrV1?h?*RlyZmS8-RLYX})_ zY;P-OSKBUX6SV{!0d|CTpeY(zjx5Fp#&cWVZA?j@f?Ki8<^4_j3FaR~2bx1LFfW~H zqXz&`n4inI!F~B+PbJxz26fE=-dcJ(w@vn-DzJXvQI0pZk>+zl(&Qe$`E1VUpF={o z{cwA_c1A%CpDmn6TTCYs*V$cBhuf*4n-&3&lNH5B*i%uLtTsU)sA~xm@Hnw7i9=Ip z3CCy-$8cy$Do9Ess-m#?S92IYxDTh2B_#rZZgjtVGA%ouGfbKC#ag=0g_Sf71%-IR z gT-l^C%7#bGr9*9y{%^Zi}{)Aq^}`vSjl?zBgFK0VK>gmyI7pn%9G2 zT4<`mmFJw!>XHg{Lm}M<+sgJ)d}urqhUIbicw;gG+bNdc<7Dy~`B>5xxO2X2Nn7(W z{VK;ALNtYAsEUG=HhAx>+mB_KUDFdq!S8V*BqS?a4Abm#4k }}7T zJ7sO%$mW%)ajjpn+yzioK{%|lud;!$r{xhh6F5|r0(Sv(x6LIwI?DV$^D!&~RcJUA z4GR;?5@?FXXZy<7U)De(mVq0|fW8q{msB(3mv4|TB$}cSiY5qnotTylcsOSA?uPwL z7?wwCByJ0dZKh65CC%rulY6>W0*Vmm$;`pDB&L}>lmrVH&?^nML&It}eUU6&lFDQz ziw8}$wYLk%KwP)|t*R&;#mwJ8+Qeafd2!ixdtoVYs0x4nY%e!X8;K?~gcQulnM0aC zjpYq1xTW{4xK$S**i(6u;rZFAE4jDV??W0UN6PcjfKkJ%czMU^)V7AOEH#zix}6$^ zX<=Csugk%bO{F~k{b}^c@TXu@6hSnuQ`^)=es<7K@RQX*d*$U&?VWut2R^rha4dn- zsnQaP^7~t-bJaPg6E_STYDePVUL9(xz@=$;TpDrR=vGbsEueP$P!g2$M-L!BJ4jqN zu_Oe%PFC$KXVHgSQf65buc0j-W_WN2s-n;qOYp;ImvhH6%Wcz91of>^KG{}|I|$o% z4WhwPm^!HhMNJTjm_*__(S%MYn&4zhBy~`aQ{&L_CcfBH#l*tCXsUuGZ9f>*4Hj=a zh@yy;rnTSTsfu9xky^GLsv#rbrhiV5gkdJf6h7KqN}A6_Zkmq_zdQA02Ha!^J*4~G z6d$SiUxWB{ g#e{jx{vuY&Lq?p!=Wlzmc;LN^7Gf$aMyFo*;(4ieMjyG z#bAPY39qi$&6EdT=eZBIB=bW1vn}6tn2Nd(X?}}}>OL&}d@REUR 5sP35{V~+6`W`e z^TM+2O!@cM_;~AK6d{;1xsZ6mKmY-claIF^;nqbTbMR c9ZCO<~^MaDd78y~g~f zK1%iqPVqp0m0S)Lk5jX)3D8u9O$Ux50GGqgms=xoG|Q6QJG+S0JIh(Uy`0=kKZext zNH;HiaDbPi3rS2`OQ85N?tbYYHQ|$Zolb)3?Z3#{0KL2ZK=Oh_Ae1PpSKP#$^IN#+ z!lxL{<-oaJ1S}~#!H1g;;&P}2y-rqcFQc(7%9FQU$c$h9H_^C(&+R~%@Y6r7=Gmpi z^v_MhG%d<%o2hMTBW{|c`|VQs=INt&f8#+`?I
GeIBV2J@H@%86Wi5fvX5;$uV!~D{nSL*dB4}+2 z6N&2xVb|)P?XJY_&`21PSiFsM3&%5@)wJpT_}m;xh4~1&8OPAUFeO(^9EPr&Bn-Q5 zuWbnN=GwhX8BxHS_g_xX>*PdJTMFo-^{srqyOQ<$syW#b#-(XkZBZgII~ci~8h?4< zaxR%Lgu13Sn!_=CE+@KSva|dIt4qo$K3qe6YXpx|!!k^o+hTz2s!YQ|@AP~nz}SJ( z7~;JfU{?`wHI&*oFEhY3(?;;~t0$3{72x&NyI8lkikvhbPKS!u?c$*u&!%5i zKE1_!+-eT>%F8q;Z{Soi@hij0P4}{*xC~25{B9STrlOk`b0!xuqJIu^&mB(C>mri; zHAMod5I7ww9;br=z0$bu!qMC~Z6ujN4^o29?c} 83i&xf#tiDs z*uj0s>{N$0wZ+g)llGfeMF_Hj9_)mv<7dBSRuZR_Ty96;pg9~Pp_{1#NF>=oZz|gW zJ0Gq(*-A}g8{t?2O;hNV?qg8z4BXDH|NN4jd^$i)V;e_mnrMy0i5n(9mxHXJm%(`% zq fO3{SD!J`e-w?;5b3y;e|es+L9nSpOK|6lZX(Ek8L W>`$~$WD7I^0000