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

Het opgeven van het burgerservicenummer (SOFInummer) is niet verplicht maar helpt bij het vernieuwen of herroepen van het certificaat: anders moet de gebruiker het originele document opnieuw meebrengen. Met het burgerservicenummer kan de CA makkelijk zien of de aanvrager dezelfde persoon is, zelfs als inmiddels paspoort of rijbewijs zijn vernieuwd. Tenzij de aanvrager bezwaar maakt is het nuttig dit nummer over te nemen.

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

De user aanvraag formulieren staan op
  https://certificate.nikhef.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 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

  1. The end-user has to generate his or her 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, optionally a SOFI number, 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.
  2. The user should come to you in person, bringing the following items
  3. You must and then fill the bottom part (write down the location where you met, and sign and date it)
  4. You now have two options: 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 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.