TTP-Assisted Assurance Program (Subpolicy)

TTP-Assisted Assurance Subpolicy https://svn.cacert.org/CAcert/Policies/images/cacert-draft.png

This is the top-level page for the TTP-Assisted Assurance (sub)programme. TTP-Assisted Assurance Subpolicy is a subsidiary policy of Assurance Policy

Steps & tasks

Assurance Team! Start your engines . . .

task

leader

status

comments

Document the process in handbook.

u60

{g}

pink box is below

Appoint, list, document, whatever the Senior Assurers / TTP-Admins

u60

{g}

procedure see TTPadmin

reset Old ttpadmin flags

u60

{+}

under arbitration a20110118.1

set new ttpadmin flags

u60 / inopiae

{g}

following board motion

Search wiki for all TTP references and change

u60

{g}

marked CategoryAssuranceTTP

reformat policy to drop the coloured parts.

Iang

{+}

also added some links, the policy block

push the clean DRAFT policy onto the main website. bug #1146 see bug 1131

Iang, u60

{0}

ready now

packages as mentioned in policy.

u60

{0}

first part fixed (except TOPUP)

TTP-assisted-assurance package

u60

{g}

TOPUP package

{0}

WIP

fix up the website text (prefer to destroy it and just point to wiki).

inopiae, u60

{0}

Bug #1111 Bug #1112

Check Assurer Challenge to see if there is mention of it, fix the Questions.

inopiae, werner

{g}

write some mini-C questions for fiddle.

Iang

{o}

write a procedure for Support to add the TTPadmin flag to Senior Assurers.

u60

{0}

first proposal under TTPadmin

trial run?

inopiae, Jeffery

{g}

organise this top-level page to summarise TTP programme and point to all references

u60

{0}

started, WIP

finish wiki TTP pages documentation

all

{0}

TTP-Users

inopiae, u60

{g}

TTP/TrustedThirdParty

inopiae, u60

{g}

TTP-Admins

inopiae, u60

{g}

TOPUP

{0}

system implementation to enter TTP assurances into the system Bug #863 {-} , Bug #864 {o} , Bug #888 {+} and Bug #988 {0}

{-}

Glossary: {+} finished - {0} happening, allocated, planned - {-} warning, needs attention! - {o} deffered to later

Informations for TTP-Users (Assuree's)

If seeking TTP-Assisted Assurance, this is your page:

Informations for TTPs or Trusted Third Parties

This is for people who might be asked to check ID documents for CAcert Assurance purposes:

Informations for TTP-Assurer (TTP-Admins I, Senior-Assurers)

Informations for TTP-TOPUP-Assurer (TTP-Admins II)

Administrative Tasks

TTP CAP form deployment

First draft CAP forms for TTP-Assisted-Assurances (WIP) of a TTP-CAP form. As there is a actual TTP CAP available you have to request it via support.

Draft

  1. You have to request a TTP-CAP-Form with an email to support.
  2. TTPadmin sends prefilled TTP CAP form to TTP user

references

For more information about Trusted Third Parties see

Pink Box Procedure

These steps are taken.

3.1 Preliminaries

  1. The Member creates her account and attempts to be assured by the routine face-to-face process.
  2. Once determining that none are conveniently located, the Member contacts an Assurer who is enabled to conduct TTP-assisted assurances in the region.
  3. The Assurer confirms that the Member agrees to the CAcert Community Agreement (CCA), including the Dispute Resolution Policy (DRP).
  4. 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.
  5. 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).
    • Iang: this may suggest a Patch required to the system that permits the Assurer to check other TTP Assurances of the member.

  6. Assurer agrees to conduct the TTP-assisted Assurance, and gives the Member a Token.

3.2 Face-to-face meeting with the TTP

  1. The TTP and the Member meet face-to-face.
  2. The TTP shall confirm that:
    1. The Member agrees to the CCA.
    2. The Name and Date of Birth details recorded on the form are matched by those in the identity documents.
    3. The method (document type and issuer, not numbers) by which the Name and DoB details are matched is stated on the form.
    4. Location of the meeting.
    5. Contact details for the TTP
    6. Assurer's Name and Token.
  3. The TTP shall use either the local form of document (on CAcert's approved list), or a CAcert-provided form.
  4. The TTP shall log the event by their customary means, including the Assurer's Name and Verification Token.
    • Old: leaving a Remote Assurance Form and copies of identity documents with the TTP for at least 60 days

  5. The paperwork is sent to the Assurer by the TTP.
    • 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).

    • iang: this requirement was informed by DRCi C.9.b:

      • "RAs provide the CA with complete documentation on each verified applicant for a certificate."

    • RA is registration authority which is a verifier of people who is outside the CA. For us, Assurers are our RAs.

    • 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.

    • 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 CARS of the Assurance Statement over the subject member. Ergo the Assurer is the RA, and is the responsible party.

    • Hence, the above point 5. is likely going to change.

3.3 Completion of the Assurance

  1. The Assurer must confirm the assurance using the paperwork,
  2. 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
    • Iang: this clause would probably meet DRC C.9.a:

      • "When the CA uses an external registration authority (RA), each RA is positively identified by CA personnel before being authorized to verify identities of subscribers and authorizations of individuals to represent organizational subscribers (see §A.2.v)."

    • For that reason, the above clause should be considered strongly, and either discussed further in the Handbook, or include these other Older suggestions:

    • RA MUST authenticate the TTP to their satisfaction by:

      1. searching for their details in an appropriate, official public registry (eg government site, association registry, telephone book)

      2. contacting the TTP using these details to verify their identity

      3. verifying that the TTP is suitable in terms of meeting the requirements of this policy

      4. verifying that the meeting did indeed take place and that the Assuree was adequately identified

  3. The Assurer may contact the TTP, quoting Name and Verification Token.
  4. 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.
    • Iang: this clause might be better off in the Handbook.

    • Dominik+1
  5. The assurance must be entered into the system using the TTP flag/method.
  6. 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).

Old TTP programme

Note that the TTP programme is effectively was frozen because it was knocked out by AP rules.

Proposal 2011-06-30: workflow User -> TTP -> TTP Assurer

  1. user sends TTP Assurance request to support@c.o

  2. triage moves request to TTPadmins pool
  3. 1st TTPadmin picks up the request, ackknowledges the users primary email address
  4. TTP admin triggers pre-TTP-assurance process thru the webdb (-> similiar to assure someone (to get the users data) + print a cap form (to add TTPadmins postal address)) with users primary email address, pre-filled ttp cap, and adds the TTPadmins postal address, prints the form to pdf, and sends the prefilled pdf to the requesting users primary email (see Bug #988)

  5. user prints out the pdf and go to the next accepted TTP and brings in a pre-stamped envelope
  6. TTP sends the prefilled and filled document back to the TTPadmins postal address as printed on the TTPCAP
  7. TTP admin enters the TTP assurance into the system and sends topup request if checked in ttp-assurance to the TTPadmin pool
  8. user sends 2nd TTP assurance request to support@c.o

  9. similiar to steps 2-7
  10. after 2nd TTP-assisted-assurance 3rd TTPadmin picks up the topup request and contacts user for the topup procedure

Glossary

For more terms and translations in other languages, see the glossary.


TTP (last edited 2015-06-15 04:31:25 by AlesKastner)