Page tree

Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

Elector certificates are not part of the PKI hierarchy of the SCMS, i.e., verifying a certificate chain in the system does not involve verifying elector certificates. They are used primarily for root CA certificate management, including adding and removing a root CA. They will probably use cryptographic algorithms different from the rest of the system, preferably quantum-safe algorithms, to provide a recovery option in case quantum computers become a reality. The signature on the elector certificate does not have any cryptographic value as the signature is by the elector itself, and, therefore, the trust in an elector certificate is established through out-of-band means. Elector certificates do not have an encryption key as electors are mostly offline and do not accept any incoming messages, whether encrypted or not. Elector certificates must be made available to everyone in the system. As elector certificates are self-signed, the integrity of the initial set of electors must be ensured by other means, other than the cryptography used in generating the certificate itself, such as tamper-proof hardware and software validation of elector messages. For the same reason, the initial provisioning of elector certificates is done through out-of-band means in a secure environment during enrollment. Subsequent updating of elector certificates can be done in-band through e.g., revocation and adding by using the elector model as explained in Elector-based Root Management and Revocation Recovery.

Root CA

Index term
secondarySCMS Component
primaryRoot CA
The root CA certificate is different from all other types of certificates in many ways:

...

A root CA certificate does not have an encryption key as the root CA is mostly offline and does not accept any incoming messages, whether encrypted or not. The root CA certificate needs to be made available to everyone in the system. Also, for the reason explained in (2) above, integrity of a root CA certificate must be ensured by other means, other than the cryptography used in generating the certificate itself, such as tamper-proof hardware and software validation of elector messages. For the same reason, the initial provisioning of the root CA certificate is done through out-of-band means in a secure environment during enrollment. Subsequent updating of root CA certificates can be done in-band through e.g., revocation or adding by using the elector model as explained in Elector-based Root Management and Revocation Recovery.

ICA

Index term
secondarySCMS Component
primaryICA
ICA certificates can be used to only issue certificates to other SCMS components and nothing else. Only the root CA or the ICA can issue, or authorize someone to issue, a CRL to revoke an ICA certificate. 

...

Index term
secondarySCMS Component
primaryECA
As mentioned above, ECA certificates are of explicit type as they do not need to be distributed through P2P distribution. ECA certificates can be used to only issue certificates to end-entities including OBEs and RSEs. These  These certificates do not have encryption keys. To receive encrypted messages, the owner of these certificates can include an ephemeral response encryption key in the request messages. Revocation an encryption key.  Revocation of ECA certificate is done through CRLs issued by the CRL Generator. 

...

Index term
secondarySCMS Component
primaryPCA
PCA certificates can be used to only issue certificates to end-entities including OBEs and RSEs. PCA certificates need to have validity periods that are at least as long as the longest validity certificates issued using them. Revocation These certificates have an encryption key.  Revocation of PCA certificate is done through CRLs issued by CRL generator. 

...

These include LA, MA, and RA certificates. These certificates cannot be used to issue certificates. These certificates do not have encryption keys. To receive encrypted messages, owners of these certificates can include an ephemeral response encryption key in the request messages. Validity periods are They are described are as follows:

LA Certificates

Index term
secondarySCMS Component
primaryLA
Can be short as LAs do not interact with end-entities.  These certificates do not have encryption keys. To receive encrypted messages, the owner of these certificates can include an ephemeral response encryption key in the request messages.

RA Certificates

Index term
secondarySCMS Component
primaryRA
Must be long enough so that end-entities can successfully make a certificate provisioning request after being bootstrapped.  These certificates have an encryption key.

MA Certificates

Index term
secondarySCMS Component
primaryMA
Needs to be long so that end-entities do not need to retrieve these certificates very often.  These certificates have an encryption key.

EE Certificate Type Features

...