Hardware:
Root CA:
 ~raspi:
 + USB / integrated / SFF ICC reader
 + USB / external reader
  ~+ 5 additional USB for external ICC readers for bootstrap process to be more convinient
 + USB / storage for moving artifacts
 + Serial interface for I/O
 ~+ Dummy terminal (better) or USB keyboard + VGA

CA:
 ~raspi:
 + USB / integrated / SFF ICC reader
 + USB for KC
 + USB for audit log replication (or syslog dependency + offline backup)
 + network interface

KC:
 ~ USB reader for his workstation

Bootstraping Root CA (ca be Root CA, but other ICC readers through USB)
 * 2 ICC readers for Root_CA_ICC
 * 2 ICC readers for CA_ICC
 * 2 ICC readers for KC ICC 
 * 1 port for USB storage
Root CA
 * 1 Root CA ICC reader
 * 1 KC ICC
 * 1 for USB storage

Components:
 - Root CA ICC (javacard + nxp)
  * Root CA signing keypair
  * CA  keypair (for issuing KC certificates)

 - CA ICC (javacard + nxp)
  * CA signing keypair (for end-user/device certificate issuing)
  * CA server keypair (for communication between CA's)

 - CA tools/interfaces (go? python? java)

 - CA server (webservice API + gui + queue srvc)

 - KC ICC (javacard + NXP)
  * CA key share
  * KC Signing certificate (US CAC interface?)

 - KC tools (go? python? java)

 - Monitor ICC (javacard + NXP)

Roles:
 - Root CA:		Issue CA ceritifcates and KC certificates (at least N>2)
 - CA:			Issues end-user/device certificates (N>2)
 - Key Custodian:	PKI peptide control interface (N>2)
 - Key Custodian:	CA KC performing action in ceremony.
 - Master of Ceremony: 	PKI meta-peptide control interface for CA ceremonies. 
   			Should not be Key Custodian during ceremony. N=1
 - Key Manager: 	Spin all this shit around.
 - Auditor: 		Looking at others hands.

I Bootstrap

A KC cards
?> First 2 KCs generate their keys and CSR's on KC ICC using KC tools.
   This can be done on their workstation, but doing it on Root CA will be more convinient.

># KC init
<# Set PIN
># ****
<# PIN set
<# DN:
># cn=<username>,ou=pki,ou=Services,dc=hackerspace,dc=pl
<# KC ICC done

<- KC1_ICC:KC1PK
<- KC1.csr
<- KC2_ICC:KC2PK
<- KC2.csr

B Root_CA_1

 CA_N1
-> Key manager initiates self-generation of asymmetric crypto keys on 1st CA ICC and
   sets two initial KC:

># ca init -a KC1.csr -a KC2.csr
<# CA 

<- CA_N1_ICC:CA_sigPK
<- CA_N1_ICC:CA_srvPK
<- CA_N1_ICC:CA_admPK
<- CA_N1_InitCAsig.crt
<- CA_N1_InitCAsrv.crt
<- CA_N1_InitCAadm.crt
<- CA1_KC1.crt
<- CA1_KC2.crt

C CA_N2
-> Key manager initiates key generation on 2nd CA ICC

># ca

.B same as 1.A but on 2nd CA ICC and any further CA ICC


1. NXP Java card as keystore
2. Token concept?