1 <!DOCTYPE HTML
PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
4 <meta name
="copyright" content
="CAcert Inc http://www.cacert.org/">
5 <title
>Certification Practice
Statement (CPS
)</title
>
7 <style type
="text/css">
10 font
-family
: verdana
, helvetica
, arial
, sans
-serif
;
13 pre
, code
, kbd
, tt
, samp
{
14 font
-family
: courier
, monospace
;
24 margin
-bottom
: 0.5em
;
67 <h1
>CAcert CPS
and CP
</h1
>
69 <a href
="PolicyOnPolicy.html"><img src
="cacert-draft.png" alt
="CAcert Policy Status" height
="31" width
="88" style
="border-style: none;" /></a
><br
/>
70 Creation date
: 20060726<br
/>
71 Status
: DRAFT p20091108
<br
/>
72 <!-- $Id: CertificationPracticeStatement
.php
,v
1.1 2009-11-21 22:34:00 philipp Exp $
-->
78 <li
> <a href
="#p1">INTRODUCTION
</a
>
80 <li
><a href
="#p1.1">1.1. Overview
</a
></li
>
81 <li
><a href
="#p1.2">1.2. Document name
and identification
</a
></li
>
82 <li
><a href
="#p1.3">1.3. PKI participants
</a
> </li
>
83 <li
><a href
="#p1.4">1.4. Certificate usage
</a
> </li
>
84 <li
><a href
="#p1.5">1.5. Policy administration
</a
> </li
>
85 <li
><a href
="#p1.6">1.6. Definitions
and acronyms
</a
></li
>
88 <li
> <a href
="#p2">PUBLICATION
AND REPOSITORY RESPONSIBILITIES
</a
>
90 <li
><a href
="#p2.1">2.1. Repositories
</a
></li
>
91 <li
><a href
="#p2.2">2.2. Publication of certification information
</a
></li
>
92 <li
><a href
="#p2.3">2.3. Time
or frequency of publication
</a
></li
>
93 <li
><a href
="#p2.4">2.4. Access controls on repositories
</a
></li
>
96 <li
> <a href
="#p3">IDENTIFICATION
AND AUTHENTICATION (I
&
;A
)</a
>
98 <li
><a href
="#p3.1">3.1. Naming
</a
> </li
>
99 <li
><a href
="#p3.2">3.2. Initial Identity Verification
</a
> </li
>
100 <li
><a href
="#p3.3">3.3. I
&
;A
for Re
-key Requests
</a
> </li
>
101 <li
><a href
="#p3.4">3.4. I
&
;A
for Revocation Request
</a
></li
>
104 <li
><a href
="#p4">CERTIFICATE LIFE
-CYCLE OPERATIONAL REQUIREMENTS
</a
>
106 <li
><a href
="#p4.1">4.1. Certificate Application
</a
> </li
>
107 <li
><a href
="#p4.2">4.2. Certificate application processing
</a
> </li
>
108 <li
><a href
="#p4.3">4.3. Certificate issuance
</a
> </li
>
109 <li
><a href
="#p4.4">4.4. Certificate acceptance
</a
> </li
>
110 <li
><a href
="#p4.5">4.5. Key pair
and certificate usage
</a
> </li
>
111 <li
><a href
="#p4.6">4.6. Certificate renewal
</a
> </li
>
112 <li
><a href
="#p4.7">4.7. Certificate re
-key
</a
> </li
>
113 <li
><a href
="#p4.8">4.8. Certificate modification
</a
> </li
>
114 <li
><a href
="#p4.9">4.9. Certificate revocation
and suspension
</a
> </li
>
115 <li
><a href
="#p4.10">4.10. Certificate status services
</a
> </li
>
116 <li
><a href
="#p4.11">4.11. End of subscription
</a
></li
>
117 <li
><a href
="#p4.12">4.12. Key escrow
and recovery
</a
> </li
>
120 <li
><a href
="#p5">FACILITY
, MANAGEMENT
, AND OPERATIONAL CONTROLS
</a
>
122 <li
><a href
="#p5.1">5.1. Physical controls
</a
> </li
>
123 <li
><a href
="#p5.2">5.2. Procedural controls
</a
> </li
>
124 <li
><a href
="#p5.3">5.3. Personnel controls
</a
> </li
>
125 <li
><a href
="#p5.4">5.4. Audit logging procedures
</a
> </li
>
126 <li
><a href
="#p5.5">5.5. Records archival
</a
> </li
>
127 <li
><a href
="#p5.6">5.6. Key changeover
</a
></li
>
128 <li
><a href
="#p5.7">5.7. Compromise
and disaster recovery
</a
> </li
>
129 <li
><a href
="#p5.8">5.8. CA
or RA termination
</a
></li
>
132 <li
><a href
="#p6">TECHNICAL SECURITY CONTROLS
</a
>
134 <li
><a href
="#p6.1">6.1. Key pair generation
and installation
</a
> </li
>
135 <li
><a href
="#p6.2">6.2. Private Key Protection
and Cryptographic Module Engineering Controls
</a
> </li
>
136 <li
><a href
="#p6.3">6.3. Other aspects of key pair management
</a
> </li
>
137 <li
><a href
="#p6.4">6.4. Activation data
</a
> </li
>
138 <li
><a href
="#p6.5">6.5. Computer security controls
</a
> </li
>
139 <li
><a href
="#p6.6">6.6. Life cycle technical controls
</a
> </li
>
140 <li
><a href
="#p6.7">6.7. Network security controls
</a
></li
>
141 <li
><a href
="#p6.8">6.8. Time
-stamping
</a
></li
>
144 <li
><a href
="#p7">CERTIFICATE
, CRL
, AND OCSP PROFILES
</a
>
146 <li
><a href
="#p7.1">7.1. Certificate profile
</a
> </li
>
147 <li
><a href
="#p7.2">7.2. CRL profile
</a
> </li
>
148 <li
><a href
="#p7.3">7.3. OCSP profile
</a
> </li
>
151 <li
><a href
="#p8">COMPLIANCE AUDIT
AND OTHER ASSESSMENTS
</a
>
153 <li
><a href
="#p8.1">8.1. Frequency
or circumstances of assessment
</a
></li
>
154 <li
><a href
="#p8.2">8.2. Identity
/qualifications of assessor
</a
></li
>
155 <li
><a href
="#p8.3">8.3. Assessor
's relationship to assessed entity</a></li>
156 <li><a href="#p8.4">8.4. Topics covered by assessment</a></li>
157 <li><a href="#p8.5">8.5. Actions taken as a result of deficiency</a></li>
158 <li><a href="#p8.6">8.6. Communication of results</a></li>
161 <li><a href="#p9">OTHER BUSINESS AND LEGAL MATTERS</a>
163 <li><a href="#p9.1">9.1. Fees</a> </li>
164 <li><a href="#p9.2">9.2. Financial responsibility</a> </li>
165 <li><a href="#p9.3">9.3. Confidentiality of business information</a> </li>
166 <li><a href="#p9.4">9.4. Privacy of personal information</a> </li>
167 <li><a href="#p9.5">9.5. Intellectual property rights</a></li>
168 <li><a href="#p9.6">9.6. Representations and warranties</a> </li>
169 <li><a href="#p9.7">9.7. Disclaimers of warranties</a></li>
170 <li><a href="#p9.8">9.8. Limitations of liability</a></li>
171 <li><a href="#p9.9">9.9. Indemnities</a></li>
172 <li><a href="#p9.10">9.10. Term and termination</a> </li>
173 <li><a href="#p9.11">9.11. Individual notices and communications with participants</a></li>
174 <li><a href="#p9.12">9.12. Amendments</a> </li>
175 <li><a href="#p9.13">9.13. Dispute resolution provisions</a></li>
176 <li><a href="#p9.14">9.14. Governing law</a></li>
177 <li><a href="#p9.15">9.15. Compliance with applicable law</a></li>
178 <li><a href="#p9.16">9.16. Miscellaneous provisions</a> </li>
187 <!-- *************************************************************** -->
188 <h2><a name="p1" id="p1">1. INTRODUCTION</a></h2>
190 <h3><a name="p1.1" id="p1.1">1.1. Overview</a></h3>
193 This document is the Certification Practice Statement (CPS) of
194 CAcert, the Community Certification Authority (CA).
195 It describes rules and procedures used by CAcert for
197 and applies to all CAcert PKI Participants,
198 including Assurers, Members, and CAcert itself.
204 <h3><a name="p1.2" id="p1.2">1.2. Document name and identification</a></h3>
207 This document is the Certification Practice Statement (CPS) of CAcert.
208 The CPS also fulfills the role of the Certificate Policy (CP)
209 for each class of certificate.
214 This document is COD6 under CAcert Official Documents numbering scheme.
217 The document is structured according to
219 <a href="http://www.ietf.org/rfc/rfc3647.txt">RFC3647</a>,
220 <a href="http://tools.ietf.org/html/rfc3647#section-4">chapter 4</a>.
221 All headings derive from that Chapter.
224 It has been improved and reviewed (or will be reviewed)
225 to meet or exceed the criteria of the
226 <cite>Certificate Authority Review Checklist</cite>
227 from <i>David E. Ross</i> ("DRC")
228 and Mozilla Foundation's CA policy
.
231 OID assigned to this document
: 1.3.6.1.4.1.18506.4.4.x (x
=approved Version
)
232 (<a href
="http://www.iana.org/assignments/enterprise-numbers">iana
.org
</a
>)
233 <p
class="q"> .x will change to
.1 in the first approved instance
.</p
>
236 ©
; CAcert Inc
. 2006-2009.
237 <!-- note that CCS policies must be controlled by CAcert Inc
. -->
240 Issued under the CAcert document licence policy
,
241 as and when made policy
.
242 See
<a href
="http://wiki.cacert.org/wiki/PolicyDrafts/DocumentLicence">
243 PolicyDrafts
/DocumentLicence
</a
>.
245 <li
> The cited page discusses
2 options
: CCau Attribute
-Share
-alike
and GNU Free Document License
. Refer to that
. </li
>
246 <li
> Note that the noun Licence in Australian English has two Cs
. The verb License is spelt the same way
as American English
. </li
>
250 Earlier notes were written by Christian Barmala
251 in a document placed under GNU Free Document License
252 and under FSF copyright
.
253 However this clashed with the control provisions of
254 Configuration
-Control Specification
255 (COD2
) within Audit criteria
.
258 <span
class="q">In this document
:</span
>
261 <span
class="q">green text
</span
>
262 refers to questions that seek answers
,
264 <span
class="error">red text
</span
>
265 refers to probably audit fails
or serious errors
.
267 <span
class="change">blue text
</span
>
268 refers to changes written after the document got seriously reviewed
.
271 None is to be considered part of the policy
,
272 and they should disappear in the DRAFT
273 and must disappear in the POLICY
.
278 Some content is incorporated under
279 <!-- <a href
="http://xkcd.com/license.html">Creative Commons license
</a
> -->
280 <!-- from
<a href
="http://xkcd.com/">xkcd
.com
</a
>. -->
287 The CPS is an authoritive document
,
288 and rules other documents
289 except where explicitly deferred to
.
290 See also
<a href
="#p1.5.1">1.5.1 Organisation Administering the Document
</a
>.
293 <h3
><a name
="p1.3" id
="p1.3">1.3. PKI participants
</a
></h3
>
295 The CA is legally operated by CAcert Incorporated
,
296 an Association registered in
2002 in
297 New South Wales
, Australia
,
298 on behalf of the wider Community of Members of CAcert
.
299 The Association details are at the
300 <a href
="http://wiki.cacert.org/wiki/CAcertIncorporated">CAcert wiki
</a
>.
304 CAcert is a Community formed of Members who agree to the
305 <a href
="http://www.cacert.org/policy/CAcertCommunityAgreement.php">
306 CAcert Community Agreement
</a
>.
307 The CA is technically operated by the Community
,
308 under the direction of the Board of CAcert Incorporated
.
309 (The Members of the Community are not to be confused
310 with the
<i
>Association Members
</i
>, which latter are
311 not referred to anywhere in this CPS
.)
314 <h4
><a name
="p1.3.1" id
="p1.3.1">1.3.1. Certification authorities
</a
></h4
>
316 CAcert does not issue certificates to external
317 intermediate CAs under the present CPS
.
320 <h4
><a name
="p1.3.2" id
="p1.3.2">1.3.2. Registration authorities
</a
></h4
>
322 Registration
Authorities (RAs
) are controlled under Assurance Policy
323 (<a href
="http://www.cacert.org/policy/AssurancePolicy.php">COD13
</a
>).
326 <h4
><a name
="p1.3.3" id
="p1.3.3">1.3.3. Subscribers
</a
></h4
>
329 CAcert issues certificates to Members only
.
330 Such Members then become Subscribers
.
334 <h4
><a name
="p1.3.4" id
="p1.3.4">1.3.4. Relying parties
</a
></h4
>
337 A relying party is a Member
,
339 CAcert Community Agreement
340 (<a href
="http://www.cacert.org/policy/CAcertCommunityAgreement.php">COD9
</a
>),
341 who
, in the act of using a CAcert certificate
,
342 makes a decision on the basis of that certificate
.
345 <h4
><a name
="p1.3.5" id
="p1.3.5">1.3.5. Other participants
</a
></h4
>
349 Membership of the Community is
as defined in the
350 <a href
="http://www.cacert.org/policy/CAcertCommunityAgreement.php">COD9
</a
>.
351 Only Members may RELY
or may become Subscribers
.
357 A senior
and experienced Member of the CAcert Community
358 who resolves disputes between Members
, including ones
359 of certificate reliance
, under
360 Dispute Resolution Policy
361 (<a href
="http://www.cacert.org/policy/DisputeResolutionPolicy.php">COD7
</a
>).
366 Software suppliers who integrate the root certificates of CAcert
367 into their software also assume a proxy role of Relying Parties
,
368 and are subject to another licence
.
370 At the time of writing
, the
371 "3rd Party Vendor - Disclaimer and Licence"
372 is being worked upon
, but is neither approved nor offered
.
377 <b
>Non
-Related Persons
</b
> (NRPs
).
378 These are users of browsers
and similar software who are
379 unaware of the CAcert certificates they may
use, and
380 are unaware of the ramifications of usage
.
381 Their relationship with CAcert
383 Non
-related Persons
- Disclaimer
and Licence
384 (<a href
="http://www.cacert.org/policy/NRPDisclaimerAndLicence.php">COD4
</a
>).
385 No other rights nor relationship is implied
or offered
.
389 <h3
><a name
="p1.4" id
="p1.4">1.4. Certificate usage
</a
></h3
>
391 <p
>CAcert serves
as issuer of certificates
for
392 individuals
, businesses
, governments
, charities
,
393 associations
, churches
, schools
,
394 non
-governmental organisations
or other groups
.
395 CAcert certificates are intended
for low
-cost
396 community applications especially where volunteers can
397 become Assurers
and help CAcert to help the Community
.
401 Types of certificates
and their appropriate
and
402 corresponding applications are defined in
403 <a href
="#p1.4.1">§
;1.4.1</a
>.
404 Prohibited applications are defined in
<a href
="#p1.4.2">§
;1.4.2</a
>.
405 Specialist uses may be agreed by contract
or within
406 a specific environment
, as described in
407 <a href
="#p1.4.4">§
;1.4.4</a
>.
409 unreliable applications in
410 <a href
="#p1.4.3">§
;1.4.3</a
>
411 and risks
, liabilities
and obligations in
412 <a href
="#p9">§
;9</a
>.
417 <table border
="1" cellpadding
="5">
419 <td colspan
="2"><center
><i
>Type
</center
></i
></td
>
420 <td colspan
="2"><center
><i
>Appropriate Certificate uses
</center
></i
></th
>
425 <th
><center
>Description
</center
></th
>
426 <th
><center
>Comments
</center
></th
>
429 <td rowspan
="2"><center
>Server
</center
></td
>
431 <td
> web server encryption
</td
>
432 <td
> enables encryption
</td
>
436 <td
> embedded server authentication
</td
>
437 <td
> mail servers
, IM
-servers
</td
>
440 <td rowspan
="4"><center
>Client
</center
></td
>
442 <td
> email encryption
</td
>
443 <td
> "digital signatures" employed in S
/MIME
444 are not legal
/ human signatures
,
445 but instead enable the encryption mode of S
/MIME
</td
>
449 <td
> client authentication
</td
>
450 <td
> the nodes must be secure
</td
>
454 <td
> web based signature applications
</td
>
455 <td
> the certificate authenticates only
. See
<a href
="#p1.4.3">§
;1.4.3</a
>. </td
>
458 <td
> "
;Digital Signing
"
; </td
>
459 <td
> for human signing over documents
</td
>
460 <td
> Only within a wider application
and rules
461 such
as by separate policy
,
462 as agreed by contract
, etc
.
463 See
<a href
="#p1.4.4">§
;1.4.4</a
>.
467 <td
><center
>Code
</center
></td
>
468 <td
> Authenticode
, ElfSign
, Java
</td
>
469 <td
> Code Signing
</td
>
470 <td
> Signatures on packages are evidence of their Membership
and indicative of Identity
</td
>
473 <td
><center
>PGP
</center
></td
>
475 <td
> Key Signing
</td
>
476 <td
> Signatures on Member Keys are evidence of their Membership
and indicative of Identity
</td
>
479 <td
><center
>Special
</center
></td
>
481 <td
> OCSP
, Timestamping
</td
>
482 <td
> Only available to CAcert Systems Administrators
, as controlled by Security Policy
</td
>
486 <span
class="figure">Table
1.4. Types of Certificate
</span
>
489 <h4
><a name
="p1.4.1" id
="p1.4.1">1.4.1. Appropriate certificate uses
</a
></h4
>
496 CAcert server certificates can be used to enable encryption
497 protection in web servers
.
498 Suitable applications
include webmail
and chat forums
.
500 CAcert server certificates can be used to enable encryption
501 in SSL
/TLS links in embedded protocols such
as mail servers
504 CAcert client certificates can be used to enable encryption
505 protection in email clients
.
506 (See
<a href
="#p1.4.3">§
;1.4.3</a
> for caveat on signatures
.)
508 CAcert client certificates can be used to replace password
-based
509 authentication to web servers
.
511 OpenPGP keys with CAcert signatures can be used
512 to encrypt
and sign files
and emails
,
513 using software compatible with OpenPGP
.
515 CAcert client certificates can be used in web
-based
516 authentication applications
.
518 CAcert code signing certificates can be used to sign code
519 for distribution to other people
.
521 Time stamping can be used to attach a time record
522 to a digital document
.
526 <h4
><a name
="p1.4.2" id
="p1.4.2">1.4.2. Prohibited certificate uses
</a
></h4
>
528 CAcert certificates are not designed
, intended
, or authorised
for
529 the following applications
:
532 Use or resale
as control equipment in hazardous circumstances
533 or for uses requiring fail
-safe performance such
as the operation
534 of nuclear facilities
, aircraft navigation
or communication systems
,
535 air traffic control systems
, or weapons control systems
,
536 where failure could lead directly to death
, personal injury
,
537 or severe environmental damage
.
540 <h4
><a name
="p1.4.3" id
="p1.4.3">1.4.3. Unreliable Applications
</a
></h4
>
543 CAcert certificates are not designed nor intended
for use in
544 the following applications
, and may not be reliable enough
545 for these applications
:
549 <b
>Signing within Protocols
.</b
>
550 Digital signatures made by CAcert certificates carry
551 <u
>NO
default legal
or human meaning
</u
>.
552 See
<a href
="#p9.15.1">§
;9.15.1</a
>.
553 Especially
, protocols such
as S
/MIME commonly will automatically
554 apply digital signatures
as part of their protocol needs
.
555 The purpose of the cryptographic signature in S
/MIME
556 and similar protocols is limited by
default to strictly
557 protocol security purposes
:
558 to provide some confirmation that a familiar certificate
559 is in
use, to enable encryption
, and to ensure the integrity
560 of the email in transit
.
562 <b
>Non
-repudiation applications
.</b
>
563 Non
-repudiation is not to be implied from
use of
564 CAcert certificates
. Rather
, certificates may
565 provide support
or evidence of actions
, but that
566 evidence is testable in any dispute
.
568 <b
>Ecommerce applications
.</b
>
569 Financial transactions
or payments
or valuable e
-commerce
.
571 Use of
anonymous (Class 1 or Member SubRoot
) certificates
572 in any application that requires
or expects identity
.
575 <!-- <center
><a href
="http://xkcd.com/341/"> <img src
="http://imgs.xkcd.com/comics/1337_part_1.png"> </a
> </center
> -->
577 <h4
><a name
="p1.4.4" id
="p1.4.4">1.4.4. Limited certificate uses
</a
></h4
>
580 By contract
or within a specific environment
581 (e
.g
. internal to a company
),
582 CAcert Members are permitted to
use Certificates
583 for higher security
, customised
or experimental applications
.
584 Any such usage
, however
, is limited to such entities
585 and these entities take on the whole responsible
for
586 any harm
or liability caused by such usage
.
590 <b
>Digital signing applications
.</b
>
591 CAcert client certificates
592 may be used by Assured Members in
593 applications that provide
or support the human signing of documents
594 (known here
as "digital signing").
595 This must be part of a wider framework
and set of rules
.
597 must be documented either under a separate CAcert digital signing
598 policy
or other external regime agreed by the parties
.
601 <h4
><a name
="p1.4.5" id
="p1.4.5">1.4.5. Roots
and Names
</a
></h4
>
604 <b
>Named Certificates
.</b
>
605 Assured Members may be issued certificates
606 with their verified names in the certificate
. In this role
, CAcert
607 operates
and supports a network of Assurers who verify the
608 identity of the Members
.
609 All Names are verified
, either by Assurance
or another defined
610 method under
policy (c
.f
. Organisations
).
614 <b
>Anonymous Certificates
.</b
>
615 Members can be issued certificates that are anonymous
,
616 which is defined
as the certificate with no Name included
,
617 or a shared name such
as "Community Member".
618 These may be considered to be somewhere between Named certificates
619 and self
-signed certificates
. They have serial numbers in them
620 which is ultimately traceable via dispute to a Member
, but
621 reliance is undefined
.
622 In this role
, CAcert provides the
623 infrastructure
, saving the Members from managing a difficult
624 and messy process in order to get manufactured certificates
.
628 <b
>Psuedonymous Certificates
.</b
>
629 Note that CAcert does not currently issue pseudonymous certificates
,
630 being those with a name chosen by the Member
and not verifiable
631 according to documents
.
635 <b
>Advanced Certificates
.</b
>
636 Members who are
as yet unassured are not permitted to create
637 advanced forms such
as wildcard
or subjectAltName
644 The
<span
class="q"> (new) </span
> CAcert root layout is
as below
.
645 These roots are pending Audit
,
646 and will be submitted to vendors via
the (Top
-level
) Root
.
649 <b
>(Top
-level
) Root
.</b
>
650 Used to sign on
-line CAcert SubRoots only
.
651 This Root is kept offline
.
653 <b
>Member SubRoot
.</b
>
654 For Community Members who are
new and unassured (some restrictions exist
).
655 Reliance is undefined
.
656 (Replacement
for the
Class 1 root
, matches
"Domain Validation" type
.)
658 <b
>Assured SubRoot
.</b
>
659 Only available
for Assured individual Members
,
660 intended to sign certificates with Names
.
661 Suitable
for Reliance under this
and other policies
.
662 Approximates the type known
as Individual Validation
.
664 <b
>Organisation SubRoot
.</b
>
665 Only available
for Assured Organisation Members
.
666 Suitable
for Reliance under this
and other policies
.
667 Approximates the type known
as Organisational Validation
.
674 <table border
="1" cellpadding
="5">
677 <td colspan
="5"><center
><i
>Level of Assurance
</center
></i
></td
>
682 <th colspan
="2"><center
> Members
&dagger
; </center
></th
>
683 <th colspan
="2"><center
> Assured Members
</center
></th
>
684 <th colspan
="1"><center
> Assurers
</center
></th
>
685 <th colspan
="1"><center
> </center
></th
>
688 <td
><i
>Class of Root
</i
></td
>
694 <td colspan
="1"><center
><i
>Remarks
</center
></i
></td
>
697 <td
><center
>Top level
<br
><big
><b
>Root
</b
></big
></center
></td
>
698 <td
> <center
> <font title
="pass." color
="green" size
="+3"> &bull
; </font
> </center
> </th
>
699 <td
> <center
> <font title
="pass." color
="green" size
="+3"> &bull
; </font
> </center
> </th
>
700 <td
> <center
> <font title
="pass." color
="green" size
="+3"> &bull
; </font
> </center
> </td
>
701 <td
> <center
> <font title
="pass." color
="green" size
="+3"> &bull
; </font
> </center
> </td
>
702 <td
> <center
> <font title
="pass." color
="green" size
="+3"> &bull
; </font
> </center
> </td
>
703 <td
> Signs other CAcert SubRoots only
. </td
>
706 <td
><center
><big
><b
>Member
</b
></big
><br
>SubRoot
</center
></td
>
707 <td
> <center
> <font title
="pass." color
="green" size
="+3"> ✔ </font> </center> </td>
708 <td
> <center
> <font title
="pass." color
="red" size
="+3"> ✘ </font> </center> </th>
709 <td
> <center
> <font title
="pass." color
="green" size
="+3"> ✔ </font> </center> </td>
710 <td
> <center
> <font title
="pass." color
="green" size
="+3"> ✔ </font> </center> </td>
711 <td
> <center
> <font title
="pass." color
="green" size
="+3"> ✔ </font> </center> </td>
712 <td
> &dagger
; For Members meeting basic checks in
<a href
="#p4.2.2">§
;4.2.2</a
><br
>(Reliance is undefined
.) </td
>
715 <td
><center
><big
><b
>Assured
</b
></big
><br
>SubRoot
</center
></td
>
716 <td
> <center
> <font title
="pass." color
="red" size
="+3"> ✘ </font> </center> </th>
717 <td
> <center
> <font title
="pass." color
="red" size
="+3"> ✘ </font> </center> </th>
718 <td
> <center
> <font title
="pass." color
="green" size
="+3"> ✔ </font> </center> </td>
719 <td
> <center
> <font title
="pass." color
="green" size
="+3"> ✔ </font> </center> </td>
720 <td
> <center
> <font title
="pass." color
="green" size
="+3"> ✔ </font> </center> </td>
721 <td
> Assured Members only
.<br
>Fully intended
for reliance
. </td
>
724 <td
><center
><big
><b
>Organisation
</b
></big
><br
>SubRoot
</center
></td
>
725 <td
> <center
> <font title
="pass." color
="red" size
="+3"> ✘ </font> </center> </th>
726 <td
> <center
> <font title
="pass." color
="red" size
="+3"> ✘ </font> </center> </th>
727 <td
> <center
> <font title
="pass." color
="green" size
="+3"> ✔ </font> </center> </td>
728 <td
> <center
> <font title
="pass." color
="green" size
="+3"> ✔ </font> </center> </td>
729 <td
> <center
> <font title
="pass." color
="green" size
="+3"> ✔ </font> </center> </td>
730 <td
> Assured Organisation Members only
.<br
>Fully intended
for reliance
. </td
>
733 <th
>Expiry of Certificates
</th
>
734 <td colspan
="2"><center
>6 months
</center
></th
>
735 <td colspan
="3"><center
>24 months
</center
></th
>
739 <td colspan
="2"><center
>client
, server
</center
></th
>
740 <td colspan
="2"><center
>wildcard
, subjectAltName
</center
></th
>
741 <td colspan
="1"><center
>code
-signing
</center
></th
>
742 <td
> (Inclusive to the left
.) </td
>
746 <span
class="figure">Table
1.4.5.b Certificate under Audit Roots
</span
>
751 Following information on OLD roots here
for
752 descriptive
and historical purposes only
.
753 When CPS goes to DRAFT
, this needs to be
754 converted into a short summary of the way
755 OLD roots are used
and its relationship to
756 this CPS
. E
.g
., "OLD roots are used for
757 testing and other purposes outside this CPS."
758 Because
... they still exist
, and people will
759 look at the CPS to figure it out
.
763 <table border
="1" cellpadding
="5">
766 <td colspan
="4"><center
><i
>Level of Assurance
</center
></i
></td
>
771 <th colspan
="2"><center
>Members
</center
></th
>
772 <th colspan
="2"><center
>Assured Members
</center
></th
>
773 <th colspan
="1"><center
> </center
></th
>
776 <td
><i
>Class of Root
</i
></td
>
781 <td colspan
="1"><center
><i
>Remarks
</center
></i
></td
>
784 <td
><center
>Class<br
><big
><b
>1</b
></big
></center
></td
>
785 <td
> <center
> <font title
="pass." color
="green" size
="+3"> ✔ </font> </center> </td>
786 <td
> <center
> <font title
="pass." color
="red" size
="+3"> ✘ </font> </center> </td>
787 <td
> <center
> <font title
="pass." color
="green" size
="+3"> ✔ </font> </center> </td>
788 <td
> <center
> <font title
="pass." color
="green" size
="+3"> ✔ </font> </center> </td>
789 <td
> Available
for all Members
,<br
>reliance is undefined
.</td
>
792 <td
><center
>Class<br
><big
><b
>3</b
></big
></center
></td
>
793 <td
> <center
> <font title
="pass." color
="red" size
="+3"> ✘ </font> </center> </th>
794 <td
> <center
> <font title
="pass." color
="red" size
="+3"> ✘ </font> </center> </th>
795 <td
> <center
> <font title
="pass." color
="green" size
="+3"> ✔ </font> </center> </td>
796 <td
> <center
> <font title
="pass." color
="green" size
="+3"> ✔ </font> </center> </td>
797 <td
> Assured Members only
.<br
> Intended
for Reliance
. </center
> </td
>
800 <th
>Expiry of Certificates
</th
>
801 <td colspan
="2"><center
>6 months
</center
></th
>
802 <td colspan
="2"><center
>24 months
</center
></th
>
805 <th
>Types available
</th
>
806 <td colspan
="2"><center
>simple only
</center
></th
>
807 <td colspan
="2"><center
>wildcard
, subjectAltName
</center
></th
>
811 <span
class="figure">Table
1.4.5. Certificates under Old Roots
- <b
>Audit Fail
</b
> </span
>
816 The old CAcert root layout is
as below
. These roots are
<b
>Audit Fail
</b
>
817 and will only be used where
new roots
do not serve
:
820 (old
) <b
>Class 1 root
.</b
>
821 Used primarily
for certificates with no names
and by
823 For compatibility only
,
824 Assured Members may also
use this root
.
826 (old
) <b
>Class 3 root
.</b
>
827 Used primarily
for certificates including the names
829 Signed by
Class 1 root
.
830 Members can decide to rely on these
831 certificates
for Assured Members
832 by selecting the
Class 3 root
for
833 Assured Members
as trust anchor
.
837 <li
> Current Mozilla position has drifted from
Class 1,2,3s to DV
, IV+OV
and EV posture
. Except
, the actual posture is either unstated
or difficult to fathom
.</li
>
838 <li
> scheme
for future roots is at
<a href
="http://wiki.cacert.org/wiki/Roots/NewRootsTaskForce">NewRootsTaskForce
</a
>.</li
>
839 <li
>END OLD ROOTS
</li
>
842 <h3
><a name
="p1.5" id
="p1.5">1.5. Policy administration
</a
></h3
>
844 <p
>See
<a href
="#p1.2">1.2 Document Name
and Identification
</a
>
845 for general scope of this document
.</p
>
847 <h4
><a name
="p1.5.1" id
="p1.5.1">1.5.1. Organization administering the document
</a
></h4
>
850 This document is administered by the policy group of
851 the CAcert Community under Policy on
Policy (<a href
="http://www.cacert.org/policy/PolicyOnPolicy.php">COD1
</a
>).
854 <h4
><a name
="p1.5.2" id
="p1.5.2">1.5.2. Contact person
</a
></h4
>
856 For questions including about this document
:
860 <li
>Join the policy group
, by means of the discussion forum at
861 <a href
="http://lists.cacert.org/mailman/listinfo">
862 lists
.cacert
.org
</a
> . </li
>
863 <li
>Send email to
<
; support AT cacert DOT org
>
; </li
>
864 <li
>IRC
: irc
.cacert
.org
#CAcert (ssl port 7000, non-ssl port 6667)</li>
867 <h4
><a name
="p1.5.3" id
="p1.5.3">1.5.3. Person determining CPS suitability
for the policy
</a
></h4
>
869 This CPS
and all other policy documents are managed by
870 the policy group
, which is a group of Members of the
871 Community found at policy forum
. See discussion forums above
.
874 <h4
><a name
="p1.5.4" id
="p1.5.4">1.5.4. CPS approval procedures
</a
></h4
>
876 CPS is controlled
and updated according to the
878 (<a href
="http://www.cacert.org/policy/PolicyOnPolicy.php">COD1
</a
>)
880 Configuration
-Control
Specification (COD2
).
884 In brief
, the policy forum prepares
and discusses
.
885 After a last call
, the document moves to DRAFT status
886 for a defined period
.
887 If no challenges have been received in the defined period
,
888 it moves to POLICY status
.
889 The process is modelled after some elements of
890 the RFC process by the IETF
.
893 <h4
><a name
="p1.5.5" id
="p1.5.5">1.5.5 CPS updates
</a
></h4
>
900 <h3
><a name
="p1.6" id
="p1.6">1.6. Definitions
and acronyms
</a
></h3
>
902 <b
><a name
="d_cert" id
="d_cert">Certificate
</a
></b
>.
903 A certificate is a piece of cryptographic data used
904 to validate certain statements
, especially those of
905 identity
and membership
.
908 <b
><a name
="d_cacert" id
="d_cacert">CAcert
</a
></b
>.
909 CAcert is a Community certificate authority
as defined under
910 <a href
="#p1.2">§
;1.2 Identification
</a
>.
913 <b
><a name
="d_member" id
="d_member">Member
</a
></b
>.
914 Everyone who agrees to the
915 CAcert Community Agreement
916 (<a href
="http://www.cacert.org/policy/CAcertCommunityAgreement.php">COD9
</a
>).
917 This generally implies having an account registered
918 at CAcert
and making
use of CAcert
's data, programs or services.
919 A Member may be an individual ("natural person")
920 or an organisation (sometimes, "legal person").
923 <b><a name="d_community" id="d_community">Community</a></b>.
924 The group of Members who agree to the
925 CAcert Community Agreement
926 (<a href="http://www.cacert.org/policy/CAcertCommunityAgreement.php">COD9</a>)
927 or equivalent agreements.
930 <b><a name="d_unassured" id="d_unassured">Unassured Member</a></b>.
931 A Member who has not yet been Assured.
934 <b><a name="d_subscriber" id="d_subscriber">Subscriber</a></b>.
935 A Member who requests and receives a certificate.
938 <b><a name="d_assured" id="d_assured">Assured Member</a></b>.
939 A Member whose identity has been sufficiently
940 verified by Assurers or other
941 approved methods under Assurance Policy.</p>
944 <b><a name="d_assurer" id="d_assurer">Assurer</a></b>.
945 An Assured Member who is authorised under Assurance Policy
946 to verify the identity of other Members.
949 <b><a name="d_name" id="d_name">Name</a></b>.
952 (<a href="http://www.cacert.org/policy/AssurancePolicy.php">COD13</a>),
953 to describe a name of a Member
954 that is verified by the Assurance process.
956 <b><a name="d_oadmin" id="d_oadmin">Organisation Administrator</a></b>.
958 An Assurer who is authorised to act for an Organisation.
959 The O-Admin is authorised by an organisation
960 to vouch for the identity of other users of the organisation.
963 <b><a name="d_org_ass" id="d_org_ass">Organisation Assurer</a></b>.
964 An Assurer who is authorised to conduct assurances on
968 <b><a name="d_user" id="d_user">Non-Related Persons</a></b>.
970 are general users of browsers and similar software.
971 The NRPs are generally unaware of
972 CAcert or the certificates that they may use, and
973 are unaware of the ramifications of usage.
974 They are not permitted to RELY, but may USE, under the
975 Non-Related Persons - Disclaimer and Licence (<a href="http://www.cacert.org/policy/NRPDisclaimerAndLicence.php">COD4</a>).
978 <b><a name="rel" id="d_reliance">Reliance</a></b>.
979 An industry term referring to
980 the act of making a decision, including taking a risk,
981 which decision is in part or in whole
982 informed or on the basis of the contents of a certificate.
985 <b><a name="rel" id="rel">Relying Party</a></b>.
986 An industry term refering to someone who relies
987 (that is, makes decisions or takes risks)
988 in part or in whole on a certificate.
991 <b>Subscriber Naming.</b>
992 The term used in this CPS to
993 describe all naming data within a certificate.
994 Approximately similar terms from Industry such as
995 "Subject naming" and "Distinguished Name"
999 <b><a name="ver" id="d_verification">Verification</a></b>.
1000 An industry term referring to
1001 the act of checking and controlling
1002 the accuracy and utility of a single claim.
1005 <b><a name="ver" id="d_validation">Validation</a></b>.
1006 An industry term referring to the process of
1007 inspecting and verifying the information and
1008 subsidiary claims behind a claim.
1011 <b><a name="rel" id="rel">Usage</a></b>.
1012 The event of allowing a certificate to participate in
1013 a protocol, as decided and facilitated by a user's software
.
1014 Generally
, Usage does not
require significant input
, if any
,
1015 on the part of the user
.
1016 This defers all decisions to the user software
,
1017 thus elevating the software
as user
's only and complete
1018 Validation Authority or Agent.
1021 <b><a name="drel" id="drel">CAcert Relying Party</a></b>.
1022 CAcert Members who make decisions based in part or in whole
1023 on a certificate issued by CAcert.
1024 Only CAcert Members are permitted to Rely on CAcert certificates,
1025 subject to the CAcert Community Agreement.
1028 <b><a name="ddst" id="ddst">Vendors</a></b>.
1029 Non-members who distribute CAcert's root
or intermediate certificates
1030 in any way
, including but not limited to delivering these
1031 certificates with their products
, e
.g
. browsers
, mailers
or servers
.
1032 Vendors are covered under a separate licence
.
1033 <span
class="q"> As of the moment
, this licence is not written
.</span
>
1036 <b
><a name
="d_ccs" id
="d_ccs">Configuration
-Control Specification
</a
></b
> "CCS".
1037 The audit criteria that controls this CPS
.
1038 The CCS is documented in COD2
, itself a controlled document under CCS
.
1042 <b
><a name
="d_cod" id
="d_cod">CAcert Official Document
</a
></b
> (COD
).
1043 Controlled Documents that are part of the CCS
.
1048 <!-- *************************************************************** -->
1049 <h2
><a name
="p2" id
="p2">2. PUBLICATION
AND REPOSITORY RESPONSIBILITIES
</a
></h2
>
1052 <h3
><a name
="p2.1" id
="p2.1">2.1. Repositories
</a
></h3
>
1055 CAcert operates no repositories in the sense
1056 of lookup
for non
-certificate
-related information
1057 for the general
public.
1061 Under the Assurance
Policy (<a href
="http://www.cacert.org/policy/AssurancePolicy.php">COD13
</a
>),
1062 there are means
for Members to search
, retrieve
1063 and verify certain data about themselves
and others
.
1066 <h3
><a name
="p2.2" id
="p2.2">2.2. Publication of certification information
</a
></h3
>
1073 <li
>A repository of CRLs
. An OCSP responder is in operation
.</li
>
1074 <li
>The root certificate
and intermediate certificates
.</li
>
1078 CAcert does not expressly publish information on issued certificates
.
1079 However
, due to the purpose of certificates
, and the essential
1080 public nature of Names
and email addresses
, all information within
1081 certificates is presumed to be
public and published
, once
1082 issued
and delivered to the Member
.
1085 <h3
><a name
="p2.3" id
="p2.3">2.3. Time
or frequency of publication
</a
></h3
>
1088 Root
and Intermediate Certificates
and CRLs are
1089 made available on issuance
.
1092 <h3
><a name
="p2.4" id
="p2.4">2.4. Access controls on repositories
</a
></h3
>
1093 <p
> No stipulation
. </p
>
1097 <!-- *************************************************************** -->
1098 <h2
><a name
="p3" id
="p3">3. IDENTIFICATION
AND AUTHENTICATION
</a
></h2
>
1100 <h3
><a name
="p3.1" id
="p3.1">3.1. Naming
</a
></h3
>
1102 <h4
><a name
="p3.1.1" id
="p3.1.1">3.1.1. Types of names
</a
></h4
>
1105 <b
>Client Certificates
.</b
>
1106 The Subscriber Naming consists of
:
1109 <li
><tt
>subjectAltName
=</tt
>
1110 One
, or more
, of the Subscriber
's verified email addresses,
1111 in rfc822Name format.
1114 <li>SSO in subjectAltName?.</li>
1116 <li><tt>EmailAddress=</tt>
1117 One, or more, of the Subscriber's verified email addresses
.
1118 This is deprecated under
1119 RFC5280
<a href
="http://tools.ietf.org/html/rfc5280#section-4.2.1.6">4
1121 and is to be phased out
. Also includes a SHA1 hash of a random number
if
1122 the member selects
SSO (Single Sign On ID
) during submission of CSR
.
1124 <li
><tt
>CN
=</tt
> The common name takes its value from one of
:
1127 the
string "<tt>CAcert WoT Member</tt>" may be used
for
1128 anonymous certificates
.
1130 For individual Members
,
1131 a Name of the Subscriber
,
1132 as Assured under AP
.
1134 For Organisation Members
,
1135 an organisation
-chosen name
,
1136 as verified under OAP
.
1141 <li
> <a href
="http://bugs.cacert.org/view.php?id=672"> bug
672</a
> filed on subjectAltName
.</li
>
1142 <li
> O
-Admin must verify
as per
<a href
="http://wiki.cacert.org/wiki/PolicyDecisions">p20081016
</a
>. </li
>
1143 <li
> it is a wip
for OAP to state how this is done
. </li
>
1144 <li
> curiously
, (RFC5280
) verification is only mandated
for subjectAltName not subject field
. </li
>
1145 <li
> what Directory
String is used in above? UTF8String is specified by RFC52804
.1
.2.6? is this important
for the CPS to state?
</li
>
1149 <b
>Individual Server Certificates
.</b
>
1150 The Subscriber Naming consists of
:
1154 The common name is the host name out of a domain
1155 for which the Member is a domain master
.
1157 <tt
>subjectAltName
=</tt
>
1158 Additional host names
for which the Member
1159 is a domain master may be added to permit the
1160 certificate to serve multiple domains on one IP number
.
1162 All other fields are optional
and must either match
1163 the CN
or they must be
empty
1167 <b
>Certificates
for Organisations
.</b
>
1168 In addition to the above
, the following applies
:
1173 organizationalUnitName (set by O
-Admin
, must be verified by O
-Admin
).</li
>
1175 organizationName is the fixed name of the Organisation
.</li
>
1179 stateOrProvinceName
</li
>
1182 <li
><tt
>contact
=</tt
>
1183 EMail Address of Contact
.
1184 <!-- not included in RFC5280
4.1.2.4 list, but
list is not restricted
-->
1189 Except
for the OU
and CN
, fields are taken from the Member
's
1190 account and are as verified by the Organisation Assurance process.
1191 Other Subscriber information that is collected and/or retained
1192 does not go into the certificate.
1195 <h4><a name="p3.1.2" id="p3.1.2">3.1.2. Need for names to be meaningful</a></h4>
1198 Each Member's
Name (<tt
>CN
=</tt
> field
)
1199 is assured under the Assurance
Policy (<a href
="http://www.cacert.org/policy/AssurancePolicy.php">COD13
</a
>)
1200 or subsidiary
policies (such
as Organisation Assurance Policy
).
1201 Refer to those documents
for meanings
and variations
.
1205 Anonymous certificates have the same
<code
>subject
</code
>
1207 See
<a href
="#p1.4.5">§
;1.4.5.</a
>.
1211 Email addresses are verified according to
1212 <a href
="#p4.2.2">§
;4.2.2.</a
>
1215 <!-- <center
><a href
="http://xkcd.com/327/"> <img src
="http://imgs.xkcd.com/comics/exploits_of_a_mom.png"> </a
> </center
> -->
1217 <h4
><a name
="p3.1.3" id
="p3.1.3">3.1.3. Anonymity
or pseudonymity of subscribers
</a
></h4
>
1220 See
<a href
="#p1.4.5">§
;1.4.5</a
>.
1223 <h4
><a name
="p3.1.4" id
="p3.1.4">3.1.4. Rules
for interpreting various name forms
</a
></h4
>
1225 Interpretation of Names is controlled by the Assurance Policy
,
1226 is administered by means of the Member
's account,
1227 and is subject to change by the Arbitrator.
1228 Changes to the interpretation by means of Arbitration
1229 should be expected as fraud (e.g., phishing)
1230 may move too quickly for policies to fully document rules.
1233 <h4><a name="p3.1.5" id="p3.1.5">3.1.5. Uniqueness of names</a></h4>
1236 Uniqueness of Names within certificates is not guaranteed.
1237 Each certificate has a unique serial number which maps
1238 to a unique account, and thus maps to a unique Member.
1239 See the Assurance Statement within Assurance Policy
1240 (<a href="http://www.cacert.org/policy/AssurancePolicy.php">COD13</a>).
1244 Domain names and email address
1245 can only be registered to one Member.
1248 <h4><a name="p3.1.6" id="p3.1.6">3.1.6. Recognition, authentication, and role of trademarks</a></h4>
1251 Organisation Assurance Policy
1252 (<a href="http://www.cacert.org/policy/OrganisationAssurancePolicy.php">COD11</a>)
1253 controls issues such as trademarks where applicable.
1254 A trademark can be disputed by filing a dispute.
1256 <a href="#adr">§9.13</a>.
1259 <h4><a name="p3.1.7" id="p3.1.7">3.1.7. International Domain Names</a></h4>
1262 Certificates containing International Domain Names, being those containing a
1263 ACE prefix (<a href="http://www.ietf.org/rfc/rfc3490#section-5">RFC3490
1264 Section 5</a>), will only be issued to domains satisfying one or more
1265 of the following conditions:
1267 <li>The Top Level Domain (TLD) Registrar associated with the domain has a policy
1268 that has taken measures to prevent two homographic domains being registered to
1269 different entities down to an accepted level.
1271 <li>Domains contain only code points from a single unicode character script,
1272 excluding the "Common" script, with the additionally allowed numberic
1273 characters [0-9], and an ACSII hyphen '-'.
1278 <p>Email address containing International Domain Names in the domain portion of
1279 the email address will also be required to satisfy one of the above conditions.
1283 The following is a list of accepted TLD Registrars:
1288 <td><a href="http://www.nic.ac/">Registry</a></td>
1289 <td><a href="http://www.nic.ac/pdf/AC-IDN-Policy.pdf">Policy</a></td>
1294 <td><a href="http://www.nic.ar/">Registry</a></td>
1295 <td><a href="http://www.nic.ar/616.html">Policy</a></td>
1299 <td><a href="http://www.nic.at/">Registry</a></td>
1300 <td><a href="http://www.nic.at/en/service/legal_information/registration_guidelines/">Policy</a> (<a href="http://www.nic.at/en/service/technical_information/idn/charset_converter/">character list</a>)</td>
1305 <td><a href="http://www.neustarregistry.biz/">Registry</a></td>
1306 <td><a href="http://www.neustarregistry.biz/products/idns">Policy</a></td>
1311 <td><a href="http://registro.br/">Registry</a></td>
1312 <td><a href="http://registro.br/faq/faq6.html">Policy</a></td>
1316 <td><a href="http://www.domini.cat/">Registry</a></td>
1318 <td><a href="http://www.domini.cat/normativa/en_normativa_registre.html">Policy</a></td>
1322 <td><a href="http://www.switch.ch/id/">Registry</a></td>
1323 <td><a href="http://www.switch.ch/id/terms/agb.html#anhang1">Policy</a></td>
1328 <td><a href="http://www.nic.cl/">Registry</a></td>
1329 <td><a href="http://www.nic.cl/CL-IDN-policy.html">Policy</a></td>
1334 <td><a href="http://www.cnnic.net.cn/">Registry</a></td>
1335 <td><a href="http://www.faqs.org/rfcs/rfc3743.html">Policy</a> (JET Guidelines)</td>
1339 <td><a href="http://www.denic.de/">Registry</a></td>
1341 <td><a href="http://www.denic.de/en/richtlinien.html">Policy</a></td>
1345 <td><a href="http://www.dk-hostmaster.dk/">Registry</a></td>
1346 <td><a href="http://www.dk-hostmaster.dk/index.php?id=151">Policy</a></td>
1351 <td><a href="https://www.nic.es/">Registry</a></td>
1352 <td><a href="https://www.nic.es/media/2008-12/1228818323935.pdf">Policy</a></td>
1357 <td><a href="http://www.ficora.fi/">Registry</a></td>
1358 <td><a href="http://www.ficora.fi/en/index/palvelut/fiverkkotunnukset/aakkostenkaytto.html">Policy</a></td>
1362 <td><a href="https://grweb.ics.forth.gr/english/index.html">Registry</a></td>
1363 <td><a href="https://grweb.ics.forth.gr/english/ENCharacterTable1.jsp">Policy</a></td>
1368 <td><a href="http://www.domain.hu/domain/">Registry</a></td>
1369 <td><a href="http://www.domain.hu/domain/English/szabalyzat.html">Policy</a> (section 2.1.2)</td>
1374 <td><a href="http://www.afilias.info/">Registry</a></td>
1375 <td><a href="http://www.afilias.info/register/idn/">Policy</a></td>
1380 <td><a href="http://www.nic.io">Registry</a></td>
1381 <td><a href="http://www.nic.io/IO-IDN-Policy.pdf">Policy</a></td>
1385 <td><a href="https://www.nic.ir/">Registry</a></td>
1386 <td><a href="https://www.nic.ir/IDN">Policy</a></td>
1391 <td><a href="http://www.isnic.is/">Registry</a></td>
1392 <td><a href="http://www.isnic.is/english/domain/rules.php">Policy</a></td>
1397 <td><a href="http://jprs.co.jp/">Registry</a></td>
1398 <td><a href="http://www.iana.org/assignments/idn/jp-japanese.html">Policy</a></td>
1402 <td><a href="http://domain.nic.or.kr/">Registry</a></td>
1404 <td><a href="http://www.faqs.org/rfcs/rfc3743.html">Policy</a> (JET Guidelines)</td>
1408 <td><a href="http://www.switch.ch/id/">Registry</a></td>
1409 <td><a href="http://www.switch.ch/id/terms/agb.html#anhang1">Policy</a> (managed by .ch registry)</td>
1414 <td><a href="http://www.domreg.lt/public?pg=&sp=&loc=en">Registry</a></td>
1415 <td><a href="http://www.domreg.lt/public?pg=8A7FB6&sp=idn&loc=en">Policy</a> (<a href="http://www.domreg.lt/static/doc/public/idn_symbols-en.pdf">character list</a>)</td>
1420 <td><a href="http://about.museum/">Registry</a></td>
1421 <td><a href="http://about.museum/idn/idnpolicy.html">Policy</a></td>
1426 <td><a href="http://www.norid.no/">Registry</a></td>
1427 <td><a href="http://www.norid.no/domeneregistrering/veiviser.en.html">Policy</a> (section 4)</td>
1432 <td><a href="http://www.pir.org/">Registry</a></td>
1433 <td><a href="http://pir.org/PDFs/ORG-Extended-Characters-22-Jan-07.pdf">Policy</a></td>
1437 <td><a href="http://www.nask.pl/">Registry</a></td>
1438 <td><a href="http://www.dns.pl/IDN/idn-registration-policy.txt">Policy</a></td>
1443 <td><a href="https://www.nic.pr/">Registry</a></td>
1444 <td><a href="https://www.nic.pr/idn_rules.asp">Policy</a></td>
1449 <td><a href="http://www.nic-se.se/">Registry</a></td>
1450 <td><a href="http://www.iis.se/en/domaner/internationaliserad-doman-idn/">Policy</a> (<a href="http://www.iis.se/docs/teckentabell-03.pdf">character list</a>)</td>
1455 <td><a href="http://www.nic.sh">Registry</a></td>
1456 <td><a href="http://www.nic.sh/SH-IDN-Policy.pdf">Policy</a></td>
1460 <td><a href="http://www.thnic.or.th/">Registry</a></td>
1462 <td><a href="http://www.iana.org/assignments/idn/th-thai.html">Policy</a></td>
1466 <td><a href="http://www.nic.tm">Registry</a></td>
1467 <td><a href="http://www.nic.tm/TM-IDN-Policy.pdf">Policy</a></td>
1472 <td><a href="http://www.twnic.net.tw/">Registry</a></td>
1473 <td><a href="http://www.faqs.org/rfcs/rfc3743.html">Policy</a> (JET Guidelines)</td>
1478 <td><a href="http://www.vnnic.net.vn/">Registry</a></td>
1479 <td><a href="http://www.vnnic.vn/english/5-6-300-2-2-04-20071115.htm">Policy</a> (<a href="http://vietunicode.sourceforge.net/tcvn6909.pdf">character list</a>)</td>
1485 This criteria will apply to the email address and server host name fields for all certificate types.
1489 The CAcert Inc. Board has the authority to decide to add or remove accepted TLD Registrars on this list.
1492 <h3><a name="p3.2" id="p3.2">3.2. Initial Identity Verification</a></h3>
1495 Identity verification is controlled by the
1496 <a href="http://svn.cacert.org/CAcert/Policies/AssurancePolicy.html">
1497 Assurance Policy</a> (<a href="http://www.cacert.org/policy/AssurancePolicy.php">COD13</a>).
1498 The reader is refered to the Assurance Policy,
1499 the following is representative and brief only.
1503 <h4><a name="p3.2.1" id="p3.2.1">3.2.1. Method to prove possession of private key</a></h4>
1506 CAcert uses industry-standard techniques to
1507 prove the possession of the private key.
1511 For X.509 server certificates,
1512 the stale digital signature of the CSR is verified.
1513 For X.509 client certificates for "Netscape" browsers,
1514 SPKAC uses a challenge-response protocol
1515 to check the private key dynamically.
1516 For X.509 client certificates for "explorer" browsers,
1517 ActiveX uses a challenge-response protocol
1518 to check the private key dynamically.
1521 <h4><a name="p3.2.2" id="p3.2.2">3.2.2. Authentication of Individual Identity</a></h4>
1525 An Internet user becomes a Member by agreeing to the
1526 CAcert Community Agreement
1527 (<a href="http://www.cacert.org/policy/CAcertCommunityAgreement.php">COD9</a>)
1528 and registering an account on the online website.
1529 During the registration process Members are asked to
1530 supply information about themselves:
1533 <li>A valid working email.
1535 <li>Full Name and Date of Birth such as is
1536 found on Identity documents.
1538 <li>Personal Questions used only for Password Retrieval.</li>
1542 The online account establishes the method of authentication
1543 for all service requests such as certificates.
1548 Each Member is assured according to Assurance Policy
1549 (<a href="http://www.cacert.org/policy/AssurancePolicy.php">COD13</a>).
1552 <!-- <center><a href="http://xkcd.com/364/"> <img src="http://imgs.xkcd.com/comics/responsible_behavior.png"> </a> </center> -->
1557 <b>Certificates.</b>
1558 Based on the total number of Assurance Points
1559 that a Member (Name) has, the Member
1560 can get different levels of certificates.
1561 See <a href="#p1.4.5">§1.4.5</a>.
1563 When Members have 50 or more points, they
1564 become <i>Assured Members</i> and may then request
1565 certificates that state their Assured Name(s).
1572 <table border="1" cellpadding="5">
1574 <th>Assurance Points</th>
1581 <td>Unassured Member</td>
1583 <td>Certificates with no Name, under Class 1 Root. Limited to 6 months expiry.</td>
1587 <td>Unassured Member</td>
1589 <td>Certificates with no Name under Member SubRoot. Limited to 6 months expiry.</td>
1592 <td rowspan="1">50-99</td>
1593 <td>Assured Member</td>
1595 <td>Certificates with Verified Name for S/MIME, web servers, "digital signing."
1596 Expiry after 24 months is available.</td>
1599 <td rowspan="2">100++</td>
1600 <td rowspan="2">Assurer</td>
1601 <td>Code-signing</td>
1602 <td>Can create Code-signing certificates </td>
1606 <span class="figure">Table 3.2.b - How Assurance Points are used in Certificates</span>
1613 <h4><a name="p3.2.3" id="p3.2.3">3.2.3. Authentication of organization identity</a></h4>
1617 Verification of organisations is delegated by
1618 the Assurance Policy to the
1619 Organisation Assurance Policy
1620 (<a href="http://www.cacert.org/policy/OrganisationAssurancePolicy.php">COD11</a>).
1621 The reader is refered to the Organisation Assurance Policy,
1622 the following is representative and brief only.
1626 Organisations present special challenges.
1627 The Assurance process for Organisations is
1628 intended to permit the organisational Name to
1629 appear in certificates.
1630 The process relies heavily on the Individual
1631 process described above.
1635 Organisation Assurance achieves the standard
1636 stated in the OAP, briefly presented here:
1640 the organisation exists,
1642 the organisation name is correct and consistent,
1644 signing rights: requestor can sign on behalf of the organisation, and
1646 the organisation has agreed to the terms of the
1647 CAcert Community Agreement
1648 (<a href="http://www.cacert.org/policy/CAcertCommunityAgreement.php">COD9</a>),
1649 and is therefore subject to Arbitration.
1653 <li> As of the current time of writing, OA lacks critical documentation and there are bugs identified with no response.</li>
1654 <li> <a href="http://wiki.cacert.org/wiki/PolicyDrafts/OrganisationAssurance">documented bugs</a>. </li>
1655 <li> Therefore Organisations will not participate in the current audit cycle of roots. </li>
1656 <li> See <a href="http://wiki.cacert.org/wiki/OrganisationAssurance">wiki</a> for any progress on this. </li>
1660 <h4><a name="p3.2.4" id="p3.2.4">3.2.4. Non-verified subscriber information</a></h4>
1663 All information in the certificate is verified,
1664 see Relying Party Statement, §4.5.2.
1668 <h4><a name="p3.2.5" id="p3.2.5">3.2.5. Validation of authority</a></h4>
1671 The authorisation to obtain a certificate is established as follows:
1676 The member claims authority over a domain or email address
1677 when adding the address, <a href="#p4.1.2">§4.1.2</a>.
1678 (Control is tested by means described in <a href="#p4.2.2">§4.2.2</a>.)
1683 The authority to participate as a Member is established
1684 by the CAcert Community Agreement
1685 (<a href="http://www.cacert.org/policy/CAcertCommunityAgreement.php">COD9</a>).
1686 Assurances are requested by means of the signed CAP form.
1690 <b>Organisations.</b>
1691 The authority for Organisation Assurance is established
1692 in the COAP form, as signed by an authorised representative
1693 of the organisation.
1694 The authority for the
1695 Organisation Administrator
1696 (O-Admin) is also established on the
1698 See Organisation Assurance Policy.
1702 <h4><a name="p3.2.6" id="p3.2.6">3.2.6. Criteria for interoperation</a></h4>
1705 CAcert does not currently issue certificates to subordinate CAs
1707 Other CAs may become Members, and are then subject to the
1708 same reliance provisions as all Members.
1711 <h3><a name="p3.3" id="p3.3">3.3. Re-key Requests</a></h3>
1714 Via the Member's account
.
1717 <h3
><a name
="p3.4" id
="p3.4">3.4. Revocations Requests
</a
></h3
>
1720 Via the Member
's account.
1721 In the event that the Member has lost the password,
1722 or similar, the Member emails the support team who
1723 either work through the lost-password questions
1724 process or file a dispute.
1729 <!-- *************************************************************** -->
1730 <h2><a name="p4" id="p4">4. CERTIFICATE LIFE-CYCLE OPERATIONAL REQUIREMENTS</a></h2>
1733 The general life-cycle for a new certificate for an Individual Member is:
1736 Member adds claim to an address (domain/email).
1738 System probes address for control.
1740 Member creates key pair.
1742 Member submits CSR with desired options (Anonymous Certificate, SSO, Root Certificate) .
1744 System validates and accepts CSR based on
1745 known information: claims, assurance, controls, technicalities.
1747 System signs certificate.
1749 System makes signed certificate available to Member.
1751 Member accepts certificate.
1757 (Some steps are not applicable, such as anonymous certificates.)
1761 <h3><a name="p4.1" id="p4.1">4.1. Certificate Application</a></h3>
1763 <h4><a name="p4.1.1" id="p4.1.1">4.1.1. Who can submit a certificate application</a></h4>
1766 Members may submit certificate applications.
1767 On issuance of certificates, Members become Subscribers.
1770 <h4><a name="p4.1.2" id="p4.1.2">4.1.2. Adding Addresses</a></h4>
1773 The Member can claim ownership or authorised control of
1774 a domain or email address on the online system.
1775 This is a necessary step towards issuing a certificate.
1776 There are these controls:
1778 The claim of ownership or control is legally significant
1779 and may be referred to dispute resolution.
1781 Each unique address can be handled by one account only.
1783 When the Member makes the claim,
1784 the certificate application system automatically initiates the
1785 check of control, as below.
1789 <h4><a name="p4.1.3" id="p4.1.3">4.1.3. Preparing CSR </a></h4>
1792 Members generate their own key-pairs.
1793 The CAcert Community Agreement
1794 (<a href="http://www.cacert.org/policy/CAcertCommunityAgreement.php">COD9</a>)
1795 obliges the Member as responsible for security.
1796 See CCA2.5, §9.6.
1800 The Certificate Signing Request (CSR) is prepared by the
1801 Member for presentation to the automated system.
1804 <h3><a name="p4.2" id="p4.2">4.2. Certificate application processing</a></h3>
1806 <!-- states what a CA does on receipt of the request -->
1809 The CA's certificate application process is completely automated
.
1810 Requests
, approvals
and rejections are handled by the website system
.
1811 Each application should be processed in less than a minute
.
1814 Where certificates are requested
for more than one
1815 purpose
, the requirements
for each purpose must be
1819 <!-- all sub headings in
4.2 are local
, not from Chokhani
. -->
1821 <h4
><a name
="p4.2.1" id
="p4.2.1">4.2.1. Authentication
</a
></h4
>
1824 The Member logs in to her account on the CAcert website
1825 and thereby authenticates herself with username
1826 and passphrase
or with her CAcert client
-side digital certificate
.
1829 <h4
><a name
="p4.2.2" id
="p4.2.2">4.2.2. Verifying Control
</a
></h4
>
1832 In principle
, at least two controls are placed on each address
.
1836 <b
><a name
="ping">Email
-Ping
</a
>.</b
>
1837 Email addresses are verified by means of an
1838 <i
><a name
="ping">Email
-Ping test
</a
></i
>:
1842 The system generates a cookie
1843 (a random
, hard
-to
-guess code
)
1844 and formats it
as a
string.
1846 The system sends the cookie
1847 to the Member in an email
.
1849 Once the Member receives the email
,
1850 she enters the cookie into the website
.
1852 The entry of the code verifies
1853 control of that email account
.
1857 <b
><a name
="email">Email Control
</a
>.</b
>
1858 Email addresses
for client certificates are verified by passing the
1862 <li
>An Email
-ping test
1863 is done on the email address
.
1865 <li
>The Member must have signed a CAP form
or equivalent
,
1866 and been awarded at least one Assurance point
.
1871 <b
><a name
="domain">Domain Control
</a
>.</b
>
1872 Domains addresses
for server certificates are verified by passing two of the
1877 is done on an email address chosen from
<i
>whois
</i
>
1878 or interpolated from the domain name
.
1880 The system generates a cookie
1881 which is then placed in DNS
1884 The system generates a cookie
1885 which is then placed in HTTP headers
or a text file on the website
1888 Statement by at least
2 Assurers about
1889 ownership
/control of the domain name
.
1891 The system generates a cookie
1892 which is then placed in whois registry information
1899 Other methods can be added from time to time by CAcert
.
1901 Static cookies should remain
for the duration of a certificate
1902 for occasional re
-testing
.
1904 Dynamic tests can be repeated at a later time of CAcert
's choosing.
1906 Domain control checks may be extended to apply to email control
1912 <li> As of the time of writing, only a singular Email-ping is implemented in the technical system. </li>
1913 <li> A further approved check is the 1 pt Assurance. </li>
1914 <li> Practically, this would mean that certificates can only be issued under Audit Roots to Members with 1 point. </li>
1915 <li> Criteria DRC C.7.f, A.2.q, A.2.i indicate registry whois reading. Also A.2.h. </li>
1916 <li> Current view is that this will be resolved in BirdShack. </li>
1919 <h4><a name="p4.2.3" id="p4.2.3">4.2.3. Options Available</a></h4>
1922 The Member has options available:
1926 <li>Each Email address that is verified
1927 is available for Client Certificates.
1929 <li>Each Domain address that is verified
1930 is available for Server Certificates.
1932 <li>If the Member is unassured then only the Member SubRoot is available.
1934 <li>If the Member is Assured then both Assured Member and Member SubRoots
1937 <li>If a Name is Assured then it may be
1938 put in a client certificate or an OpenPGP signature.
1942 <h4><a name="p4.2.4" id="p4.2.4">4.2.4. Client Certificate Procedures</a></h4>
1945 For an individual client certificate, the following is required.
1947 <li>The email address is claimed and added. </li>
1948 <li>The email address is ping-tested. </li>
1949 <li>For the Member Subroot, the Member must have
1950 at least one point of Assurance and have signed a CAP form.</li>
1951 <li>For the Assured Subroot, the Member must have
1952 at least fifty points of Assurance. </li>
1953 <li>To include a Name, the Name must be assured to at least fifty points. </li>
1958 <h4><a name="p4.2.5" id="p4.2.5">4.2.5. Server Certificate Procedures</a></h4>
1961 For a server certificate, the following is required:
1963 <li>The domain is claimed and added. </li>
1964 <li>The domain is checked twice as above. </li>
1965 <li>For the Member SubRoot, the Member must have
1966 at least one point of Assurance and have signed a CAP form.</li>
1967 <li>For the Assured SubRoot, the Member must have
1968 at least fifty points of Assurance. </li>
1973 <h4><a name="p4.2.6" id="p4.2.6">4.2.6. Code-signing Certificate Procedures</a></h4>
1976 Code-signing certificates are made available to Assurers only.
1977 They are processed in a similar manner to client certificates.
1980 <h4><a name="p4.2.7" id="p4.2.7">4.2.7. Organisation Domain Verification</a></h4>
1983 Organisation Domains are handled under the Organisation Assurance Policy
1984 and the Organisation Handbook.
1988 <li> As of time of writing, there is no Handbook for Organisation Assurers or for the Organisation, and the policy needs rework; so (audit) roots will not have OA certs .... </li>
1989 <li> <a href="http://wiki.cacert.org/wiki/PolicyDrafts/OrganisationAssurance"> Drafts </a> for ongoing story. </li>
1992 <h3><a name="p4.3" id="p4.3">4.3. Certificate issuance</a></h3>
1995 <!-- <a href="http://xkcd.com/153/"> <img align="right" src="http://imgs.xkcd.com/comics/cryptography.png"> </a> -->
1996 <h4><a name="p4.3.1" id="p4.3.1">4.3.1. CA actions during certificate issuance</a></h4>
2000 Members may request keys of any size permitted by the key algorithm.
2001 Many older hardware devices require small keys.
2006 CAcert currently only supports the RSA algorithm for X.509 keys.
2007 X.509 signing uses the SHA-1 message digest algorithm.
2008 OpenPGP Signing uses RSA signing over RSA and DSA keys.
2013 <b>Process for Certificates:</b>
2014 All details in each certificate are verified
2015 by the website issuance system.
2016 Issuance is based on a 'template
' system that selects
2017 profiles for certificate lifetime, size, algorithm.
2022 The CSR is verified.
2024 Data is extracted from CSR and verified:
2026 <li> Name §3.1, </li>
2027 <li> Email address <a href="#p4.2.2">§4.2.2</a>, </li>
2028 <li> Domain address <a href="#p4.2.2">§4.2.2</a>. </li>
2031 Certificate is generated from template.
2033 Data is copied from CSR.
2035 Certificate is signed.
2037 Certificate is stored as well as mailed.
2042 <b>Process for OpenPGP key signatures:</b>
2043 All details in each Sub-ID are verified
2044 by the website issuance system.
2045 Issuance is based on the configuration that selects
2046 the profile for signature lifetime, size,
2047 algorithm following the process:
2051 The public key is verified.
2053 Data is extracted from the key and verified (Name, Emails).
2054 Only the combinations of data in Table 4.3.1 are permitted.
2056 OpenPGP Key Signature is generated.
2058 Key Signature is applied to the key.
2060 The signed key is stored as well as mailed.
2064 <table border="1" align="center" valign="top" cellpadding="5"><tbody>
2067 <td>Verified Name</td>
2068 <td valign="top">Unverified Name<br></td>
2069 <td>Empty Name<br></td>
2072 <td>Verified email<br></td>
2073 <td><center> <font title="pass." color="green" size="+3"> ✔ </font> </center></td>
2074 <td valign="top"><center> <font title="pass." color="red" size="+3"> ✘ </font> </center></td>
2075 <td><center> <font title="pass." color="green" size="+3"> ✔ </font> </center></td>
2078 <td>Unverified email</td>
2079 <td><center> <font title="pass." color="red" size="+3"> ✘ </font> </center></td>
2080 <td valign="top"><center> <font title="pass." color="red" size="+3"> ✘ </font> </center></td>
2081 <td><center> <font title="pass." color="red" size="+3"> ✘ </font> </center></td></tr><tr><td valign="top">Empty email<br></td>
2082 <td valign="top"><center> <font title="pass." color="green" size="+3"> ✔ </font> </center></td>
2083 <td valign="top"><center> <font title="pass." color="red" size="+3"> ✘ </font> </center></td>
2084 <td valign="top"><center> <font title="pass." color="red" size="+3"> ✘ </font> </center></td>
2086 </tbody></table><br>
2088 <span class="figure">Table 4.3.1. Permitted Data in Signed OpenPgp Keys</span>
2091 <h4><a name="p4.3.2" id="p4.3.2">4.3.2. Notification to subscriber by the CA of issuance of certificate</a></h4>
2094 Once signed, the certificate is
2095 made available via the Member's account
,
2096 and emailed to the Member
.
2097 It is also archived internally
.
2100 <h3
><a name
="p4.4" id
="p4.4">4.4. Certificate acceptance
</a
></h3
>
2102 <h4
><a name
="p4.4.1" id
="p4.4.1">4.4.1. Conduct constituting certificate acceptance
</a
></h4
>
2105 There is no need
for the Member to explicitly accept the certificate
.
2106 In
case the Member does not accept the certificate
,
2107 the certificate has to be revoked
and made again
.
2110 <h4
><a name
="p4.4.2" id
="p4.4.2">4.4.2. Publication of the certificate by the CA
</a
></h4
>
2113 CAcert does not currently publish the issued certificates
2115 In the event that CAcert will run a repository
,
2116 the publication of certificates
and signatures
2117 there will be at the Member
's options.
2118 However note that certificates that are issued
2119 and delivered to the Member are presumed to be
2120 published. See §2.2.
2123 <h4><a name="p4.4.3" id="p4.4.3">4.4.3. Notification of certificate issuance by the CA to other entities</a></h4>
2126 There are no external entities that are notified about issued certificates.
2129 <h3><a name="p4.5" id="p4.5">4.5. Key pair and certificate usage</a></h3>
2132 All Members (subscribers and relying parties)
2133 are obliged according to the
2134 CAcert Community Agreement
2135 (<a href="http://www.cacert.org/policy/CAcertCommunityAgreement.php">COD9</a>)
2136 See especially 2.3 through 2.5.
2138 <h4><a name="p4.5.1" id="p4.5.1">4.5.1. Subscriber Usage and Responsibilities</a></h4>
2141 Subscribers should use keys only for their proper purpose,
2142 as indicated by the certificate, or by wider agreement with
2146 <h4><a name="p4.5.2" id="p4.5.2">4.5.2. Relying Party Usage and Responsibilities</a></h4>
2150 Relying parties (Members) may rely on the following.
2154 <table border="1" cellpadding="25"><tr><td>
2156 <big><b>Relying Party Statement</b></big>
2158 Certificates are issued to Members only.<br><br>
2159 All information in a certificate is verified.
2166 The following notes are in addition to the Relying Party Statement,
2167 and can be seen as limitations on it.
2170 <h5>4.5.2.a Methods of Verification </h5>
2172 The term Verification as used in the Relying Party Statement means one of
2174 <table border="1" cellpadding="5"><tr>
2175 <th>Type</th><th>How</th><th>Authority</th><th>remarks</th>
2177 <th>Assurance</th><td>under CAcert Assurance Programme (CAP)</td>
2178 <td>Assurance Policy</td>
2179 <td>only information assured to 50 points under CAP is placed in the certificate </td>
2181 <th>Evaluation</th><td>under automated domain and email checks </td>
2183 <td>see §4.2.2</td>
2185 <th>Controlled</th><td>programs or "profiles" that check the information within the CSR </td>
2187 <td>see §7.1</td>
2190 <h5>4.5.2.b Who may rely</h5>
2192 <b>Members may rely.</b>
2193 Relying parties are Members,
2194 and as such are bound by this CPS and the
2195 CAcert Community Agreement
2196 (<a href="http://www.cacert.org/policy/CAcertCommunityAgreement.php">COD9</a>).
2197 The licence and permission to rely is not assignable.
2201 <b>Suppliers of Software.</b>
2202 CAcert roots may be distributed in software,
2203 and those providers may
2204 enter into agreement with CAcert by means of the
2205 Third Party Vendor - Disclaimer and Licence
2207 This licence brings the supplier in to the Community
2208 to the extent that <span class="q"> ...WIP comment:</span>
2209 they agree to dispute resolution
2210 within CAcert's forum
.
2214 <li
> Just exactly what the
3PV
-DaL says is unclear
.</li
>
2215 <li
> The document itself is more a collection of ideas
.</li
>
2220 <b
>NRPs may not rely
.</b
>
2221 If not related to CAcert by means of an agreement
2222 that binds the parties to dispute resolution within CAcert
's forum,
2223 a person is a Non-Related-Person (NRP).
2224 An NRP is not permitted to rely and is not a Relying Party.
2225 For more details, see the
2226 NRP - Disclaimer and Licence (<a href="http://www.cacert.org/policy/NRPDisclaimerAndLicence.php">COD4</a>).
2229 <h5>4.5.2.c The Act of Reliance </h5>
2232 <b>Decision making.</b>
2233 Reliance means taking a decision that is in part or in whole
2234 based on the information in the certificate.
2236 A Relying Party may incorporate
2237 the information in the certificate,
2238 and the implied information such as Membership,
2239 into her decision-making.
2240 In making a decision,
2241 a Relying Party should also:
2245 include her own overall risk equation,
2247 include the general limitations of the Assurance process,
2248 certificates, and wider security considerations,
2250 make additional checks to provide more information,
2252 consider any wider agreement with the other Member, and
2254 use an appropriate protocol or custom of reliance (below).
2258 <b>Examining the Certificate.</b>
2259 A Relying Party must make her own decision in using
2260 each certificate. She must examine the certificate,
2261 a process called <i>validation</i>.
2262 Certificate-related information includes,
2263 but is not limited to:
2268 expiry time of certificate,
2270 current certificate revocation list (CRL),
2272 certificate chain and
2273 the validity check of the certificates in the chain,
2275 issuer of certificate (CAcert),
2277 SubRoot is intended for reliance (Assured, Organisation and Class 3)
2279 purpose of certificate.
2283 <b>Keeping Records.</b>
2284 Records should be kept, appropriate to the import of the decision.
2285 The certificate should be preserved.
2286 This should include sufficient
2287 evidence to establish who the parties are
2288 (especially, the certificate relied upon),
2289 to establish the transaction in question,
2290 and to establish the wider agreement that
2295 <b>Wider Protocol.</b>
2296 In principle, reliance will be part of a wider protocol
2297 (customary method in reaching and preserving agreement)
2298 that presents and preserves sufficient of the evidence
2299 for dispute resolution under CAcert's forum of Arbitration
.
2300 The protocol should be agreed amongst the parties
,
2301 and tuned to the needs
.
2302 This CPS does not define any such protocol
.
2303 In the absence of such a protocol
, reliance will be weakened
;
2304 a dispute without sufficient evidence may be dismissed by an Arbitrator
.
2308 <b
>As Compared to Usage
</b
>.
2309 Reliance goes beyond Usage
. The latter is limited to
2310 letting the software act
as the total
and only Validation
2311 Authority
. When relying
, the Member also augments
2312 the algorithmic processing of the software with her own
2313 checks of the business
, technical
and certificate aspect
.
2316 <h5
>4.5.2.d Risks
and Limitations of Reliance
</h5
>
2318 <b
>Roots
and Naming
.</b
>
2319 Where the
Class 1 root is used
,
2320 this Subscriber may be a
new Member
2321 including one with zero points
.
2322 Where the Name is not provided
,
2323 this indicates it is not available
.
2324 In these circumstances
,
2325 reliance is not defined
,
2326 and Relying parties should take more care
.
2331 <table border
="1" cellpadding
="5">
2334 <td colspan
="4"><center
><i
>Statements of Reliance
for Members
</center
></i
></td
>
2337 <td
><i
>Class of Root
</i
></td
>
2338 <td
><center
><b
>Anonymous
</b
><br
>(all Members
)</center
></td
>
2339 <td
><center
><b
>Named
</b
><br
>(Assured Members only
)</center
></td
>
2342 <td
><center
>Class<br
><big
><b
>1</b
></big
></center
></td
>
2343 <td rowspan
="2" bgcolor
="red">
2344 <b
>Do not rely
.</b
><BR
>
2345 Relying party must
use other methods to check
. </td
>
2346 <td rowspan
="2" bgcolor
="orange">
2348 Although the named Member has been Assured by CAcert
,
2349 reliance is not defined with
Class 1 root
.<BR
>
2350 (issued
for compatibility only
).</td
>
2353 <td
><center
><big
><b
>Member
</b
></big
><br
>SubRoot
</center
></td
>
2356 <td
><center
>Class<br
><big
><b
>3</b
></big
></center
></td
>
2357 <td rowspan
="2" bgcolor
="orange">
2358 Do not rely on the
Name (being available
).
2359 The Member has been Assured by CAcert
,
2360 but reliance is undefined
.</td
>
2362 The Member named in the certificate has been Assured by CAcert
.</td
>
2365 <td
><center
><big
><b
>Assured
</b
></big
><br
>SubRoot
</center
></td
>
2369 <span
class="figure">Table
4.5.2. Statements of Reliance
</span
>
2373 <b
>Software Agent
.</b
>
2374 When relying on a certificate
, relying parties should
2375 note that your software is responsible
for the way it
2376 shows you the information in a certificate
.
2377 If your software agent hides parts of the information
,
2378 your sole remedy may be to choose another software agent
.
2383 When relying on a certificate
, relying parties should
2384 note that platforms that are vulnerable to viruses
or
2385 trojans
or other weaknesses may not process any certificates
2386 properly
and may give deceptive
or fraudulent results
.
2387 It is your responsibility to ensure you are using a platform
2388 that is secured according to the needs of the application
.
2391 <h5
>4.5.2.e When something goes wrong
</h5
>
2393 In the event that an issue arises out of the Member
's reliance,
2394 her sole avenue is <b>to file dispute under DRP</b>.
2395 See <a href="#p9.13">§9.13</a>.
2396 <!-- DRC_A§A.4.d -->
2397 For this purpose, the certificate (and other evidence) should be preserved.
2401 <b>Which person?</b>
2402 Members may install certificates for other individuals or in servers,
2403 but the Member to whom the certificate is issued
2404 remains the responsible person.
2405 E.g., under Organisation Assurance, an organisation is issued
2406 a certificate for the use by individuals
2407 or servers within that organisation,
2408 but the Organisation is the responsible person.
2411 <!-- <a href="http://xkcd.com/424/"> <img align="right" src="http://imgs.xkcd.com/comics/security_holes.png"> </a> -->
2413 <b>Software Agent.</b>
2414 If a Member is relying on a CAcert root embedded in
2415 the software as supplied by a vendor,
2416 the risks, liabilities and obligations of the Member
2417 do not automatically transfer to the vendor.
2420 <h3><a name="p4.6" id="p4.6">4.6. Certificate renewal</a></h3>
2423 A certificate can be renewed at any time.
2424 The procedure of certificate renewal is the same
2425 as for the initial certificate issuance.
2428 <h3><a name="p4.7" id="p4.7">4.7. Certificate re-key</a></h3>
2431 Certificate "re-keyings" are not offered nor supported.
2432 A new certificate with a new key has to be requested and issued instead,
2433 and the old one revoked.
2436 <h3><a name="p4.8" id="p4.8">4.8. Certificate modification</a></h3>
2439 Certificate "modifications" are not offered nor supported.
2440 A new certificate has to be requested and issued instead.
2443 <h3><a name="p4.9" id="p4.9">4.9. Certificate revocation and suspension</a></h3>
2445 <h4><a name="p4.9.1" id="p4.9.1">4.9.1. Circumstances for revocation</a></h4>
2447 Certificates may be revoked under the following circumstances:
2451 As initiated by the Subscriber through her online account.
2453 As initiated in an emergency action by a
2454 support team member.
2455 Such action will immediately be referred to dispute resolution
2458 Under direction from the Arbitrator in a duly ordered ruling
2459 from a filed dispute.
2463 These are the only three circumstances under which a
2467 <h4><a name="p4.9.2" id="p4.9.2">4.9.2. Who can request revocation</a></h4>
2473 <h4><a name="p4.9.3" id="p4.9.3">4.9.3. Procedure for revocation request</a></h4>
2475 The Subscriber logs in to her online account through
2476 the website at http://www.cacert.org/ .
2480 In any other event such as lost passwords or fraud,
2481 a dispute should be filed
2483 < support AT cacert DOT org >
2486 <h4><a name="p4.9.4" id="p4.9.4">4.9.4. Revocation request grace period</a></h4>
2488 <p>No stipulation.</p>
2490 <h4><a name="p4.9.5" id="p4.9.5">4.9.5. Time within which CA must process the revocation request</a></h4>
2493 The revocation automated in the Web Interface for subscribers,
2494 and is handled generally in less than a minute.
2498 A filed dispute that requests a revocation should be handled
2499 within a five business days, however the Arbitrator has discretion.
2502 <h4><a name="p4.9.6" id="p4.9.6">4.9.6. Revocation checking requirement for relying parties</a></h4>
2505 Each revoked certificate is recorded in the
2506 certificate revocation list (CRL).
2507 Relying Parties must check a certificate against
2508 the most recent CRL issued, in order to validate
2509 the certificate for the intended reliance.
2512 <h4><a name="p4.9.7" id="p4.9.7">4.9.7. CRL issuance frequency (if applicable)</a></h4>
2515 A new CRL is issued after every certificate revocation.
2518 <h4><a name="p4.9.8" id="p4.9.8">4.9.8. Maximum latency for CRLs (if applicable)</a></h4>
2521 The maximum latency between revocation and issuance of the CRL is 1 hour.
2524 <h4><a name="p4.9.9" id="p4.9.9">4.9.9. On-line revocation/status checking availability</a></h4>
2527 OCSP is available at
2528 http://ocsp.cacert.org/ .
2531 <h4><a name="p4.9.10" id="p4.9.10">4.9.10. On-line revocation checking requirements</a></h4>
2533 Relying parties must check up-to-date status before relying.
2536 <h4><a name="p4.9.11" id="p4.9.11">4.9.11. Other forms of revocation advertisements available</a></h4>
2541 <h4><a name="p4.9.12" id="p4.9.12">4.9.12. Special requirements re key compromise</a></h4>
2543 Subscribers are obliged to revoke certificates at the earliest opportunity.
2546 <h4><a name="p4.9.13" id="p4.9.13">4.9.13. Circumstances for suspension</a></h4>
2549 Suspension of certificates is not available.
2552 <h4><a name="p4.9.14" id="p4.9.14">4.9.14. Who can request suspension</a></h4>
2557 <h4><a name="p4.9.15" id="p4.9.15">4.9.15. Procedure for suspension request</a></h4>
2562 <h4><a name="p4.9.16" id="p4.9.16">4.9.16. Limits on suspension period</a></h4>
2569 <h3><a name="p4.10" id="p4.10">4.10. Certificate status services</a></h3>
2571 <h4><a name="p4.10.1" id="p4.10.1">4.10.1. Operational characteristics</a></h4>
2574 at http://ocsp.cacert.org/ .
2577 <h4><a name="p4.10.2" id="p4.10.2">4.10.2. Service availability</a></h4>
2580 OCSP is made available on an experimental basis.
2583 <h4><a name="p4.10.3" id="p4.10.3">4.10.3. Optional features</a></h4>
2589 <h3><a name="p4.11" id="p4.11">4.11. End of subscription</a></h3>
2592 Certificates include expiry dates.
2595 <h3><a name="p4.12" id="p4.12">4.12. Key escrow and recovery</a></h3>
2597 <h4><a name="p4.12.1" id="p4.12.1">4.12.1. Key escrow and recovery policy and practices</a></h4>
2600 CAcert does not generate nor escrow subscriber keys.
2603 <h4><a name="p4.12.2" id="p4.12.2">4.12.2. Session key encapsulation and recovery policy and practices</a></h4>
2611 <!-- *************************************************************** -->
2612 <h2><a name="p5" id="p5">5. FACILITY, MANAGEMENT, AND OPERATIONAL CONTROLS</a></h2>
2614 <!-- <a href="http://xkcd.com/87/"> <img align="right" src="http://imgs.xkcd.com/comics/velociraptors.jpg"> </a> -->
2616 <h3><a name="p5.1" id="p5.1">5.1. Physical controls</a></h3>
2619 Refer to Security Policy (<a href="http://svn.cacert.org/CAcert/Policies/SecurityPolicy.html">COD8</a>)
2621 Site location and construction - SP2.1
2623 Physical access - SP2.3
2628 <h4><a name="p5.1.3" id="p5.1.3">5.1.3. Power and air conditioning</a></h4>
2630 Refer to Security Policy 2.1.2 (<a href="http://svn.cacert.org/CAcert/Policies/SecurityPolicy.html">COD8</a>)
2632 <h4><a name="p5.1.4" id="p5.1.4">5.1.4. Water exposures</a></h4>
2634 Refer to Security Policy 2.1.4 (<a href="http://svn.cacert.org/CAcert/Policies/SecurityPolicy.html">COD8</a>)
2636 <h4><a name="p5.1.5" id="p5.1.5">5.1.5. Fire prevention and protection</a></h4>
2638 Refer to Security Policy 2.1.4 (<a href="http://svn.cacert.org/CAcert/Policies/SecurityPolicy.html">COD8</a>)
2640 <h4><a name="p5.1.6" id="p5.1.6">5.1.6. Media storage</a></h4>
2642 Refer to Security Policy 4.3 (<a href="http://svn.cacert.org/CAcert/Policies/SecurityPolicy.html">COD8</a>)
2644 <h4><a name="p5.1.7" id="p5.1.7">5.1.7. Waste disposal</a></h4>
2648 <h4><a name="p5.1.8" id="p5.1.8">5.1.8. Off-site backup</a></h4>
2650 Refer to Security Policy 4.3 (<a href="http://svn.cacert.org/CAcert/Policies/SecurityPolicy.html">COD8</a>)
2653 <h3><a name="p5.2" id="p5.2">5.2. Procedural controls</a></h3>
2655 <h4><a name="p5.2.1" id="p5.2.1">5.2.1. Trusted roles</a></h4>
2658 <li><b> Technical teams:</b>
2660 <li>User support personnel</li>
2661 <li>Systems Administrators -- critical and non-critical</li>
2662 <li>Softare Developers</li>
2663 <li>controllers of keys</li>
2665 Refer to Security Policy 9.1 (<a href="http://svn.cacert.org/CAcert/Policies/SecurityPolicy.html">COD8</a>)
2669 <li><b>Assurance:</b>
2672 <li> Any others authorised under COD13 </li>
2674 Refer to Assurance Policy (<a href="http://www.cacert.org/policy/AssurancePolicy.php">COD13</a>)
2677 <li><b>Governance:</b>
2679 <li>Directors (members of the CAcert Inc. committee, or "Board") </li>
2680 <li>Internal Auditor</li>
2687 <h4><a name="p5.2.2" id="p5.2.2">5.2.2. Number of persons required per task</a></h4>
2689 CAcert operates to the principles of <i>four eyes</i> and <i>dual control</i>.
2690 All important roles require a minimum of two persons.
2691 The people may be tasked to operate
2692 with an additional person observing (<i>four eyes</i>),
2693 or with two persons controlling (<i>dual control</i>).
2696 <h4><a name="p5.2.3" id="p5.2.3">5.2.3. Identification and authentication for each role</a></h4>
2699 All important roles are generally required to be assured
2700 at least to the level of Assurer, as per AP.
2701 Refer to Assurance Policy (<a href="http://www.cacert.org/policy/AssurancePolicy.php">COD13</a>).
2706 Refer to Security Policy 9.1 (<a href="http://svn.cacert.org/CAcert/Policies/SecurityPolicy.html">COD8</a>).
2709 <h4><a name="p5.2.4" id="p5.2.4">5.2.4. Roles requiring separation of duties</a></h4>
2712 Roles strive in general for separation of duties, either along the lines of
2713 <i>four eyes principle</i> or <i>dual control</i>.
2716 <h3><a name="p5.3" id="p5.3">5.3. Personnel controls</a></h3>
2718 <h4><a name="p5.3.1" id="p5.3.1">5.3.1. Qualifications, experience, and clearance requirements</a></h4>
2721 <table border="1" cellpadding="5">
2723 <td><b>Role</b></td> <td><b>Policy</b></td> <td><b>Comments</b></td>
2726 <td><a href="http://www.cacert.org/policy/AssurancePolicy.php"> COD13</td>
2728 Passes Challenge, Assured to 100 points.
2731 <td>Organisation Assurer</td>
2732 <td><a href="http://www.cacert.org/policy/OrganisationAssurancePolicy.php">COD11</a></td>
2734 Trained and tested by two supervising OAs.
2738 <td>SM => COD08</td>
2740 Teams responsible for testing.
2744 <td><a href="http://www.cacert.org/policy/DisputeResolutionPolicy.php">COD7</a></td>
2746 Experienced Assurers.
2751 <span class="figure">Table 5.3.1. Controls on Roles</span>
2755 <h4><a name="p5.3.2" id="p5.3.2">5.3.2. Background check procedures</a></h4>
2758 Refer to Security Policy 9.1.3 (<a href="http://svn.cacert.org/CAcert/Policies/SecurityPolicy.html">COD8</a>).
2760 <!-- <a href="http://xkcd.com/538/"> <img align="right" src="http://imgs.xkcd.com/comics/security.png"> </a> -->
2762 <h4><a name="p5.3.3" id="p5.3.3">5.3.3. Training requirements</a></h4>
2763 <p>No stipulation.</p>
2764 <h4><a name="p5.3.4" id="p5.3.4">5.3.4. Retraining frequency and requirements</a></h4>
2765 <p>No stipulation.</p>
2767 <h4><a name="p5.3.5" id="p5.3.5">5.3.5. Job rotation frequency and sequence</a></h4>
2768 <p>No stipulation.</p>
2770 <h4><a name="p5.3.6" id="p5.3.6">5.3.6. Sanctions for unauthorized actions</a></h4>
2772 Any actions that are questionable
2773 - whether uncertain or grossly negligent -
2774 may be filed as a dispute.
2775 The Arbitrator has wide discretion in
2776 ruling on loss of points, retraining,
2777 or termination of access or status.
2781 <h4><a name="p5.3.7" id="p5.3.7">5.3.7. Independent contractor requirements</a></h4>
2782 <p>No stipulation.</p>
2784 <h4><a name="p5.3.8" id="p5.3.8">5.3.8. Documentation supplied to personnel</a></h4>
2785 <p>No stipulation.</p>
2787 <h3><a name="p5.4" id="p5.4">5.4. Audit logging procedures</a></h3>
2790 Refer to Security Policy 4.2, 5 (<a href="http://svn.cacert.org/CAcert/Policies/SecurityPolicy.html">COD8</a>).
2793 <h3><a name="p5.5" id="p5.5">5.5. Records archival</a></h3>
2795 The standard retention period is 7 years.
2796 Once archived, records can only be obtained and verified
2797 by means of a filed dispute.
2798 Following types of records are archived:
2802 <table border="1" cellpadding="5">
2804 <td><b>Record</b></td>
2805 <td><b>Nature</b></td>
2806 <td><b>Exceptions</b></td>
2807 <td><b>Documentation</b></td>
2811 <td>username, primary and added addresses, security questions, Date of Birth</td>
2812 <td>resigned non-subscribers: 0 years.</td>
2813 <td>Security Policy and Privacy Policy</td>
2818 <td>"at least 7 years."<br> as per subsidiary policies</td>
2819 <td>Assurance Policy 4.5</td>
2822 <td>Organisation Assurance</td>
2824 <td>as per subsidiary policies</td>
2825 <td>Organisation Assurance Policy</td>
2828 <td>certificates and revocations</td>
2829 <td> for reliance </td>
2830 <td> 7 years after termination </td>
2834 <td>critical roles</td>
2835 <td>background check worksheets</td>
2836 <td>under direct Arbitrator control</td>
2837 <td>Security Policy 9.1.3</td>
2841 <span class="figure">Table 5.5. Documents and Retention </span>
2845 <h3><a name="p5.6" id="p5.6">5.6. Key changeover</a></h3>
2848 Refer to Security Policy 9.2 (<a href="http://svn.cacert.org/CAcert/Policies/SecurityPolicy.html">COD8</a>).
2851 <h3><a name="p5.7" id="p5.7">5.7. Compromise and disaster recovery</a></h3>
2854 Refer to Security Policy 5, 6 (<a href="http://svn.cacert.org/CAcert/Policies/SecurityPolicy.html">COD8</a>).
2855 (Refer to <a href="#p1.4">§1.4</a> for limitations to service.)
2860 <h3><a name="p5.8" id="p5.8">5.8. CA or RA termination</a></h3>
2862 <h4><a name="p5.8.1" id="p5.8.1">5.8.1 CA termination</a></h4>
2867 If CAcert should terminate its operation or be
2868 taken over by another organisation, the actions
2869 will be conducted according to a plan approved
2870 by the CAcert Inc. Board.
2875 In the event of operational termination, the
2876 Roots (including SubRoots)
2877 and all private Member information will be secured.
2878 The Roots will be handed over to a responsible
2879 party for the sole purpose of issuing revocations.
2880 Member information will be securely destroyed.
2883 <span class="change">
2885 The CA cannot be transferrred to another organisation.
2891 In the event of takeover,
2892 the Board will decide if it is in the interest
2893 of the Members to be converted to the
2895 Members will be notified about the conversion
2896 and transfer of the Member information.
2897 Such takeover, conversion or transfer may involve termination
2898 of this CPS and other documents.
2900 Members will have reasonable time in which to file a related
2901 dispute after notification
2902 (at least one month).
2908 <li> The ability to transfer is not given in any of CCA, PP or AP! </li>
2909 <li> The Board does not have the power to terminate a policy, that is the role of policy group! </li>
2910 <li> The right to transfer was against the principles of the CAcert? </li>
2911 <li> Check Association Statutes.... </li>
2915 <span class="change">
2918 New root keys and certificates will be made available
2919 by the new organisation as soon as reasonably practical.
2924 <h4><a name="p5.8.2" id="p5.8.2">5.8.2 RA termination</a></h4>
2927 When an Assurer desires to voluntarily terminates
2928 her responsibilities, she does this by filing a dispute,
2929 and following the instructions of the Arbitrator.
2933 In the case of involuntary termination, the process is
2934 the same, save for some other party filing the dispute.
2941 <!-- *************************************************************** -->
2942 <h2><a name="p6" id="p6">6. TECHNICAL SECURITY CONTROLS</a></h2>
2945 <!-- <a href="http://xkcd.com/221/"> <img align="right" src="http://imgs.xkcd.com/comics/random_number.png"> </a> -->
2947 <h3><a name="p6.1" id="p6.1">6.1. Key Pair Generation and Installation</a></h3>
2949 <h4><a name="p6.1.1" id="p6.1.1">6.1.1. Key Pair Generation</a></h4>
2952 Subscribers generate their own Key Pairs.
2955 <h4><a name="p6.1.2" id="p6.1.2">6.1.2. Subscriber Private key security</a></h4>
2958 There is no technical stipulation on how Subscribers generate
2959 and keep safe their private keys,
2960 however, CCA 2.5 provides for general security obligations.
2961 See <a href="#p9.6">§9.6</a>.
2964 <h4><a name="p6.1.3" id="p6.1.3">6.1.3. Public Key Delivery to Certificate Issuer</a></h4>
2967 Members login to their online account.
2968 Public Keys are delivered by cut-and-pasting
2969 them into the appropriate window.
2970 Public Keys are delivered in signed-CSR form
2971 for X.509 and in self-signed form for OpenPGP.
2974 <h4><a name="p6.1.4" id="p6.1.4">6.1.4. CA Public Key delivery to Relying Parties</a></h4>
2977 The CA root certificates are distributed by these means:
2981 Published on the website of CAcert,
2982 in both HTTP and HTTPS.
2984 Included in Third-Party Software such as
2985 Browsers, Email-Clients.
2986 Such suppliers are subject to the Third Party Vendor Agreement.
2989 <p class="q"> Third Party Vendor Agreement is early wip, only </p>
2991 <h4><a name="p6.1.5" id="p6.1.5">6.1.5. Key sizes</a></h4>
2994 No limitation is placed on Subscriber key sizes.
2998 CAcert X.509 root and intermediate keys are currently 4096 bits.
2999 X.509 roots use RSA and sign with the SHA-1 message digest algorithm.
3000 See <a href="#p4.3.1">§4.3.1</a>.
3004 OpenPGP Signing uses both RSA and DSA (1024 bits).
3008 CAcert adds larger keys and hashes
3009 in line with general cryptographic trends,
3010 and as supported by major software suppliers.
3014 <li> old Class 3 SubRoot is signed with MD5 </li>
3015 <li> likely this will clash with future plans of vendors to drop acceptance of MD5</li>
3016 <li> Is this a concern? </li>
3017 <li> to users who have these certs, a lot? </li>
3018 <li> to audit, not much? </li>
3022 <h4><a name="p6.1.6" id="p6.1.6">6.1.6. Public key parameters generation and quality checking</a></h4>
3028 <h4><a name="p6.1.7" id="p6.1.7">6.1.7. Key Usage Purposes</a></h4>
3032 <li> This section probably needs to detail the key usage bits in the certs. </li>
3037 CAcert roots are general purpose.
3038 Each root key may sign all of the general purposes
3039 - client, server, code.
3043 The website controls the usage purposes that may be signed.
3044 This is effected by means of the 'template
' system.
3049 <!-- <a href="http://xkcd.com/257/"> <img align="right" src="http://imgs.xkcd.com/comics/code_talkers.png"> </a> -->
3051 <h3><a name="p6.2" id="p6.2">6.2. Private Key Protection and Cryptographic Module Engineering Controls</a></h3>
3056 <h4><a name="p6.2.1" id="p6.2.1">6.2.1. Cryptographic module standards and controls</a></h4>
3059 SubRoot keys are stored on a single machine which acts
3060 as a Cryptographic Module, or <i>signing server</i>.
3061 It operates a single daemon for signing only.
3062 The signing server has these security features:
3066 It is connected only by one
3067 dedicated (serial USB) link
3068 to the online account server.
3069 It is not connected to the network,
3070 nor to any internal LAN (ethernet),
3071 nor to a console switch.
3073 The protocol over the dedicated link is a custom, simple
3074 request protocol that only handles certificate signing requests.
3076 The daemon is designed not to reveal the key.
3078 The daemon incorporates a dead-man switch that monitors
3079 the one webserver machine that requests access.
3081 The daemon shuts down if a bad request is detected.
3083 The daemon resides on an encrypted partition.
3085 The signing server can only be (re)started with direct
3086 systems administration access.
3088 Physical Access to the signing server is under dual control.
3092 See §5. and the Security Policy 9.3.1.
3096 (Hardware-based, commercial and standards-based cryptographic
3097 modules have been tried and tested, and similar have been tested,
3098 but have been found wanting, e.g., for short key lengths and
3099 power restrictions.)
3103 What document is responsible for architecture? CPS? SM?
3104 <a href="http://www.cacert.org/help.php?id=7">website</a>?
3105 SM punts it to CPS, so above stays.
3107 There is no criteria on Architecture.
3109 Old questions moved to SM.
3112 <a href="http://www.cacert.org/help.php?id=7">
3113 CAcert Root key protection</a> which should be deprecated by this CPS.
3117 <h3><a name="p6.3" id="p6.3">6.3. Other aspects of key pair management</a></h3>
3118 <h4><a name="p6.3.1" id="p6.3.1">6.3.1. Public key archival</a></h4>
3121 Subscriber certificates, including public keys,
3122 are stored in the database backing the online system.
3123 They are not made available in a public- or subscriber-accessible
3124 archive, see §2.
3125 They are backed-up by CAcert's normal backup procedure
,
3126 but their availability is a subscriber responsibility
.
3129 <h4
><a name
="p6.3.2" id
="p6.3.2">6.3.2. Certificate operational periods
and key pair usage periods
</a
></h4
>
3132 The operational period of a certificate
and its key pair
3133 depends on the Assurance status of the Member
,
3134 see
<a href
="#p1.4.5">§
;1.4.5</a
> and Assurance
Policy (<a href
="http://www.cacert.org/policy/AssurancePolicy.php">COD13
</a
>).
3138 The
CAcert (top
-level
) Root certificate
3139 has a
30 year expiry
.
3140 SubRoots have
10 years
, and are to be rolled over more quickly
.
3141 The keysize of the root certificates are chosen
3142 in order to ensure an optimum security to CAcert
3143 Members based on current recommendations from the
3144 <a href
="http://www.keylength.com/">cryptographic community
</a
>
3145 and maximum limits in generally available software
.
3146 At time of writing this is
4096 bits
.
3149 <h3
><a name
="p6.4" id
="p6.4">6.4. Activation data
</a
></h3
>
3150 <p
> No stipulation
. </p
>
3152 <h3
><a name
="p6.5" id
="p6.5">6.5. Computer security controls
</a
></h3
>
3154 Refer to Security Policy
.
3157 <h3
><a name
="p6.6" id
="p6.6">6.6. Life cycle technical controls
</a
></h3
>
3159 Refer to SM7
"Software Development".
3162 <h3
><a name
="p6.7" id
="p6.7">6.7. Network security controls
</a
></h3
>
3164 Refer to SM3
.1
"Logical Security - Network".
3167 <h3
><a name
="p6.8" id
="p6.8">6.8. Time
-stamping
</a
></h3
>
3169 Each server synchronises with NTP
.
3170 No
"timestamping" service is currently offered
.
3174 <li
> How does the signing server syncronise
if only connected over serial?
</li
>
3175 <li
> How is timestamping done on records?
</li
>
3181 <!-- *************************************************************** -->
3182 <h2
><a name
="p7" id
="p7">7. CERTIFICATE
, CRL
, AND OCSP PROFILES
</a
></h2
>
3185 CAcert defines all the meanings
, semantics
and profiles
3186 applicable to issuance of certificates
and signatures
3187 in its policies
, handbooks
and other documents
.
3188 Meanings that may be written in external standards
or documents
3189 or found in wider conventions are not
3190 incorporated
, are not used by CAcert
, and must not be implied
3191 by the Member
or the Non
-related Person
.
3194 <h3
><a name
="p7.1" id
="p7.1">7.1. Certificate profile
</a
></h3
>
3195 <h4
><a name
="p7.1.1" id
="p7.1.1">7.1.1. Version
number(s
)</a
></h4
>
3196 <p
class="q"> What versions of PGP are signed? v3? v4?
</p
>
3199 Issued X
.509 certificates are of v3 form
.
3200 The form of the PGP signatures depends on several factors
, therefore no stipulation
.
3203 <h4
><a name
="p7.1.2" id
="p7.1.2">7.1.2. Certificate extensions
</a
></h4
>
3206 Client certificates
include the following extensions
:.
3209 basicConstraints
=CA
:FALSE (critical
)
3211 keyUsage
=digitalSignature
,keyEncipherment
,cRLSign
3214 extendedKeyUsage
=emailProtection
,clientAuth
,serverAuth
,msEFS
,msSGC
,nsSGC
3216 authorityInfoAccess
= OCSP
;URI
:http
://ocsp.cacert.org
3218 subjectAltName
=(as per
<a href
="#p3.1.1">§
;3.1.1.</a
>).
3221 <li
> what about Client Certificates Adobe Signing extensions ?
</li
>
3222 <li
> SubjectAltName should become critical
if DN is removed http
://tools.ietf.org/html/rfc5280#section-4.2.1.6</li>
3227 Server certificates
include the following extensions
:
3230 basicConstraints
=CA
:FALSE (critical
)
3232 keyUsage
=digitalSignature
,keyEncipherment
3234 extendedKeyUsage
=clientAuth
,serverAuth
,nsSGC
,msSGC
3236 authorityInfoAccess
= OCSP
;URI
:http
://ocsp.cacert.org
3238 subjectAltName
=(as per
<a href
="#p3.1.1">§
;3.1.1.</a
>).
3242 Code
-Signing certificates
include the following extensions
:
3246 basicConstraints
=CA
:FALSE (critical
)
3248 keyUsage
=digitalSignature
,keyEncipherment
3250 extendedKeyUsage
=emailProtection
,clientAuth
,codeSigning
,msCodeInd
,msCodeCom
,msEFS
,msSGC
,nsSGC
3252 authorityInfoAccess
= OCSP
;URI
:http
://ocsp.cacert.org
3255 <li
> what about subjectAltName
for Code
-signing
</li
>
3259 OpenPGP key signatures currently
do not
include extensions
.
3260 In the future
, a serial number might be included
as an extension
.
3264 <h4
><a name
="p7.1.3" id
="p7.1.3">7.1.3. Algorithm
object identifiers
</a
></h4
>
3269 <h4
><a name
="p7.1.4" id
="p7.1.4">7.1.4. Name forms
</a
></h4
>
3271 Refer to
<a href
="#p3.1.1">§
;3.1.1</a
>.
3274 <h4
><a name
="p7.1.5" id
="p7.1.5">7.1.5. Name constraints
</a
></h4
>
3276 Refer to
<a href
="#p3.1.1">§
;3.1.1</a
>.
3279 <h4
><a name
="p7.1.6" id
="p7.1.6">7.1.6. Certificate policy
object identifier
</a
></h4
>
3281 The following OIDs are defined
and should be incorporated
3285 <table border
="1" cellpadding
="5">
3299 1.3.6.1.4.1.18506.4.4
3302 Certification Practice Statement
3305 (this present document
)
3311 Versions are defined by additional numbers appended such
as .1.
3314 <h4
><a name
="p7.1.7" id
="p7.1.7">7.1.7. Usage of Policy Constraints extension
</a
></h4
>
3319 <h4
><a name
="p7.1.8" id
="p7.1.8">7.1.8. Policy qualifiers syntax
and semantics
</a
></h4
>
3324 <h4
><a name
="p7.1.9" id
="p7.1.9">7.1.9. Processing semantics
for the critical Certificate Policies extension
</a
></h4
>
3330 <h3
><a name
="p7.2" id
="p7.2">7.2. CRL profile
</a
></h3
>
3331 <h4
><a name
="p7.2.1" id
="p7.2.1">7.2.1. Version
number(s
)</a
></h4
>
3333 CRLs are created in X
.509 v2 format
.
3336 <h4
><a name
="p7.2.2" id
="p7.2.2">7.2.2. CRL
and CRL entry extensions
</a
></h4
>
3342 <h3
><a name
="p7.3" id
="p7.3">7.3. OCSP profile
</a
></h3
>
3343 <h4
><a name
="p7.3.1" id
="p7.3.1">7.3.1. Version
number(s
)</a
></h4
>
3345 The OCSP responder operates in Version
1.
3347 <h4
><a name
="p7.3.2" id
="p7.3.2">7.3.2. OCSP extensions
</a
></h4
>
3354 <!-- *************************************************************** -->
3355 <h2
><a name
="p8" id
="p8">8. COMPLIANCE AUDIT
AND OTHER ASSESSMENTS
</a
></h2
>
3358 There are two major threads of assessment
:
3362 <b
>Systems Audit
</b
>.
3363 Analyses the CA
for business
and operations security
.
3364 This is conducted in two phases
: documents
for compliance
3365 with criteria
, and operations
for compliance with documentation
.
3368 Analyses the source code
.
3369 This is conducted at two levels
:
3370 Security concepts at the web applications level
,
3371 and source code security
and bugs review
.
3375 See the Audit page at
3376 <a href
="http://wiki.cacert.org/wiki/Audit/">
3377 wiki
.cacert
.org
/wiki
/Audit
/</a
>
3378 for more information
.
3381 <h3
><a name
="p8.1" id
="p8.1">8.1. Frequency
or circumstances of assessment
</a
></h3
>
3383 The first audits started in late
2005,
3384 and since then
, assessments have been an
3386 Even when completed
, they are expected to
3387 be permanent features
.
3391 <b
>Systems Audit
</b
>.
3393 The first phase of the first audit is nearing completion
.
3394 The second phase starts in earnest when documentation is in
3395 effect
, at lease
as DRAFT under PoP
.
3396 As the second phase is dependent on
3397 this CPS
and the Security Policy
, they will
3398 be in effect
as DRAFT at least
3399 before the first audit is completed
.
3400 Only prior
and completed audits can be reported here
.
3405 A complete review of entire source code has not yet been completed
.
3409 <h3
><a name
="p8.2" id
="p8.2">8.2. Identity
/qualifications of assessor
</a
></h3
>
3412 <b
>Systems Auditors
.</b
>
3413 CAcert uses business systems auditors with broad experience
3414 across the full range of business
, information systems
3415 and security fields
.
3416 In selecting a business systems auditor
, CAcert looks
for
3417 experience that includes but is not limited to
3418 cryptography
, PKI
, governance
, auditing
,
3419 compliance
and regulatory environments
,
3420 business strategy
, software engineering
,
3421 networks
, law (including multijurisdictional issues
),
3422 identity systems
, fraud
, IT management
.
3425 <!-- <center
><a href
="http://xkcd.com/511/"> <img src
="http://imgs.xkcd.com/comics/sleet.png"> </a
> </center
> -->
3428 <b
>Code Auditors
.</b
>
3429 See Security Policy
, sections
7, 9.1.
3432 <h3
><a name
="p8.3" id
="p8.3">8.3. Assessor
's relationship to assessed entity</a></h3>
3435 Specific internal restrictions on audit personnel:
3439 Must be Assured by CAcert Assurers
3440 and must be background checked.
3442 Must not have been active in any (other) role in CAcert.
3443 Specifically, must not be an Assurer, a member of the association,
3444 or in any other defined role or office.
3446 Although the Auditor may be expected to undertake various
3447 of the activities (Assurance, Training)
3448 during the process of the audit, any results are frozen
3449 until resignation as auditor is effected.
3451 The Auditor is required to declare to CAcert all
3452 potential conflicts of interest on an ongoing basis.
3456 Specific external restrictions on audit personnel:
3460 Should have a verifiable and lengthy history in
3461 user privacy and user security.
3463 Must not have worked for a competitive organisation.
3465 Must not have worked for national security, intelligence,
3466 LEO or similar agencies.
3470 An Auditor may convene an audit team.
3471 The same restrictions apply in general
3472 to all members of the team, but may be varied.
3473 Any deviations must be documented and approved
3474 by the CAcert Inc. Board.
3477 <h3><a name="p8.4" id="p8.4">8.4. Topics covered by assessment</a></h3>
3480 Systems Audits are generally conducted to criteria.
3481 CAcert requires that the criteria are open:
3486 The criteria must be reviewable by all interested parties.
3489 They should be understandable, in that they provide the
3490 sufficient information in a readable form for interested
3491 parties to follow the gist and importance.
3492 (Arcane security criteria may stretch this requirement.)
3495 There must be sufficent background information that the
3496 whole story is there. Especially, criteria that refer
3497 to undocumented practices or conventions deliberately
3498 kept secret must be avoided.
3500 Applicable. The criteria should relate directly
3501 and unambiguously to a need of the identified interested parties
projects / cacert-devel.git / blob