|
Items
|
Description
|
|
Key Alias
|
Define a name (alias) for the new key. This name has to be unique within the ADSS system.
|
|
If the Crypto source is Azure Key Vault HSM, then only these characters are supported for key alias:
A-Z, a-z, 0-9 and hyphen "-".
|
|
|
Purpose
|
Select the certificate purpose for this key pair. The list of certificate purposes is populated based on the certificate templates generated in the Certificate Templates area. A list of default certificate purposes certificate templates is shown below:
Attribute Authority - used to create an Attribute Authority to be configured in the list of Local Attribute Authorities in Manage CAs module. Local Attribute Authority will issue attribute certificates through the ADSS Certification Service.
Document Signing – used in the ADSS Signing Service (e.g. for signing documents as part of Watched Folder mode signing)
Code Signing – used to digitally sign source code of different applications
EV Code Signing – It is Extended Validation Code Signing which includes all the benefits of standard code signing with rigorous vetting process.
Verification Response Signing – for signing ADSS Verification Service Response messages
OCSP Request Signing – used by ADSS Server for signing OCSP request messages sent to an OCSP responder
OCSP Response Signing – used for signing ADSS OCSP Service Response messages
|
|
When operating in FIPS 201 compliant mode, the ADSS Server user must ensure that the length of the OCSP response signing key must be at least as large as, or larger than, the key length used by the CA that issued the target certificate (i.e. certificate being validated)
TLS Client Authentication Template – used by ADSS Server for TLS client authentication when communicating with other service providers.
|
TLS Server Authentication – used by ADSS Server for TLS server authentication (e.g. when communicating with client applications)
EV TLS Server Authentication – It is Extended Validation version for TLS Server Authentication with more rigorous authentication process.
TLS Client Authentication – used by ADSS Server for TLS client authentication while communicating with other applications over TLS.
Cert/CRL Signing – used to issue certificates/CRLs, this key can be selected for use as the ADSS Local CA key
CSCA Certificate – Its a root certificate in an E-Passport infrastructure that issues Document Signer, Master List Signer and other certificates.
DS Certificate – It is used to compute signature over personal and bio-metric data held on E-Passport chips.
RA Certificate – used by RA Service clients (devices) to encrypt the PKCS#10/CSR requests before sending them to RA Service over SCEP.
Log Signing – used for signing log records
Timestamp Response Signing – used for signing ADSS Timestamp Service Response messages
XKMS Response Signing – used for signing ADSS XKMS Service Response messages
XKMS Request Signing – used for signing ADSS XKMS Service Request messages
SCVP Response Signing – used for signing ADSS SCVP Service Response messages
|
|
When operating in FIPS 201 compliant mode, the ADSS Server user must ensure that the length of the SCVP response signing key must be at least as large as, or larger than, the key length used by the CA that issued the target certificate (i.e. certificate being validated).
|
SCVP Request Signing – used for signing ADSS SCVP Service Request messages
Master List Signing – It is used to sign the master lists that contain CSCA and link certificates.
DRM Agent – used for DRM Agent certificates
Rights Issuer – used for Rights Issuer certificates
IP Sec Signing – used for IPSec Signing certificates
Code Signing – used for code signing certificates
Email Signing – used for email signing certificates
Key Encapsulation Mechanism – used where Kyber is selected as a Key Algorithm
Document Encryption - used for document encryption certificates, e.g. used by Go>Sign applet to encrypt data for later decryption by the ADSS Decryption Service
Qualified Certificates - used for generating qualified certificates according to the ETSI Qualified Certificate Profile (ETSI TS 101 862).
Key Encryption Key (KEK) - used for encrypting the keys
Data Encryption Key (DEK) - used for encrypting the data
HMAC Key - used for generating an HMAC key used for protecting database records within the ADSS Server database to ensure system integrity.
Country Verifying CA (CVCA) – it is a root CA of a country in an E-Passport (Extended Access Control) infrastructure that is used to issue certificates to Document Verifiers.
Document Verifying CA (DVCA) – These are sub-CAs that issue certificates to Inspection Systems in an E-Passport infrastructure.
|
|
Crypto Profile ID
|
Select whether to generate and store this key within the ADSS Server database (software mode), Azure Key Vault or to store the key on a hardware security module (HSM) preconfigured within ADSS Server Key Manager as described in the section Crypto Processor Settings.
|
|
When a configured hardware crypto profile is Not Available in the ADSS Server Key Manager (i.e. record is shown with orange highlighting) then the relevant crypto profile will not be available here for configurations.
|
|
|
Algorithm
|
Select the Key Algorithm to be used:
- RSA
- ECDSA
- GOST
- Dilithium
- Kyber
Note:
- For HMAC keys HmacSHA1, HmacSHA256, HmacSHA384, HmacSHA512 or HmacMD5 can be selected.
- Click here for more details on limitations when ECDSA Key Algorithm is used.
- The keys generated using PQC algorithms, such as Dilithium and Kyber, are created solely through software and not via HSMs.
- The Dilithium algorithm will be only be used for document signing purposes.
- The below mentioned signature types are supported for Dilithium:
- PKCS1
- CMS
- CAdES Baseline (Only if CA key is RSA/EC)
- CAdES Extended (Only if CA key is RSA/EC)
- The Kyber key algorithm will be visible only when the user selects one of the certificate purposes listed below in the 'Purpose' field:
- Key Encapsulation Mechanism
- TLS Server Authentication
- EV TLS Server Authentication
- TLS Client Authentication
|
|
Currently the PQC algorithms (Dilithium and Kyber) are only for proof of concept (POC).
|
|
|
Curve Type
|
This drop-down allows the user to select the required curve type to be applied on the key. ADSS Server supports the following curve type:
- NIST P
- SEC2 K
- Brainpool R
- Brainpool T
Note:
- The Curve Type drop-down will be available only when ECDSA algorithm is selected in key algorithm field.
- Utimaco CryptoServer CP5 HSM does not support SEC2 K curve type.
- For TLS Server Authentication certificate, only NIST P curve type is supported.
|
|
Key Length
|
Select the key length to be used:
- The choices for RSA keys are: 1024, 2048, 3072, 4096 and 8192.
- The choices for ECDSA keys in terms of their respective curve types are:
- For NIST P: 160, 192, 224, 256, 384 and 521
Note: While creating a TLS Server Authentication certificate in case of NIST P, only 256, 384 and 521 key lengths are supported.
- For SEC2 K: 256
- For Brainpool R & Brainpool T: 160, 192, 224, 256, 320, 384 and 512.
Note:
- In case of E-Passport certificate purposes CVCA or DVCA, following key lengths are supported:
- For RSA keys: 1024, 1280, 1536, 2048 and 3072
- For ECDSA keys: NIST P, SEC2 K, Brainpool R and Brainpool T key lengths are supported as mentioned above
- In case of Azure Key Vault, following key lengths are supported:
- For RSA keys: 2048, 3072 and 4096
- For ECDSA keys: 256, 384 and 521 (only NIST P curve)
- In case of AWS CloudHSM, following key lengths are supported:
- For RSA keys: 2048, 3072 and 4096
- For ECDSA keys: 256 and 384 (only NIST P curve)
- In case of S/MIME key type, consider the following points:
- For RSA key pairs, the Certificate Authority (CA) must:
- Ensure that the modulus size is at least 2048 bits when encoded.
- Verify that the modulus size, in bits, is evenly divisible by 8.
- For ECDSA key pairs, the CA must:
- Confirm that the key represents a valid point on one of the NIST curves: P-256, P-384, or P-521
- The ECDSA NIST P 521 key length (supported in ADSS Server) cannot be used in Google Chrome and Microsoft Edge due to browser limitation. Currently it's only supported in Firefox.
- This is greyed out for HMAC keys.
- Support for additional key lengths can be made available upon request - contact sales@ascertia.com.
|
|
Security Level
|
The Security Level drop-down will be available when either Dilithium or Kyber is selected in the 'Algorithm' field. This drop-down allows the user to choose the security level for the selected key algorithm. The security levels for both Dilithium and Kyber are defined below:
- Dilithium: 2,3 and 5.
- Kyber: 2,3 and 5.
|
|
Description
|
This should be used to describe the key purpose in more detail (e.g. in which circumstances this key will be used and/or what sort of template the key is assigned, which applications use it etc). This is for information purposes only and avoids operational management issues on systems with lots of keys.
|
|
Allow the private key to be exported later
|
If this option is selected then the private key and associated certificates as a PKCS#12/PFX file can be exported later. This option is only available if you are using software mode, since most HSMs tightly control the export of private keys. This option is disable in case of Azure Key Vault.
|
