...
This page and its child pages contains description of individual processes dealing with service operations should be noted as well, such as:
RESPONSIBLE: Information provided here is initially populated by the development team (during the transition phase), and revised based on the need or in a yearly service check by service_name Service Managerperiodically. |
Client Root CA Signing Ceremony Playbook
...
The ceremony is held on the Xth 2nd day of month Y November in the year Z 2018 A.D. The physical location is: GEANT Association Offices, Amsterdam.
...
- 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.
- The VC begins.
- All participants to the ceremony agree on a value "n" for the length of the passphrases. Values smaller than 10 are unacceptable.
- 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.
- The CA generation scripts which are available online at GitHub get downloaded to a USB stick on a computer in GEANT offices.
- The Pri Pi gets powered up and connected to a monitor and keyboard available at GEANT offices.
- The USB stick gets attached to the Pi, and mounted.
- The scripts get copied to local USB SD card storage.
- S. Winter executes the script "CA.bootstrapNewRootCA", answering the interactive questions by the script.
- When the script asks for the certificate private key's passphrase, S. Winter makes up a n character password and writes it down on a piece of paper, large enough so that it can be seen when held into the camera of the VC laterin an application on his laptop, for screen sharing.
- When the CA is CAs are generated, S. Winter executes the second script, "CA.generateNewIntermediateCA".
- 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 a second piece of paperon an existing VeraCrypt volume on his laptop.
- S. Winter executes the scripts which generate the CRL and OCSP statements, for both the RSA and ECDSA variants.
- S. Winter holds up the passphrase to the root CAs into the camera.
- M. Milinovic makes a copy of the root CA passphrase and stores it safely for everafter.
- S. Winter makes a copy of the root CA passphrase and stores it onto an existing VeraCrypt volume on his own laptop.
- S. Winter makes a copy of the intermediate CA passphrase and stores it onto an existing VeraCrypt volume on his own laptop.destroys the piece of paper holding the passphrase.
- 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. - S. Winter copies the following SECRET information to the same USB stick:
-intermediate CA private keykeys, RSA variant onlyand ECDSA variants.
-root CA private keys, RSA and ECDSA variants - The USB stick gets unmounted.
- The Pi is shut down..
- D. Visser extracts the root CA private keys into a word processor document and prints them.
- D. Visser places the Pi and the printouts in their The Pi is placed in its physical lockup (safe). The access to that safe is managed internally in GEANT according to local procedures.
- S. Winter deletes the root CA private keys from the USB stick.
- S. Winter copies the remainder of the information on the USB stick to the relevant locations on the VMs.
- The group verifies that meanwhile the server CA generation script has finished.
- The VC ends.
- The ceremony ends.
Client and Server Root CA Procedures
TBD: where exactly is it stored, access controls to physical location
There will be a key generation ceremony. Q to the SM: is it acceptable to take the preparatory steps before traveling to the signing ceremony? Or do everything live?
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 closedTBD: who has the password for the encrypted private key, how is it stored, how is long-term accessibility ensured.