A.1.a |
A configuration-control specification exists.
|
✘
|
- wip is currently located at
wiki CCS.
- Needs revising for newer R/L/O policies.
|
WT3 WT39 |
A.1.b |
The configuration-control specification
provides for tracking versions of
controlled specifications and certificates.
|
-
Policies:
CCS
should refer to
PoP.
-
Certificates:
CCS
should refer to ???
✘
|
- Refer to PoP for control of Policies.
- Security Manual might cover certificates. ✍
|
WT39 |
A.1.c |
The configuration-control specification
controls its own revision process.
|
-
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.
|
WT39 |
A.1.d |
The configuration-control specification
controls the revision process for the
certificate policy (CP, see §A.2).
|
-
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.
|
WT39 |
A.1.e |
The configuration-control specification
controls the revision process for the
certification practice statement
(CPS, see §A.3).
|
-
CCS places CPS under Policy on Policy (PoP => COD1).
✔
|
-
CPS itself still work-in-progress.
|
WT39 |
A.1.f |
The configuration-control specification
controls the revision process for the
subscriber privacy policy (see §A.4).
|
-
CCS places Privacy Policy under Policy on Policy (PoP => COD1).
✔
|
-
Privacy Policy is approved but has a
work-in-progress project to rewrite.
|
WT39 |
A.1.g |
The configuration-control specification
controls the revision process for the
security manual (see §A.5).
|
-
CCS places Security Manual (SM => COD x)
under Policy on Policy (PoP => COD1).
✔
|
-
SM itself exists only in skeleton form.
|
WT39 |
A.1.h |
The configuration-control specification
controls the revision process for the
declarations of risks and liability (see
§A.6).
|
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)
|
WT39 |
A.1.i |
The configuration-control specification
controls changes to software involved in:
generating, signing, distributing, and
otherwise handling certificates
collecting and storing subscriber
information
communicating with subscribers and
with the general public.
|
-
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.
|
WT39 |
A.1.j |
The configuration-control specification
controls changes to hardware involved in:
generating, signing, distributing, and
otherwise handling certificates
collecting and storing subscriber
information
communicating with subscribers and
with the general public.
|
✘
|
-
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.
|
WT39 |
A.1.k |
The configuration-control specification
describes the maintenance and archiving
of logs and records of controlled changes
to certificates, software, hardware, and
documents.
|
✘
|
-
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)
|
WT39 |
A.2.a |
The CP is maintained in accord with the
configuration control specification.
|
✘
|
|
WT3 |
A.2.b |
The CP clearly specifies each class of issued certificate.
|
- CPS1.4.1 describes purposes.
- CPS1.4.4 describes roots.
✔
|
CPS4.5 describes usage.
|
WT1 WT2 |
A.2.c |
For each class of certificate,
the CP identifies the subscriber population
in terms of expected certificate use.
|
-
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.
|
WT2 WT10 WT22 |
A.2.d |
For each class of certificate, the CA
provides technical details of certificate
generation:
- size
- algorithms
- allowed lifetime
- method of generation
- purpose indicators (e.g., site, mail, file signing)
- signing (by root or intermediate certificate)
- representation of domains
- ensuring uniqueness
|
- CPS6.1.5 4.3.1
- CPS4.3.1 6.1.5
- CPS4.3.1
- CPS4.3.1
- CPS6.1.7 7.1.2
- CPS1.4 website offers choice of Class 1 or Class 3
- CPS3.1 as registered
- 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
|
WT17 WT22 WT30 (WT36) |
A.2.e |
The CP states any limitations imposed on
the use of each class of issued certificates.
|
-
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.
|
WT10 |
A.2.f |
The CP clearly describes how the identity
of each certificate subscriber is verified.
|
-
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?
|
WT25 |
A.2.g |
The CP clearly describes how the
relationship of each subscriber for an
E-mail certificate to the E-mail address is
verified.
|
-
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.
|
WT25 |
A.2.h |
For a site certificate, the CP clearly
describes how the relationship of the
subscriber to the domain is verified,
including a provision that a site certificate
cannot be issued to a subscriber who does
not own or otherwise control the
registration of the affected domain.
|
-
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.
|
WT25 |
A.2.i |
For a subscriber's site certificate, the CP
provides either:
-
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.
|
✘
|
-
AD3.1. refers.
-
It is technically difficult to acquire this information,
this is a "known hard problem."
-
See §A.2.q.
-
CPS4.2
|
None |
A.2.j |
For a subscriber certificate to be used for
authenticating files (e.g., code-signing
certificates), the CP clearly describes how
the relationship of the subscriber to the
organization identified within the
certificate is verified.
|
-
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.
|
iWT25 |
A.2.k |
If the CP indicates that both direct and
indirect (e.g., Web of Trust) methods are
used to verify the relationship of the
subscriber to the requested certificate
(per §A.2.g, §A.2.h, or §A.2.j),
the CP must
also indicate how a user relying on the
certificate can determine which method
was used.
|
-
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.
|
None |
A.2.l |
If the CA issues or signs subscriber
certificates for more than one of the
following purposes, the CP specifies that
requirements cited in this checklist for
each purpose shall be satisfied:
- site authentication and encryption
- E-mail signing and encryption
- file authentication (e.g., code-file signing)
|
✔
|
extrasearch: email
|
None |
A.2.m |
For a commercial certificate subscriber,
the CP clearly describes how the existence
of an actual business entity is verified,
including verifying that the entity is
licensed or otherwise permitted to operate
where it is located.
|
-
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.
|
WT25 |
A.2.n |
The CP clearly describes how a certificate
domain is identified, including addressing
how fraud based on homographic
spoofing of internationalized domain
names (IDNs) is avoided.
|
-
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.
|
WT25 |
A.2.o |
The CP clearly describes how a subscriber
may request its certificate to be revoked.
|
-
CPS4.2.1 User to be logged in.
-
CPS4.9 Full Process.
✘
|
-
Primarily done through website interface.
|
WT33 |
A.2.p |
The CP details the process of revoking a
subscriber certificate or the CA's signature
thereon, including which personnel are
authorized to perform that action and what
records are made of that performance.
|
-
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.
|
WT33 |
A.2.q |
The CP clearly describes situations in
which CA shall revoke a subscribers
certificate without the latter's request,
which shall include the following:
- 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.
|
WT33 |
A.2.r |
The CP clearly describes the process of
suspending a subscriber certificate,
including how requests for suspensions
are authenticated, which personnel are
authorized to perform that action and what
records are made of that performance.
|
✔
|
-
Suspension not supported or offered.
-
CPS4.9.13-16.
|
WT24 WT34 |
A.2.s |
The CP describes the differences between
renewing a subscriber certificate about to
expire, replacing a subscriber certificate
that was already allowed to expire, and
replacing a subscriber certificate that has
been revoked.
|
✔
|
-
CA only offers one form of certificate issuance,
which covers all these variants.
-
CPS4.6-9.
|
(WT20) WT33 (WT44) |
A.2.t |
The CP details the maintenance of the root
certificate, including:
- 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 ?
|
(WT20) WT33 (WT44) |
A.2.u |
The CP details the maintenance of any
intermediate certificates, including:
- 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
|
✘
|
-
§A.2.u is a duplicate of §A.2.t
|
(WT39) WT25 (WT26) (WT44) |
A.2.v |
The CP details how external registration
authorities (RAs) are approved.
|
-
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.
|
WT12 WT26 |
A.2.w |
The CP details how RAs verify subscriber identities.
|
-
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
|
WT12 WT25 WT26 |
A.2.x |
The CP details how RAs verifies
authorization of individuals to represent
organizational subscribers.
|
✔
|
-
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.
|
WT12 WT25 WT26 |
A.2.y |
The CP details tasks to be performed if
the CA terminates operations, including:
- 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.)
|
(WT6) WT35 WT39 WT40 |
A.3.a |
The CPS is maintained in accord with the
configuration control specification.
|
✘
|
-
CCS not published as yet.
-
CPS has been rewritten, not approved as yet. See §A.3.j.
|
WT6 WT39 |
A.3.b |
The CPS contains details of how disputes between
subscribers and the CA or between the public and
the CA are to be resolved.
|
✔
|
-
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.
|
WT6 |
A.3.c |
The CPS describes potential consequences if the CA merges
with another organization.
|
✔
|
-
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
|
WT6 |
A.3.d |
The CPS cites applicable laws.
|
-
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.
|
WT6 |
A.3.e |
The CPS details the obligations of
subscribers regarding the management of
their certificates.
|
- 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
|
WT14 |
A.3.f |
The CPS contains a schedule of fees charged to subscribers.
|
✔
|
-
AC1.
-
CPS9.1
-
§B.2.l also covers this and therefore conflicts.
|
WT7 |
A.3.g |
The CPS describes the process for changing fees.
|
✔
|
|
WT7 |
A.3.h |
The CPS describes the notification
process used when fees are changed.
|
✔
|
|
WT7 |
A.3.i |
The CPS describes the conditions and process for refunding fees.
|
✔
|
|
WT7 |
A.3.j |
The CPS describes which aspects of the
CA's operations involve protected
intellectual property and what protections
and licenses are involved. The property
status of the following shall be addressed:
- 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
|
WT23 WT35 |
A.3.k |
The CPS describes how the CA handles its subscribers' intellectual property.
|
✔
|
-
AC2.
-
CPS9.13
-
DRP provides forum.
|
WT6 WT42 |
A.3.l |
The CPS describes the CA's procedures
for recovering from disasters and other
operating interruptions, including
- 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
|
✘
|
- Inadequate.
- The entire section depends on the SM.
- CPS5.7 CPS5.7.3 CPS5.7.4.
|
WT8 (WT39) WT44 |
A.4.a |
The privacy policy is maintained in
accord with the configuration control
specification.
|
✔
|
-
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.
|
WT6 WT41 |
A.4.b |
The privacy policy specifically describes which
subscriber data are kept confidential.
|
?❢?
|
-
CPS1.4 covers nyms.
-
CPS5.5
-
PP.1
-
PP.2 DR may override.
|
WT6 WT41 |
A.4.c |
The privacy policy specifically describes which
subscriber data are made public.
|
?❢?
|
-
CPS9.4 refers to PP.
-
PP says no information made public by default.
-
DR may override.
|
WT6 WT41 |
A.4.d |
The privacy policy describes how an
individual may obtain access to a
subscriber's written acceptance of liability
(see §A.6.d).
|
-
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.
|
WT6 WT41 |
A.4.e |
The privacy policy identifies legal mandates regarding
both securing and disclosing subscriber data.
|
✘
|
-
See note §A.5.h on what "legal mandates" refers to.
-
PP should describe applicable laws. CPS9.15.2 §A.3.d.
|
WT6 WT41 |
A.4.f |
The privacy policy describes the CA's response
to government warrants and civil subpoenas
demanding disclosure of protected data.
|
✘
|
-
PP should refer to DR and CPS9.13
-
PP should refer to Privacy Laws
|
WT6 WT41 |
A.5.a |
The CA maintains documentation of its procedures
to ensure the electronic and physical security
of its operations.
|
✘
|
-
SM is a work in progress.
-
Security Handbook is dropped.
|
WT18 WT43 |
A.5.b |
The security manual is maintained in accord with
the configuration control specification.
|
✘
|
-
See comments §A.5.a.
-
CCS also wip.
|
WT43 |
A.5.c |
The security manual describes how
individuals are authorized to access
computer equipment.
|
✘
|
-
See comments §A.5.a.
-
Refer to Oophaga manual.
|
WT43 |
A.5.d |
The security manual describes how
individuals are authorized to change each
of the following:
- 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
|
WT43 |
A.5.e |
The security manual describes the security
of physical equipment. The following
shall be addressed:
- 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
|
WT43 |
A.5.f |
The security manual describes how
computer systems are configured and
updated to protect them against hostile
intrusion, unauthorized electronic access,
and "malware" and how individuals are
authorized to perform those tasks.
|
✘
|
-
See comments §A.5.a.
-
Parts are / may be described in the CCS.
|
WT8 WT18 WT43 |
A.5.g |
The security manual describes how
computer systems and other hardware are
protected against theft and unauthorized
physical access.
|
✘
|
-
See comments §A.5.a.
-
CPS states it is, only.
|
WT8 WT43 |
A.5.h |
The security manual identifies legal
mandates for securing data, software,
hardware, and communications.
|
✘
|
-
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."
|
WT6 |
A.5.i |
The security manual describes the
necessary procedures for recovering from
a breach of security, including such
breaches as:
- 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
|
WT43 WT18 |
A.6.a |
The CA maintains documentation of the
risks to end-users created by their reliance
upon subscriber certificates issued by the
CA.
|
-
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.
|
WT4 WT15 |
A.6.b |
The CA maintains documentation of the
liability it assumes when issuing subscriber
certificates.
|
-
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.
|
WT4 WT5 |
A.6.c |
The CA maintains documentation of the
liability assumed by subscribers when
they use certificates issued by the CA.
|
-
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.
|
WT5 |
A.6.d |
The CA obtains written acceptance from
subscribers of the liability (cited in
§A.6.c) they assume.
|
-
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.
|
WT5 |
B.1.a |
The privacy policy is available to subscribers.
|
✔
|
|
WT8 |
B.1.b |
The configuration-management policy is
available to subscribers.
|
✘
|
-
Interpreted as the CCS, but not entirely sure.
Should query DR.
-
CCS is only WIP status, and requires review.
-
|
WT8 |
B.2.a |
The CP is available to subscribers and the general public.
|
✘
|
|
WT8 WT39 |
B.2.b |
The CPS is available to subscribers and the general public.
|
?❢?
|
-
WIP status CPS
-
Is being rewritten for DRCA
|
WT8 WT39 |
B.2.c |
The statement of risks (cited in §A.6.a) is
available to subscribers and the general
public.
|
-
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.
|
WT8 |
B.2.d |
The statement of the CA's liability (cited
in A.6.b) is available to subscribers and
the general public.
|
✔
|
|
WT8 |
B.2.e |
The statement of the subscriber's liability
(cited in §A.6.c) is available to
subscribers and the general public.
|
-
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.
|
WT8 |
B.2.f |
The statement of each subscriber's
acceptance of liability (cited in §A.6.d) is
available to those who present appropriate
cause to request it.
|
-
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.
|
none |
B.2.g |
Contact information is available to
subscribers and the general public:
|
Contact page provides:
✔
|
-
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.)
|
WT3 |
B.2.h |
A list of subscriber certificates is available
to subscribers and the general public with the
following information for each certificate:
- 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.
|
WT8 WT11 WT21 |
B.2.i |
The information about a subscriber's certificate
(see §B.2.h) that has expired is either
-
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
|
WT11 |
B.2.j |
A list of certificates revoked before their
expiration dates is available to subscribers
and the general public with the same
identifying information as given in B.2.h
along with the reason for the revocation
(see §A.2.o and §A.2.q).
|
✔
|
-
Revocation list includes reason codes.
-
The revocation info does not include info above.
|
WT11 WT33 WT35 |
B.2.k |
Tools for verifying subscriber certificates are supported
(e.g., certificate revocation list (CRL),
online certificate status protocol (OCSP))
in a timely manner.
|
✔
-
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.
|
WT13 WT32 WT33 WT35 WT36 |
B.2.l |
The fee schedule is available to subscribers and the general public.
|
✔
|
-
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.
|
WT7 |
B.2.m |
The CA promptly notifies all current subscribers
of any breach of security (see C.2).
|
✘
|
-
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.
|
(none) |
B.2.n |
The CA makes available to the general
public information about any breach of
security (see §C.2).
|
✘
|
|
(none) |
B.2.o |
The CA makes available to the general
public configuration-control logs and
records (see §A.1.k).
|
✘
|
-
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
|
(none) |
B.2.p |
This checklist (as completed by the
reviewer) and the reviewer's attestation
are available to subscribers and the
general public.
|
✔
|
-
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.
|
WT9 |
C.1.a |
The CA has been repeatedly observed to operate
in general conformance with its CP.
|
✘
|
|
WT9 |
C.1.b |
The CA has been repeatedly observed to operate
in general conformance with its CPS.
|
✘
|
|
WT9 |
C.1.c |
The CA has been repeatedly observed to operate in
general conformance with its privacy policy.
|
✘
|
|
WT9 |
C.1.d |
CA personnel demonstrate knowledge of disaster recovery
procedures (see §A.3.l).
|
✘
|
|
WT43 |
C.2.a |
CA personnel demonstrate knowledge
of proper security practices
(see §A.5).
|
✘
|
|
WT43 |
C.2.b |
The CA maintains current protection against:
- being infected by computer viruses
and other "malware"
- distributing computer viruses and
other "malware"
(See §A.5.f)
|
✘
|
|
WT18 WT43 |
C.2.c |
The CA maintains current protection against
"hacking", snooping, and other electronic
intrusions into its computer systems
(see §A.5.f).
|
✘
|
|
WT18 WT43 |
C.2.d |
The CA protects computer systems and other
hardware involved in certificate operations
and subscriber records against theft and
unauthorized physical and electronic access
(see §A.5.f and §A.5.g).
|
✘
|
|
WT18 WT43 |
C.3.a |
The root certificate public key is
readily available for downloading
and installation by subscribers and
the general public.
|
✘
|
|
WT20 |
C.3.b |
The root certificate public key can be
readily authenticated by subscribers
and the general public.
|
✘
|
|
WT20 |
C.3.c |
The root certificate private key
is stored secure from electronic
and physical compromise.
|
✘
|
|
WT18 |
C.3.d |
The root certificate private key
is stored by the CA and not by any
outside party.
|
✘
|
|
WT18 |
C.3.e |
The root certificate private key pass-phrase
(i.e. password) is not stored electronically
or physically.
|
✘
|
|
WT18 |
C.3.f |
The root certificate private key pass-phrase
(or parts thereof) is known only to
CA personnel.
|
✘
|
|
WT18 |
C.3.g |
Provision is made to prevent loss of the
root certificate through a single-point
of failure of electronic equipment
(including physical destruction of
such equipment).
|
✘
|
|
WT18 |
C.3.h |
Provision is made to prevent loss of use
of the root certificate resulting from the
loss of one key person.
|
✘
|
|
WT18 |
C.3.i |
Use of the root certificate private key
requires cooperative action by at least
two CA personnel.
|
✘
|
|
WT18 |
C.3.j |
All subscribers are notified immediately
if the root certificate is revoked.
|
✘
|
|
WT21 |
C.3.k |
file not found
|
|
|
|
C.3.l |
Expired and revoked root certificates are
archived.
|
✘
|
|
WT18 |
C.4.a |
Intermediate certificate public keys are
readily available for downloading and
installation by subscribers and the
general public.
|
✘
|
|
WT18 |
C.4.b |
The intermediate certificate private keys
are stored secure from electronic and
physical compromise.
|
✘
|
|
WT18 |
C.4.c |
The intermediate certificates are created
by the CA and not by any outside party.
|
✘
|
-
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."
|
None |
C.4.d |
The intermediate certificate private key
pass-phrases (or parts thereof) are known
only to CA personnel.
|
✘
|
|
WT18 |
C.4.e |
The intermediate certificate private key
pass-phrases are stored securely.
|
✘
|
|
WT18 |
C.4.f |
All affected subscribers are notified
immediately if an intermediate certificate
is revoked.
|
✘
|
|
WT21 |
C.4.g |
Provision is made for prompt re-signing
of affected non-expired, non-revoked
subscriber certificates with a new
intermediate certificate if an
intermediate certificate is revoked.
|
✘
|
|
WT21 |
C.4.h |
Expired and revoked intermediate certificates
are archived.
|
✘
|
|
WT18 |
C.5.a |
If the CA generates certificates
for its subscribers, all requirements
for signing subscriber certificates
are met (see §C.6).
|
✘
|
|
WT19 |
C.5.b |
If the CA generates certificates for its
subscribers, a subscriber's private key
is stored with the same security as the
CA's key that signed the subscriber's
certificate.
|
✘
|
|
WT19 WT23 |
C.5.c |
If the CA generates certificates for its
subscribers, a subscriber's private key
is communicated to the subscriber in a
secure manner.
|
✘
|
|
WT22 |
C.5.d |
If the CA generates certificates for its
subscribers, a subscriber is immediately
advised to change its certificate's
pass-phrase.
|
✘
|
|
(nonw) |
C.5.e |
Pass-phrases for CA-generated subscriber
certificates are randomly generated.
|
✘
|
|
(none) |
C.5.f |
A record of the pass-phrase for a
CA-generated subscriber certificate
is not retained beyond delivery of
the certificate to the subscriber.
|
✘
|
|
WT23 |
C.5.g |
The pass-phrase for a CA-generated
subscriber certificate is communicated
to the subscriber in a secure manner
separately from the corresponding private
key.
|
✘
|
|
(none) |
C.5.h |
If the CA generates certificates for its
subscribers, the user ID chosen by the
subscriber properly appears in the
certificate.
|
✘
|
|
(none) |
C.6.a |
Positive identity of a subscriber is
obtained prior to signing a subscriber's
certificate.
|
✘
|
|
WT25 |
C.6.b |
Prior to signing a subscriber's certificate,
the purposes contained within the certificate
is verified to agree with the purposes in
the subscriber's request for signatures
(see §A.2.l).
|
✘
|
|
WT22 WT25 |
C.6.c |
For subscriber E-mail certificates, the
E-mail address in the certificate matches
the address in the subscriber's application
for signature (see §A.2.g).
|
✘
|
extrasearchterm: email
|
WT25 |
C.6.d |
For subscriber site certificates, the
domain in the certificate matches the
domain in the subscriber's application
for signature (see §A.2.h).
|
✘
|
|
WT25 |
C.6.e |
When an individual requests a certificate
to be signed and the subscriber is an
organization, the following are positively
verified:
- the individual's identity
- the individual's authorization to
request a signature on the
certificate
|
✘
|
|
WT25 |
C.6.f |
Certificates are signed in a timely manner.
|
✘
|
|
WT11 |
C.6.g |
The public list of subscriber certificates
(see §B.2.h)
is updated in a timely manner to show
newly signed certificates.
|
✘
|
|
WT13 |
C.7.a |
The CA notifies the affected subscriber
in a timely manner when a certificate
generated by the CA is about to expire.
|
✘
|
|
WT27 |
C.7.b |
The same care is taken during the renewal
of a certificate generated by the CA as
was taken during the certificate's initial
issue (see §C.5).
|
✘
|
|
WT27 WT29 |
C.7.c |
The CA notifies the affected subscriber
in a timely manner when the CA's signature
on a certificate is about to expire.
|
✘
|
|
WT27 |
C.7.d |
The same care is taken during the renewal
of a certificate's signature as was taken
during the certificate's initial signing
(see §C.6).
|
✘
|
|
WT27 WT29 |
C.7.e |
Replacing a certificate that already expired
is handled in accord with the CP
(see §A.2.s)
with the same care as for a certificate
about to expire
(as indicated in this §C.7).
|
✘
|
|
WT27 WT29 |
C.7.f |
Before renewing a site certificate,
the domain registration is verified
that the domain owner has not changed.
|
✘
|
|
(none) |
C.8.a |
Revoking a subscriber's certificate is
performed in accord with the CP
(see §A.2.p).
|
✘
|
|
WT33 |
C.8.b |
Positive identity of a subscriber is
obtained before the CA acts on the
subscriber's request to revoke a
certificate.
|
✘
|
|
WT33 |
C.8.c |
Certificates are revoked promptly.
|
✘
|
|
WT33 |
C.8.d |
A subscriber is required to notify the
CA promptly if the subscriber revokes
its own key. Such notification must
include positive identification of the
subscriber.
|
✘
|
|
WT33 |
C.8.e |
Replacing a revoked certificate is handled
in accord with the CP (see §A.2.s) and
with the same care as for a certificate about
to expire (see §C.7).
|
✘
|
|
(none) |
C.8.f |
The public list of revoked certificates
(see §B.2.j) is updated promptly.
|
✘
|
|
WT33 WT35 |
C.9.a |
When the CA uses an external registration
authority (RA), each RA is positively
identified by CA personnel before being
authorized to verify identities of
subscribers and authorizations of
individuals to represent organizational
subscribers (see §A.2.v).
|
✘
|
|
WT25 WT26 |
C.9.b |
RAs provide the CA with complete
documentation on each verified
applicant for a certificate
(see §A.2.w).
|
✘
|
|
WT26 |
C.9.c |
RAs provide the CA with complete
documentation on each verified
authorized individual representing
an organizational subscriber
(see §A.2.x).
|
✘
|
|
WT26 |