Client Root CA Signing Ceremony Playbook

Setting

The ceremony is held on the 2nd day of November in the year 2018 A.D. The physical location is: GEANT Association Offices, Amsterdam.

Required personnel physically present:

S. Winter, RESTENA: execute key generation scripts on machine (passphrase person #1)

D. Visser, GEANT Association: ensure physical lockup of CA device incl. private key; supervise operation to ensure that

   a) no copies of the private key are made

   b) passphrase is only visible to authorised people

Required additional personnel, present via VC:

M. Milinovic, SRCE (passphrase person #2)

Procedure

1. S. Winter arrives at GEANT Offices with a Raspberry Pi 3. The Pi has the most recent version of Raspian OS preinstalled, with OpenSSL and the hwrng kernel driver, but no custom software.
2. The VC begins.
3. All participants to the ceremony agree on a value "n" for the length of the passphrases. Values smaller than 10 are unacceptable.
4. S. Winter executes the server CA generation script on the host auth-1.hosted.eduroam.org. This process takes a long time and runs in parallel with the Client Root CA procedures.
5. The CA generation scripts which are available online at GitHub get downloaded to a USB stick on a computer in GEANT offices.
6. The Pi gets powered up and connected to a monitor and keyboard available at GEANT offices.
7. The USB stick gets attached to the Pi, and mounted.
8. The scripts get copied to local SD card storage.
9. S. Winter executes the script "CA.bootstrapNewRootCA", answering the interactive questions by the script.
10. When the script asks for the certificate private key's passphrase, S. Winter makes up a n character password and writes it down in an application on his laptop, for screen sharing.
11. When the CAs are generated, S. Winter executes the second script, "CA.generateNewIntermediateCA".
12. When the script asks for the certificate private key's passphrase, S. Winter makes up a different n character password and writes it down on an existing VeraCrypt volume on his laptop.
13. S. Winter executes the scripts which generate the CRL and OCSP statements, for both the RSA and ECDSA variants.
14. S. Winter holds up the passphrase to the root CAs into the camera.
15. M. Milinovic makes a copy of the root CA passphrase and stores it safely for everafter.
16. S. Winter makes a copy of the root CA passphrase and stores it onto an existing VeraCrypt volume on his own laptop.
17. S. Winter destroys the piece of paper holding the passphrase. 
18. S. Winter copies all the public information regarding the CAs onto the USB stick:
    -root CA ECDSA+RSA certificate;
    -intermediate CA ECDSA+RSA certificate;
    -root CA CRL ECDSA+RSA;
    - root CA OCSP statement for the intermediate CA certificates ECDSA+RSA.
19. S. Winter copies the following SECRET information to the same USB stick:
    -intermediate CA private keys, RSA and ECDSA variants.
    -root CA private keys, RSA and ECDSA variants
20. The USB stick gets unmounted.
21. The Pi is shut down.
22. D. Visser extracts the root CA private keys into a word processor document and prints them.
23. D. Visser  places the Pi and the printouts in their physical lockup (safe). The access to that safe is managed internally in GEANT according to local procedures.
24. S. Winter deletes the root CA private keys from the USB stick.
25. S. Winter copies the remainder of the information on the USB stick to the relevant locations on the VMs.
26. The group verifies that meanwhile the server CA generation script has finished.
27. The VC ends.
28. The ceremony ends.

Client and Server Root CA Procedures

The Client Root CA is stored in GEANT Offices inside a safe, according to local organisation procedures. None of the persons with physical access have knowledge of the passphrase to the private keys.

The passphrase to the Root CA private keys is known to the Service Owner (M. Milinovic) and S. Winter (DevOps team). Both of these have no access to the physical storage of the key file.

VM snapshot restore procedure 

1. eduroam-OT sends a request to the GEANT IT Support <support@it.geant.org>, to restore a specific machine, from a given date,

      1-a If the restore is urgent (which IMHO will always be the case), CC qaiser and Allen to the email, and note "URGENT" in subject of the message

      1-b In this message eduroam-OT states if they want that the:

          1-b-1 restored snapshot replace the existing VM, or

          1-b-2 restored snapshot to be separately accessible so that they can manually retrieve the needed information

2. GEANT IT restores the VM as per request, detailed in 1-b.

          2-a The restore time is not guaranteed, as GEANT IT is not 24/7. For urgent ones follow 1-a !!

3. GEANT IT confirms to the eduroam-OT that the restore was complete

4. eduroam-OT confirms that the restore was successful and optionally informs in case of 1-b-2, if the restored VM is no longer needed

5. restore request is closed.