You cannot select more than 25 topics
Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
392 lines
14 KiB
HTML
392 lines
14 KiB
HTML
<?xml version="1.0" encoding="utf-8"?>
|
|
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN"
|
|
"http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd">
|
|
<html xmlns="http://www.w3.org/1999/xhtml">
|
|
<head>
|
|
<title> CACert -- TTP-Assisted Assurance Policy </title>
|
|
<style type="text/css">
|
|
<!--
|
|
.q {
|
|
color : green;
|
|
text-indent : 2em;
|
|
font-weight: bold;
|
|
font-style:italic;
|
|
}
|
|
.error {
|
|
color : red;
|
|
font-weight: bold;
|
|
text-align: center;
|
|
font-style:italic;
|
|
}
|
|
.change {
|
|
color : blue;
|
|
font-weight: bold;
|
|
}
|
|
.strike {
|
|
color : blue;
|
|
text-decoration:line-through;
|
|
}
|
|
-->
|
|
</style>
|
|
|
|
</head>
|
|
|
|
<body>
|
|
<h1> TTP-Assisted Assurance Policy </h1>
|
|
|
|
<p>
|
|
<a href="PolicyOnPolicy.html"><img align="right" src="images/cacert-wip.png" alt="CAcert Policy Status" height="31" width="88" style="border-style: none;" /></a>
|
|
Editor: Iang<br />
|
|
Creation Date : <a href="//svn.cacert.org/CAcert/Assurance/Minutes/20091215HamburgMiniTOP.html">20091215</a><br />
|
|
Status: WIP 2010916 <i>under vote <a href="//wiki.cacert.org/PolicyDecisions#p20100913">p20100913</a></i><br />
|
|
Licence: <a href="//wiki.cacert.org/Policy#Licence" title="this document is Copyright © CAcert Inc., licensed openly under CC-by-sa with all disputes resolved under DRP. More at wiki.cacert.org/Policy" > CC-by-sa+DRP </a><br />
|
|
</p>
|
|
|
|
<h2 id="s0"> 0. Preliminaries </h2>
|
|
<p>
|
|
This sub-policy extends the
|
|
<a href="//www.cacert.org/policy/AssurancePolicy.php">
|
|
Assurance Policy</a> ("AP" => COD13)
|
|
by specifying how Assurers can be assisted by
|
|
outsourcing the identity documents verification
|
|
component of assurance to trusted third parties (TTPs).
|
|
<span class="change">Other</span>
|
|
definitions and terms can be found in AP or in
|
|
<a href="//wiki.cacert.org/AssuranceHandbook">Assurance Handbook</a>
|
|
("AH").
|
|
</p>
|
|
|
|
<h2 id="s1"> 1. Scope </h2>
|
|
<p>
|
|
This sub-policy is restricted to members located
|
|
in areas not well-served with Assurers.
|
|
It serves a goal of promoting both Assurers and Members in those areas.
|
|
</p>
|
|
|
|
<h2 id="s2"> 2. Roles </h2>
|
|
|
|
<h3 id="s2.1"> 2.1 Trusted Third Party </h3>
|
|
<p>
|
|
A Trusted Third Party ("TTP") is a person who is traditionally respected
|
|
for making reliable statements to others, especially over identification
|
|
documents. Typically, notaries public (anglo),
|
|
Notaries (European), bank managers, accountants
|
|
and lawyers.
|
|
</p>
|
|
|
|
<h3 id="s2.2"> 2.2 The Assurer (aka TTP-admin) </h3>
|
|
<p class="q">uli: (Synonyms: TTP-Assurer, TTP-Admin)</p>
|
|
<p>
|
|
To employ a TTP in an assurance,
|
|
the Assurer must be a <a href="//wiki.cacert.org/SeniorAssurer">Senior Assurer</a>.
|
|
The Assurer must be familiar with the local
|
|
language and customs.
|
|
</p>
|
|
|
|
<h3 id="s2.3"> 2.3 Member </h3>
|
|
|
|
<p>
|
|
A Member ("assuree") who is located in a place not well-served
|
|
by Assurers may use the TTP-assisted assurance.
|
|
</p>
|
|
|
|
<h2 id="s3"> 3. The Assurance </h2>
|
|
|
|
<p>
|
|
Assurance assisted by TTP must meet these requirements:
|
|
</p>
|
|
<ol type="a"><li>
|
|
The Assurer must positively confirm the identity and
|
|
suitability of the TTP.
|
|
</li><li>
|
|
The TTP and the Member must meet face-to-face.
|
|
</li><li>
|
|
The TTP confirms the details supporting the Assurance Statement.
|
|
</li><li>
|
|
The Assurer makes a reliable statement to confirm the
|
|
Assurance Statement.
|
|
</li><li>
|
|
Assurance must be marked as TTP-Assisted
|
|
(e.g., by use of TTPAdmin flag).
|
|
</li></ol>
|
|
|
|
|
|
<p class="q"> See Appendix A for example text for Handbook text.</p>
|
|
|
|
<h2 id="s4"> 4. Assurance Officer ("AO") </h2>
|
|
<p>
|
|
The Board routinely delegates its responsibilities to the
|
|
Assurance Officer (and this section assumes that, but does
|
|
not require it).
|
|
</p>
|
|
|
|
<p>
|
|
A report is requested annually from the Assurance Officer
|
|
on performance of this policy for the association's
|
|
annual report.
|
|
</p>
|
|
<h3 id="s4.1"> 4.1 Practice </h3>
|
|
<p>
|
|
Assurance Officer should prepare
|
|
a detailed documentation under
|
|
<a href="//wiki.cacert.org/AssuranceHandbook">AH</a>
|
|
that meets the needs of this policy, including:
|
|
</p>
|
|
<ul><li>
|
|
Form for TTPs
|
|
</li><li>
|
|
Guide for TTPs.
|
|
</li><li>
|
|
Form for TTP-assisted assurance (used by Assurer)
|
|
</li><li>
|
|
Guide and protocol
|
|
<span class="q"> (Appendix A below)</span>
|
|
for Assurers.
|
|
</li><li>
|
|
Mechanisms for contacting Assurers available for
|
|
TTP-assisted assurances.
|
|
</li><li>
|
|
Definition of
|
|
<a href="//wiki.cacert.org/SeniorAssurer">
|
|
Senior Assurer</a>.
|
|
</li></ul>
|
|
|
|
<h3 id="s4.2"> 4.2 Deserts </h3>
|
|
<p>
|
|
The Assurance Officer maintains a list of regions
|
|
that are designated as '<i>deserts,</i>' being areas that are so short
|
|
of Assurers as to render face-to-face Assurance impractical.
|
|
In each region, approved types of TTP are listed (e.g., Notary).
|
|
The list is expected to vary according to the
|
|
different juridical traditions of different regions.
|
|
Changes to the regional lists are prepared by
|
|
either an Organisation Assurer for that region
|
|
(as described by OAP)
|
|
or by two Assurers familiar with the traditions
|
|
in that region.
|
|
Changes are then submitted to the Board for approval.
|
|
</p>
|
|
<p>
|
|
Use of a type of TTP not on the list must be approved by
|
|
AO and notified to Board.
|
|
It is an explicit goal to reduce the usage of
|
|
TTP-assisted assurances in favour of face-to-face Assurance.
|
|
<p>
|
|
|
|
<p>
|
|
In coordination with internal and external auditors,
|
|
the Assurance Officer shall design and implement a
|
|
suitable programme to meet the needs of audit.
|
|
Where approved by auditors or Board, the Assurance
|
|
Officer may document and implement minor variations to this policy.
|
|
</p>
|
|
|
|
<h2 id="s5"> 5. Topup Assurance <span class="strike">Points</span> </h2>
|
|
|
|
<p>
|
|
AO is to operate a <cite>Topup Assurance Programme</cite>
|
|
to help seed deserts with Assurers.
|
|
<span class="change">
|
|
A topup assurance will add additional Assurance Points
|
|
to those gained from two previously conducted TTP-assisted assurances,
|
|
in order for a Member to reach 100 Assurance Points
|
|
for the express purpose of becoming an Assurer.
|
|
</span>
|
|
</p>
|
|
|
|
<p>
|
|
A topup assurance is conducted by a third Senior Assurer
|
|
according to the following requirements:
|
|
</p>
|
|
|
|
<ol><li>
|
|
Assurer Challenge must be completed as passed by Member.
|
|
</li><li>
|
|
The topup must be requested by Member for
|
|
purpose of enabling the Member to reach Assurer level.
|
|
</li><li>
|
|
Topup Assurer must be a Senior Assurer,
|
|
<span class="change">
|
|
and must be independent of the TTP-assist Assurers.
|
|
</span>
|
|
</li><li>
|
|
<span class="change">
|
|
The Topup Assurer reviews the two TTP-assisted assurances,
|
|
and conducts other checks as set by the Assurance Officer.
|
|
The normal face-to-face meeting is not conducted.
|
|
</span>
|
|
<span class="strike">
|
|
The two TTP-Assisted Assurances already conducted are to be reviewed.
|
|
</span>
|
|
</li><li>
|
|
Topup Assurer may award up to 35 points.
|
|
</li><li>
|
|
Assurance must be marked as Topup
|
|
(e.g., by use of new feature with TTPAdmin flag).
|
|
</ol></li>
|
|
|
|
<p>
|
|
Each topup is to be reported to AO.
|
|
Topup is only available in designated deserts.
|
|
</p>
|
|
|
|
<hr>
|
|
|
|
<h2 id="A"> Appendix A - Handbook text, not for policy </h2>
|
|
|
|
<blockquote><table border="1" bgcolor="lightpink"><tr><td>
|
|
<center><p class="q">
|
|
This pink part into the HANDBOOK when it goes to DRAFT, not part of policy!<br />
|
|
This way, the policy sets requirements and standards,<br />
|
|
and AO is responsible for meeting them as a PRACTICE.
|
|
</p></center>
|
|
|
|
<p>
|
|
These steps are taken.
|
|
</p>
|
|
|
|
<h3> 3.1 Preliminaries </h3>
|
|
<ol> <li>
|
|
<p>
|
|
The Member creates her account
|
|
and attempts to be assured by the routine face-to-face process.
|
|
</p>
|
|
</li><li>
|
|
<p>
|
|
Once determining that none are conveniently located,
|
|
the Member contacts an Assurer who is enabled to
|
|
conduct TTP-assisted assurances in the region.
|
|
</p>
|
|
</li><li>
|
|
<p>
|
|
The Assurer confirms that the Member
|
|
agrees to the CAcert Community Agreement (CCA),
|
|
including the Dispute Resolution Policy (DRP).
|
|
</p>
|
|
</li><li>
|
|
The Assurer confirms that standard Assurances do not meet
|
|
the needs of the Member.
|
|
This is only likely in areas not well-served with Assurers.
|
|
</p>
|
|
</li><li>
|
|
<p>
|
|
The Member and Assurer must negotiate the selection of TTPs
|
|
and the provision of adequate identification documents to the TTP.
|
|
Each TTP can only be used once (within one assurance for this Member).
|
|
</p>
|
|
|
|
<p class="q">iang: this may suggest a Patch required to the system that permits the Assurer to check other TTP Assurances of the member.</p>
|
|
</li><li>
|
|
Assurer agrees to conduct the TTP-assisted Assurance,
|
|
and gives the Member a Token.
|
|
</li></ol>
|
|
|
|
<h3 id="s3.2"> 3.2 Face-to-face meeting with the TTP </h3>
|
|
<ol><li>
|
|
<p>
|
|
The TTP and the Member meet face-to-face.
|
|
</p>
|
|
</li><li>
|
|
<p>
|
|
The TTP shall confirm that:
|
|
</p>
|
|
<ol type="a"><li>
|
|
The Member agrees to the CCA.
|
|
</li><li>
|
|
The Name and Date of Birth details recorded on the form
|
|
are matched by those in the identity documents.
|
|
</li><li>
|
|
The method (document type and issuer, not numbers)
|
|
by which the Name and DoB details are matched
|
|
is stated on the form.
|
|
</li><li>
|
|
Location of the meeting.
|
|
</li><li>
|
|
Contact details for the TTP
|
|
</li><li>
|
|
Assurer's Name and Token.
|
|
</li></ol>
|
|
|
|
</li><li>
|
|
<p>
|
|
The TTP shall use either the local form of document
|
|
(on CAcert's approved list), or a CAcert-provided form.
|
|
</p>
|
|
|
|
</li><li>
|
|
<p>
|
|
The TTP shall log the event by their customary means,
|
|
including the Assurer's Name and Verification Token.
|
|
</p>
|
|
<p class="q">Old: leaving a Remote Assurance Form and copies of identity documents with the TTP for at least 60 days</p>
|
|
</li><li>
|
|
|
|
<p>
|
|
The paperwork is sent to the Assurer by the TTP.
|
|
</p>
|
|
<ul class="q">
|
|
<li>Old: sending a Remote Assurance Form and copies of identity documents to the Assurer by mutually agreed medium (eg post, web form or encrypted email).</li>
|
|
<li>iang: this requirement was informed by <a href="http://audit.cacert.org/svn/DRC/browser.php">DRCi</a> C.9.b:</li>
|
|
<blockquote><u>"RAs provide the CA with complete documentation on each verified applicant for a certificate."</u></blockquote>
|
|
<li>RA is registration authority which is a verifier of people who is outside the CA. For us, Assurers are our RAs.</li>
|
|
<li>What is different? In the old version of TTP, the TTP was the RA. Thus the criteria would require the TTP to send the form, not the Member.</li>
|
|
<li> However in the new TTP-assisted version of assurance, the Assurer is the RA, and the existing arrangement of the RA's documentation process (forms provided to Arbitrator) are workable. Also note responsibility laid out in 3.d, the TTP-assist assurer makes a <a href="//wiki.cacert.org/CARS">CARS</a> of the Assurance Statement over the subject member. Ergo the Assurer is the RA, and is the responsible party.</li>
|
|
<li> Hence, the above point 5. is likely going to change. </li>
|
|
</ul>
|
|
</li></ol>
|
|
|
|
<h3 id="s3.3"> 3.3 Completion of the Assurance </h3>
|
|
<ol><li>
|
|
<p>
|
|
The Assurer must confirm the assurance using the paperwork,
|
|
</p><p>
|
|
The Assurer must
|
|
be satisfied as to the identity and competency of the TTP
|
|
in identification procedures,
|
|
as though they were to be conducting the assurance themselves
|
|
</p>
|
|
<span class="q">
|
|
<p>iang: this clause would probably meet <a href="http://audit.cacert.org/svn/DRC/browser.php">DRC</a> C.9.a:
|
|
<blockquote><u>"When the CA uses an external registration authority (RA), each RA is positively identified by CA personnel before being authorized to verify identities of subscribers and authorizations of individuals to represent organizational subscribers (see §A.2.v)."</u></blockquote>
|
|
For that reason, the above clause should be considered strongly,
|
|
and either discussed further in the Handbook, or include these
|
|
other Older suggestions:
|
|
<p>RA MUST authenticate the TTP to their satisfaction by:
|
|
</p>
|
|
<ol style="list-style-type: lower-roman;">
|
|
<li>searching for their details in an appropriate, official public registry (eg government site, association registry, telephone book) </li>
|
|
<li>contacting the TTP using these details to verify their identity </li>
|
|
<li>verifying that the TTP is suitable in terms of meeting the requirements of this policy </li>
|
|
<li>verifying that the meeting did indeed take place and that the Assuree was adequately identified </li>
|
|
</ol>
|
|
</span><br />
|
|
</i></blockquote>
|
|
|
|
</li><li>
|
|
The Assurer may contact the TTP, quoting Name and Verification Token.
|
|
</li><li>
|
|
On completion of the assurance, the Assurer
|
|
allocates standard full Assurance Points
|
|
(35 at time of writing)
|
|
to the Member.
|
|
Given the work involved, the Assurer should
|
|
strive to ensure that full points are allocated
|
|
by for example requesting any rework required.
|
|
|
|
<p class="q">iang: this clause might be better off in the Handbook. Dominik+1</p>
|
|
</li><li>
|
|
The assurance must be entered into the system
|
|
using the TTP flag/method.
|
|
</li><li>
|
|
The paperwork is held by the Assurer
|
|
according to the normal Assurance Policy rules
|
|
(at time of writing, for 7 years,
|
|
and available to Arbitrators only).
|
|
|
|
</li> </ol>
|
|
|
|
</td></tr></table></blockquote>
|
|
|
|
</body>
|
|
</html>
|