CCS is wip only. ✍

• wip is currently located at wiki CCS.
• Needs revising for newer R/L/O policies.

• Policies: CCS should refer to PoP.
• Certificates: CCS should refer to ???

• Refer to PoP for control of Policies.
• Security Manual might cover certificates. ✍

• CCA delegates control of all CAcert Official Documents (CODs) to Policy on Policy (PoP => COD1).
• Both PoP and CCS places themselves under PoP for document control purposes.
• PoP is part of CCS.
• CAcert Official Documents identifies CCS as COD2 and PoP as COD1.
• PoP is POLICY under its own regime. ✩

• CAcert Official Documents are on the main website policy page.
• Policy on Policy (PoP) was a serious change to policy procedure, and removed sustantial control from the board and passed it over to a policy group.
• The Board, the Association and the Policy Group have all separately approved PoP.
• CCS itself remains work-in-progress.

• CCS places CP/CPS under Policy on Policy (PoP => COD1).

• The CA writes all CP components into its CPS.
• CPS itself still work-in-progress.

• CCS places CPS under Policy on Policy (PoP => COD1).

• CPS itself still work-in-progress.

• CCS places Privacy Policy under Policy on Policy (PoP => COD1).

• Privacy Policy is approved but has a work-in-progress project to rewrite.

• CCS places Security Manual (SM => COD x) under Policy on Policy (PoP => COD1).

• SM itself exists only in skeleton form.

R/L/O are delegated by CCS to control under Policy on Policy (PoP => COD1).
• Risks, Liabilities, Obligations is covered by:
  • NRP-DaL speaks to non-related persons,
  • CCA controls members,
  • DRP controls disputes.
  • 3PV-DaL controls non-member distributors (work-in-progress).

• R/L/O are split across several documents, all of which are delegated by CCS to control under Policy on Policy (PoP => COD1).
Documents in the set are:
• CAcert Community Agreement (CCA => COD)
Non-Related Persons - Disclaimer and Licence (NRP-DaL => COD) Dispute Resolution Policy (DRP => COD) 3rd Party Vendors Agreement - Licence and Disclaimer (3PV-LaD work in progress)

• CPS, SM, PP should cover it.

• wip CCS includes section on software
• does software also fall into security manual? paw writes: Some aspects of software fall into the SM (sec 3.3). A different section name (currently, "Application") might make this more clear.

• wip CCS includes section on hardware
• does hardware also fall into security manual? CPS? paw writes: Hardware security is in the SM as section 2.2 (Physical assets)
• Recent NL hardware move were not addressed within context of CCS.
• Hardware sourcing not documented.

• wip CCS does not includes section on logging
• does logging also fall into security manual? paw writes: Logging is section 4.2 of the SM, and also appears in 4.4 ("Data retention")
• Logs: CP §5.4 (31 Dec 05) Certificates: CP §5.5 (31 Dec 05) Time-stamping: CP §5.5.5, §6.8 (DR 31 Dec 05)

• CPS
• 9.12 CCSx

• CPS1.4.1 describes purposes.
• CPS1.4.4 describes roots.

• 1.4.1 describes usage by certificate class.
• 4.5 describes relying party usage in terms of statement of reliance.

• Incorporate §A.2.b above.
• CPS1.4 (introduction) refers to general subscriber qualities.

1. size
2. algorithms
3. allowed lifetime
4. method of generation
5. purpose indicators (e.g., site, mail, file signing)
6. signing (by root or intermediate certificate)
7. representation of domains
8. ensuring uniqueness

1. CPS6.1.5 4.3.1
2. CPS4.3.1 6.1.5
3. CPS4.3.1
4. CPS4.3.1
5. CPS6.1.7 7.1.2
6. CPS1.4 website offers choice of Class 1 or Class 3
7. CPS3.1 as registered
8. CPS3.1 all domains are registered and tested

• Control over certificate generation is vested in a CSR parsing program. This is driven by a template system that manages the addition of new extensions and types and is subject to quality improvement. As CAcert operates a service oriented to free and experimental certificates, there is less emphasis on up-front technical documentation. A subscriber can simply roll a cert and inspect or test it.
• See CPS6.1
• CPS6.1.7 7.1.2 need to be rewritten, to include ServerAlternateName extensions

• CPS1.4.2 states prohibited uses.
• CPS1.4.3 states unreliable uses.
• CPS3.2.2 lists the relying party statements
• CPS4.5.2 describes reliance for different forms
• CPS7.1.2 lists the extensions that are used.
• CPS9.6-9 lists representations, warranties, disclaimers, indemnities
• CPS9.8.1 limits liability depending on roles.

• See §A.4.d.
• The major problem here is the immaturity of the relying party cycle. The relying party statement needs to be integrated all the way to the relying party herself - she must have a chance of reading and understanding it, in order to rely on it.
• 9.6-9 need lots of work.
• 6.1.7 ?
• 7.1.2 needs checking, rewriting.
• CPS3.2.3 should list the relying party statements for organisations, and unify with 3.2.2.

• CPS1.3.2-3 definitions
• CPS3.2 describes process of Assurance
• CPS4.1.1 who may be a Subscriber

• 3.2.3 needs integration, completion?
• 5.1?

• CPS3.1.5 on uniqueness of names
• CPS3.2.5 general requirement
• CPS4.2.2 method of validation
• CPS4.2.3 validation for email certs

• AD2.1 refers.
• In light of §A.2.i, §A.2.q, verification needs to expand beyond the addition of domain event.

• CPS3.1.5 on uniqueness of names
• CPS3.2.5 general requirement
• CPS4.2.2 method of validation
• CPS4.2.4 validation for server certs

• AD2.1 refers.
• In light of §A.2.i, §A.2.q, verification needs to expand beyond the addition of domain event.
• provision is only done on enabling, not on issuance in CPS4.2.2-4.

• The certificate expires not later than the domain's renewal date.
  
  or else
• The domain's registration data is recorded; and the renewal of registration is verified by the CA not later than the recorded renewal date, with renewal registration data then recorded.

• None of this is done.

• AD3.1. refers.
• It is technically difficult to acquire this information, this is a "known hard problem."
• See §A.2.q.
• CPS4.2

• CPS1.4.2 describes Assurance points.
• CPS4.2.5 states manual procedure.

• what does this mean? ping DR.
• Code-signing is essentially a manual procedure.
• Document signing is mentioned, but is generally excluded as a suitable application in CPS1.4.2.

• CPS3.2 identification methods are described.
• This area deferred to Assurance Policy.
• RAs reach suitable "direct" standards by means of the Assurance Handbook, training and the Assurer Challenge (test).

• Pending approval of Assurance Policy.
• As the CA uses one primary method, there is little possibility of confusion.
• Secondary methods of assurance (TTP, etc) do not change the picture sufficiently.
• Whether the Assurance process of the CA is direct or "Web of Trust" depends strongly on definitions. This criteria possibly assumes that the term "Web of Trust" and direct alternates are possible exclusives.
• In practice CAcert uses a hybrid scheme which uses elements of "Web of Trust" to supplement direct methods. As the methods involve face-to-face meetings and document verification by RAs, these are direct. A "Web of Trust" analogue is provided in the appointment procedures for RAs by the same process, but that serves to augment not separate the methods.

• site authentication and encryption
• E-mail signing and encryption
• file authentication (e.g., code-file signing)

• CPS4.2

extrasearch: email

• Organisation Assurance Policy (OAP => COD11) rules this area.
• CPS3.2.3 refers process to OAP.
• OAP directs specific environments ("countries") by Subsidiary Policy. These are not universally written nor approved as yet, but where not, no assurance is accepted.
• CPS3.1.1 describes x.509 naming attributes
• CPS3.1.6 trademarks

• Organisation Assurance Policy is now full POLICY.
• Various Subsidiary Policies for different countries are in progress or DRAFT.
• The organisation assurance process is based (a) on two or more Assurers taking responsible for the organisation's relationship, one inside and one outside, and (b) a package of documentation and other indicators that is prepared by the insider and checked by the outsider.
• Both Assurers sign off on the application.
• CAcert makes no distinction between commercial and non-commercial. All are members to CAcert and therefore "within jurisdiction."
• Review in this area is a lower priority than individual assurance and Assurers. Or at least, there is a heavy dependency on the assurance process. External parties may feel that "commercial" certificates are more sensitive, but R/L/O has substantially controlled that issue.
• See §A.2.x.

• CPS3.1.1 describes x.509 naming attributes
• CPS3.1.2 states no current requirement
• CPS3.1.4 reserves right to impose rules
• CPS3.2 IDNs are a high-level Assurance option.

• AD3.2 refers.
• Spoofing is not explicitly covered.
• The introduction of a "current threat" opens up the wider aspects of dealing with all current threats, which is how it is treated in this audit.
• The particular issue of IDNs is covered by the requirement for high-level Assurance.

• CPS4.2.1 User to be logged in.
• CPS4.9 Full Process.

• Primarily done through website interface.

• CPS4.5.1 Obliged to revoke on compromise.
• CPS4.9.1 Authorised to revoke.
• CPS4.9.2 Mechanism for revoking.
• CPS5.4,5.5.1 Recorded in audit log, archives.

• CPS4.5.2,4.9.6 Relying parties to check revocation recorded in CRL.

• The registration of the domain for a subscribers site certificate expires without renewal.
• The registration of the domain for a subscribers site certificate indicates a change in ownership or other control of the registration of the domain.
• E-mail to a subscribers last known E-mail address indicates the address is no longer functional.

• Dispute resolution is in place.

• Three different situations are described.
• They require technical issues to be resolved.
• They are not described in CPS, and form no part of the current procedures.
• Dispute resolution would more readily form a defence.
• Dispute resolution is not reviewed in CPS.
• #2 could be addressed in a member-to-member protocol for domain transference, but is problematic otherwise.
• Domains need to be more regularly / more pointedly checked for control, e.g., on cert issuance.
• AD3.1 refers.
• See §A.2.i.
• Extrasearchterm: email.

• Not applicable.

• Suspension not supported or offered.
• CPS4.9.13-16.

• No differences.

• CA only offers one form of certificate issuance, which covers all these variants.
• CPS4.6-9.

• intended lifetime
• how revocation is authorized and processed
• notification to subscribers and the general public of revocation
• how the generation of a new root certificate is authorized and processed
• notification to subscribers and the general public of a new root certificate

• CPS6.3.2 describes lifetime.
• CPS5.6 describes by whom. Method refers to SM.
• CPS5.7.3 refers to SM.
• CPS5.6 ditto.
• CPS5.7.3 refers to SM.

• This area needs to be split up between the CPS, the CCS, and the security manual.
• SM should describe process for revocation, creation of new root and advise to public of both? paw writes: SM section 7 ("Administrative") is probably where much of the standard root certificate creation/revocation/announcement procedures should go [just added]. Section 5 ("Incident Response") might want to contain emergency procedures for this.
• WT20 speaks to distribution.
• WT33 speaks to user cert revocation.
• Also see 6.1.4 6.2 ?

• intended lifetimes
• how revocation is authorized and processed
• notification to subscribers and the general public of revocation
• how the generation of a replacement intermediate certificate is authorized and processed
• notification to subscribers and the general public of a new replacement intermediate certificate

• As for &A.2.t.

• §A.2.u is a duplicate of §A.2.t

• RAs are termed "Assurers".
• System has a number of exceptions which defy easy description

• AD2.2 refers.
• The current standard is points only.
• new CATS system for training RAs is in early roll-out phase.
• This area is now deferred by CPS to Assurance Policy, which is wip.

• Verification is called Assurance.
• Assurance is documented and defined in Assurance Policy (wip)
• Assurance is documented in CPS3.2 which should refer to AP.

• Primary policy is Assurance Policy which should include an Assurance Statement.
• (Assurance) Handbook describes implementation to AP.
• CPS3.2

• See Organisation Assurance Policy.

• Organisation Assurance Policy specifies local details in Subsidiary Policies.
• Organisation Assurers have additional local training.
• An additional representative is the internal Organisational Administrator.
• AD4.2 refers.
• See §A.2.m.
• See CPS3.2 for Assurance and CPS3.2.3 for Organisation Assurance.

• revoking root and intermediate certificates
• notifying subscribers and the public
• providing for automated tools that detect revoked certificates (cf §B.2.k)
• ensuring private information about subscribers remains protected
• ensuring security of subscribers private keys until subscriber certificates can be revoked

• CPS5.8.1 root secured for future revocations. AD2.3 refers.
• CPS5.8.1
• CPS5.8.1 AD2.3 refers.
• CPS5.8.1
• (no subscriber private keys are held by CA)

• Note that CA plans to secure root(s) for future revocations, not to revoke them immediately.
• (CPS9.10 deals with document status only.)

• CCS not published as yet.
• CPS has been rewritten, not approved as yet. See §A.3.j.

• Dispute Resolution Policy covers this area.
• CPS should refer.
• CCA establishes Arbitration as dispute resolution forum.

• Dispute Resolution Policy has been written, approved, implemented
• Some cases have moved through the DRP.
• DRP is a controlled as a POLICY, and is thus a CCS-controlled document.
• CPS needs to be updated to refer to it. 9.2 9.6-9 9.13 9.14
• There is no necessary referral of disputes with public to DPR, although the forum is offered for this purpose.

• It is difficult to predict this non-routine issue, and it is best left broad and controlled by the board.
• Indeed, although there are comments in the CPS about the potential for merger, two attempts have been seen and squashed.
• WT40. 5.8.1

• Privacy lacking.
• Arbitration lacking.

• Applicable law is described for most circumstances.
• There was an exception which was not well thought out. In the old cps, parties could choose local law. Under DRP, Arbitrator may select.
• PP describes Privacy Laws. §A.4.e
• Dispute Resolution should describe AU Arbitration law. Check wiki to see if it is representative.

• CCA 2.3 assurance and information obligations
• CCA 2.5 security obligations
• CCA 3.2 dispute obligations

• Obligations of Subscribers are primarily covered in CCA, and CPS defers to that document.
• See also §A.6 and WT14
• Still some work being done on Assurance Statement (wip in AP) and Relying Party Statement but these are advanced and seem unlikely to upset the obligations to Subscribers.
• CPS4.5.1 describes the context of the relying party
• CPS9.6.1 refers to CCA

• §B.2.l

• AC1.
• CPS9.1
• §B.2.l also covers this and therefore conflicts.

• AC1.
• CPS9.1

• AC1.
• CPS9.1

• AC1.
• CPS9.1.5

• CP, CPS, privacy policy, configuration-control specification, and declarations of risks and liability
• Root and intermediate certificates
• CA-generated subscriber certificates
• Lists of current and revoked certificates
• Software tools used in the CA's operations
• CRLs, OCSP data, or the equivalent (see §B.2.k)
• The CA's Web site

• The use of CCS documents that carry others' control by means of copyright was a clear conflict with CCS. Ref §A.3.a. CPS was re-written to re-incorporate under copyright CAcert.
• AC2.
• Rights exist and are asserted in user agreements.
• Any other auditing interest in IP is hard to identify, c.f. AS.23.
• CPS9.5

• AC2.
• CPS9.13
• DRP provides forum.

• the creation and securing of backup copies of root, intermediate, and subscriber certificates
• the creation and securing of backup copies of information used to authenticate subscriber identities
• the rehosting of CA servers
• informing subscribers and the general public of interruptions
• the replacement of authorized personnel and the hand-over of their knowledge of pass-phrases

• CPS5.7.3
• ?
• CPS5.7.4
• ?
• ?

• Inadequate.
• The entire section depends on the SM.
• CPS5.7 CPS5.7.3 CPS5.7.4.

• Privacy Policy (PP) lacks numbers. Herein implied.
• See also: CPS2 (Repositories), CPS3.1.3, CPS5, CPS5.3.2 (Background checks) CPS5.8 (RA documents). CPS9.6.3 (Representations and Warranties).
• OCSP is not mentioned.
• WT41.1, 41.4, 41.7 missing.

• CPS1.4 covers nyms.
• CPS5.5
• PP.1
• PP.2 DR may override.

• CPS9.4 refers to PP.
• PP says no information made public by default.
• DR may override.

• PP.2,9 refers to dispute resolution.

• PP needs to be rewritten to align with new policies.
• See §A.6 for definitional interpretations.
• CPS4.5.2 defines RELIANCE.
• Collection of acceptance of CCA is a work in progress. See §A.4.d and §B.2.e on access to the acceptance.

• See note §A.5.h on what "legal mandates" refers to.
• PP should describe applicable laws. CPS9.15.2 §A.3.d.

• PP should refer to DR and CPS9.13
• PP should refer to Privacy Laws

• SM is a work in progress.
• Security Handbook is dropped.

• See comments §A.5.a.
• CCS also wip.

• See comments §A.5.a.
• Refer to Oophaga manual.

• safe combinations
• cipher lock combinations
• computer access passwords
• hardware encryption keys
• configuration-control logs and records (see §A.1.k)

• See comments §A.5.a.
• CPS5.3

• personnel restrictions on access to cryptographic hardware
• logging access to secure containers
• frequency of changing combinations, cipher locks, etc

• See comments §A.5.a.
• Some of this is touched in CPS5.1

• See comments §A.5.a.
• Parts are / may be described in the CCS.

• See comments §A.5.a.
• CPS states it is, only.

• See comments §A.5.a.
• David Ross clarifies:
  "In both cases, "legal mandates" refers to statutory laws that require personal data to be kept private, that mandate disclosure of such data, or that make privacy and disclosure a business decision by the CA."

• compromised private keys for root or intermediate certificates
• theft of private data provided by subscribers

• Some of point 1 is described in the CPS. See CPS5.7

• Non-Related Persons: NRP-DaL bans reliance by NRPs.
• Members: Risks are enumerated in CCA.
• CPS1.4 covers the limitations of purpose.
• CPS4.5.2 covers statement of reliance.

• CAcert uses term "Non-Related Persons" to describe end-users who are not related to the CA. They have permission to USE but not RELY.
• CAcert uses the term Members to describe parties to CCA (who have permission to USE, RELY, OFFER).
• Principles suggests that Community does not act to detriment of NRPs.
• Major risks to NRPs would include (a) inappropriate reliance (covered by NRP-DaL), and (b) non-avoidable risks/liabilities e.g., gross negligence.
• Major risks to Members would include (a) inappropriate disclosure of risks (itself covered by DRP) and (b) failure of NRP-DAL plus DRP against NRPs.
• See §A.3.e. Obligations of subscribers.
  §B.2.c. Statement is published.
• David Ross's additional comments: My requirement A.6.a means that the CA should state that end users must be realistic in their expectations. If a subscriber meets the CA's criteria for obtaining a site certificate and is then bought out by another party who then uses the site certificate to commit fraud, end users might have to look to the subscriber (and possibly the police) and not the CA for redress. The statement for A.6.a should indicate, for example, what are the general risks to end users who rely on SSL, site certificates, and the integrity of the owners of site certificates. It might also state that the CA is limited in how it controls what happens after a subscriber certificate is issued and that the CA does not daily monitor the subscriber's overall operations and activities. This requirement is NOT a statement of liability; it instead describes the environment in which certificates are used, the limits of that use, and even how they are misused.

• Non-Related Persons: NRP-DaL disclaims liabilities to NRPs.
• Users: Liabilities are enumerated in CCA2.1-2 Total monetary liability is limited to €1000.
• Civil liabilities are controlled by DRP

• For liability, there are two groups, being those within jurisdiction of the internal dispute resolution forum, and those without.
• CCA asserts jurisdiction under Arbitration Act and refers disputes to internal Arbitration. Arbitration allocates liability within community, including to/from CAcert.
• A list of potential remedies (thus liabilities) is available to the Arbitrator, applicable broadly to the parties, DRP 3.6
• Liability outside jurisdiction is disclaimed. This assumes promulgation and consistency.
• CPS9.8 Limitations of Liability
• See §B.2.d. Statement is published.
• David Ross's additional comments: Requirement A.6.b might mean that the CA assumes little liability. This would be especially true for anything happening before the CA is informed that a subscriber is acting improperly. However, it should mean that the CA assumes legal responsibility for verifying the identity of a subscriber and might include responsibility for verifying that, at the time a subscriber certificate is issued, the subscriber is operating a legitimate business.
• DR point above would seem to reduce to the relying party statement which is currently lacking.

• Non-Related Persons: NRP-DaL disclaims liabilities to NRPs.
• Users: Liabilities are enumerated in CCA2.1-2. Total monetary liability is limited to €1000.
• Civil liabilities are controlled by DRP.

• Ditto comments §A.6.b
• Subscribers are Members and have no special liabilities treatment.
• David Ross's additional comments: I would anticipate that requirement A.6.c would mean that the subscriber must explicitly assume responsibility for its own actions, including liability to end users. This leads to requirement A.6.d, in which a CA would get certification from its subscribers that they understand and accept A.6.c. (A prudent CA would get this in writing from its subscribers even without this requirement.) Then, a subscriber sued by an end user because of the subscriber's actions (or even by an end user who was personally negligent) would be inhibited from suing the CA and driving it out of business.

• CCA1.1 specifies list of places where agreement is required.

• CCA is approved as 'POLICY'.
• None of the places for securing agreement CCA1.1 are implemented. Not in systems nor procedures.
• For "written acceptance" on paper, then this will be found on future CAP form with Assurer and Member signatures.
• Strength of acceptance of dispute resolution is the major test of the spirit behind this criteria.
• It should be the task of a future audit to check the breadth, depth and consistency of the questions of acceptance of liability & DR.
• See §A.4.d and §B.2.e; on access to the acceptance. See CPS5.4.

• Privacy Policy

• A revision is required.

• Interpreted as the CCS, but not entirely sure. Should query DR.
• CCS is only WIP status, and requires review.

• Defer to § B.2.b

• CP is absorbed into CPS.

• WIP status CPS
• Is being rewritten for DRCA

• CCA, DRP, NRP-DaL are published under http://www.cacart.org/policy/

• CCA, DRP, NRP-DaL are approved as 'POLICY'.
• All such policies are published under http://www.cacart.org/policy/
• Currently, the policies (especially the CCA) are not promulgated widely, so their effectiveness remains to be established.

• Ditto §B.2.c

• Ditto §B.2.c

• Incorporate assertions from §B.2.c

• Incorporate comments from §B.2.c
• Effectiveness of this criteria is limited by whether the statement itself is available.
• The statements of Members are not currently collected, so can not be available. See §A.6.d.
• Procedure and authority is covered by §B.2.f.

• Incorporate assertions from §B.2.c.
• DRP provides the authority and procedure to control access to all data under dispute.

• Incorporate comments from §B.2.c
• Access to statement is via Dispute Resolution. The mechanism exists, is approved (DRP), controlled, and is observed to work.
• Such as it is: §A.6.d provides content.

• E-mail
• postal
• phone

• email to supportat.
• WebPost on website
• IRC and secure IRC
• postal to PObox in Sydney Australia.

• CA does not offer telephone support
• IRC and support are monitored on a volunteer basis.
• What should also be listed in the criteria is legal service. (DRP says that disputes can be filed to supportat email.)

• name of certificate subscriber
• certificate domain
• certificate type
• certificate user ID
• certificate key ID
• certificate fingerprints
• issue date
• expiration date

• CA does not conform to this criteria.
• CA has explained why this is not done to a satisfactory level.
• Therefore accepted.

• Certificates and/or their contents are not made available by the CA by policy. Privacy is considered more important than any reasons to make the the information available.
• FWIW, Non-publication is in line with industry practice for commercial CAs.
• See comments by Dutch Data Protection Authority on privacy implications
• It is unclear what (public?) purpose is served by making cert info publically available in an organised fashion. Possibly, fraud protection by encouraging domain owners to scan for their domain?
• There is an expectation that certs are public, perhaps from their name "public key".
• Some information is sometimes deemed public in mandates: name and email address. What is not deemed public is numbers and similar.
• In contrast, there are costs in declaring this info private. Declared as private means that the info has to be protected, which creates costs for the CA, and costs for the users. Which may impact on privacy. Certificates by their nature encourage publication of info, so this may create an uneconomic burden for some illusory benefit.
• Domains information is not made available.
• email sent to DR 2006.05.24.

• updated on the list of subscriber certificates to indicate expiration
  
  or
• is moved to a list of expired certificates

Accepted.
• See B.2.h for motives.

• Only revocations are distributed.
• Implication is that these lists should be public (error in criteria?), but privacy overrules publication, see §B.2.h
• See CPS2

• Revocation list includes reason codes.
• The revocation info does not include info above.

• crl.cacert.org and ocsp.cacert.org provide CRLs
• ocsp.cacert.org provides OCSP (soon).

• CRLs are distributed.
• OCSP is a work in progress, not online as of 20080106.

• On wiki at wiki.cacert.org/wiki/Price
• DRP gives authority to raise fees on dispute filing, although default of zero still applies.
• Wiki documentation is not formal and can be changed without control. However, the price is currently zero for most services.
• This criteria not examined closely as its role seems strained within the audit ambit.
• For both above two reasons, criteria deemed accepted.
• Criteria Conflict: A.3.f also covers fees and requires them in CPS. Fees should be left out of CPS as fees are business oriented. This present criteria is taken as dominating over A.3.f.

• CPS5.7 needs to be rewritten.
• Is the CPS the place for this policy? Should possibly be in the Security Manual. paw writes: SM Section 5 ("Incident handling")
• Criteria can be seen as conformance and/or policy. §C.2 should have a conformance criteria.

• as per B.2.m.

• Change log is not made public.
• Is there some security reasons for not doing this?
• Refer to DRC author.
• Non-public wiki.cacert.org/ChangeLog

• CPS8 specifies policy to publish immediately on signoff.
• Slight recursive problem here. Checklist can only indicate where it might be found, and where others have been checked to be found. Attestation can only apply to prior results, such as audits, reports, potentially including this checklist if already published.
• This clause interpreted to mean (a) policy of publishing this audit, and (b) record of publishing prior audits.
• Intent could be met via open governance, as per this website.

• being infected by computer viruses and other "malware"
• distributing computer viruses and other "malware"

• Note from primary DRC-C.4: "For the purpose of this Section C, second-party intermediate certificates of other CAs issued and signed by the CA under review and used to sign subscribers certificates issued by those second-party CAs are treated as subscriber certificates issued by the CA under review."

extrasearchterm: email

• the individual's identity
• the individual's authorization to request a signature on the certificate