Creating New Keys - ADSS-Admin-Guide

Home > Key Manager > Service Keys > Creating New Keys

Creating New Keys

To generate a new key press the New button in the main Service Keys page. A form is presented:

Item	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 operator 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 providersTLS 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 operator 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 certficates Email Signing – used for email signing certificates. 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 marked Not Available in the Key Manager > Crypto Source screen (i.e. record is shown with orange highlighting) then the relevant Crypto profile will not be available here to generate a new key pair.
Algorithm	Select the Key Algorithm to be used: RSA ECDSA GOST (ask support@ascertia.com) 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.
Curve Type	This drop-down allows the operator 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.
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 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 (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) This is greyed out for HMAC keys. Support for additional key lengths can be made available upon request - contact sales@ascertia.com.
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.

As many keys as are needed can be created for a particular key purpose. For certain purposes only one key can be used at any one time, e.g. although many TLS Server Authentication key/certificates can exist only one can be used when an TLS session is established. This key/cert is identified in global settings.

Once the key pair is generated, it is shown in the main Key Manager table where all the important details of the key are displayed.