Beste Registration Authority voor de DutchGrid CA,

Als Registration Authority ben je verantwoordelijk voor de identificatie van eindgebruikers bij je eigen organisatie of instituut - en het is dan ook de bedoeling dat je deze identificatieprocedure gaat volgen. Om een en ander wat minder belastend te maken voor de RAs, is de aanvraagprocedure voor nieuwe certificaten gestroomlijnd. Zo moet de gebruiker nu bij aanvraag zelf meer gegevens invullen, en staat er ook duidelijk dat de gebruiker *zelf* bij de RA langs moet gaan om deze indentificatie te laten doen. Hij moet hiervoor een getekend formulier meebrengen, en een identiteitsbewijs.

Hieronder staat de procedure voor RAs nog eens precies uitgelegd, zodat het hopelijk in de toekomst allemaal makkelijker en sneller gaat - en minder moeite kost voor de CA en RA. Overigens zijn deze procedures overeenkomstig de Certification Policy and Practice Statement (CP/CPS) versie 3.4.

PS: onderstaande tekst is ook na te lezen op
http://ca.dutchgrid.nl/info/ra-manual.html

De user aanvraag formulieren staan op
https://ca.dutchgrid.nl/request/
en, speciaal voor de 'Robot Qualified' Registration Authorities, de Robot Generation Compliance Form staat op:
DCA-Robot-Registration-20080730.pdf

Voordat je als RA aan de slag kunt, moet je dus wel de CP/CPS lezen :-) en daarna op verzoek het registratie formulier DutchGrid RAs invullen en terugsturen. De CA Manager zal aangeven wanneer en op welke manier je dit formulier moet gebruiken.

NIKHEF CA Registration Authority operations how-to

A Registration Authority (RA) is an intermediary that verifies the identity of requesters and forward the requests to a certification authority. An RA itself does not certify requests, but has been authorized by the CA (i.e. CA management) to do identity validation on their behalf.
To do that, they do not need a separate `RA' key, but they should be registered and authorized by a separate 'RA assignment letter', that they sign. By signing the letter, they agree to comply with the policy and practice statements, and do appropriate validation for end-entities within their domain of authority, for both humans, hosts, and services. As a Registration Authority, you have to comply with the certification policy and the relevant certification practice statements for your CA. In this case, the relevant policy is the NIKHEF/DutchGrid medium-security Certification Policy (current latest version is 2.2). To aid RAs in following this procedure, they may receive an operation training on appointment.
Should an RA need a certificate, they are certified by the Certification Authority (CA) according to the same procedures that apply to regular end-users, but they can countersign their own form.

Steps to follow (in-person verification)

For video-supported tele-meeting veritifation, see the process in section 3.1.9 of CP/CPS version 3.4+

The end-user has to generate their own request. During that process, an application form is generated, that the applicant has to fill in completely and correctly. It includes the serial number of a national photo ID, contact information, and above all a hand-written signature.
The applicant should write down (manually) the first 20 characters of the "proof-of-possession (PoP) challenge" that will be displayed on-screen when the user generates the certificate request. Without this PoP number, the request cannot be processed. Also, the PoP challenge cannot be added later the form, so do not sign the form unless the PoP challenge has been filled in.
The user should come to you in person, bringing the following items
- the filled-in application form
- the official photo-ID whose number is written on the form
You must
- verify the identity of the requestor using the photo-ID,
- validate the ID document serial number(s) on the form,
- check that the name is correct and bears proper resemblance to the full name on the identity piece (for user certificates); or
- ensure that the requestor is indeed an appropriate administrator for the host or service, is officially responsible for the systems with this FQDN, or has been duly authorized to run the service by the administrator, or is the operational or administrative contact of the domain name in the WHOIS database.
- please tell the applicant that he or she should pick a strong passphrase, at least 12 characetrs and complex, not to share the certificate and if ever there is doubt about the integrity of the key revoke the certificate!
and then fill the bottom part (write down the location where you met, and sign and date it)
You now have two options:
- Return the signed form to the user, who must mail or fax it to the CA office (POBox 41882, NL 1009 DB Amsterdam, NL; fax number +31 20 592 5155). You can leave it up to the user from that point on. This option will cost you the least amount of time
- Keep the application form and contact the CA directly by phone or signed e-mail. You must give the subject name and the first 6 characters of the proof-of-identity on the form (6 hex digits). Keep the form and photocopy with you, do not hand it back to the user, and mail or give it to the CA as soon as possible.
  In this case, the certificate request will be approved (almost) immediately . This option is only available for emergency cases, and may be impossible out of office hours.
  Never return the form to the user in this case!
Note that issuance can take up to 8 days - this is a manual process. Inform the user of TCS instant certificates at ca.dutchgrid.nl/tcs.
The signed certificate will be mailed back to the user directly by the NIKHEF CA operator.
If you send a signed confirmation mail, you should include
- the modus of your identity check (that is "personal visit"),
- the method of identification (passport, drivers license),
- the way you checked posession of the private key (time the request was received coincides with the moment the requestor sent the request, or content of request matches between the request received by the CA/RA and the data on the user's machine*),
- the full name of the requesting and responsible person (especially in case of host certificates),
- the intended use of the cert (personal, web-server, Globus gatekeeper, etc.)
*) The relevant public-key data (the 'proof-of-possession challenge', which is printed on the user's terminal after running the request generation script) must have been written on the form by the user.

Reconfirmations

When a user requests a rekey of the certificate after (or acutally just before) expiration, you as an RA will be contacted for a reconfirmation. For each certificate you validated, you will thus get at most one email per year to reconfirm that that the requestor is still OK, withing within your domain of authority, and has not left, disappeared, or whatever.
Please reply to these mails with a simple "OK" (and copy in the mail from the CA to check the renewal token). These mails should be identifiable as coming from you -- S/MIME or PGP signed email is definitely preferred. Otherwise, you will be contacted for confirmation of the mail by phone.

Other notices

Please only process certificate applications pertaining to your own domain of authority (unless you are a Roving RA). The proper RA name is printed automatically on the form.