An encoding description contains the information for the electronic personalization of a card. You import the encoding description from a file. This article describes how you create descriptions on how to handle certificates and keys. This can be used in Smart ID Identity Manager.

See also Structure of an encoding description in Identity Manager.

Read and write certificates

Write a certificate

Define like this in the encoding description:

Description of the elements:

Write a Certificate-Key-List

Use this application command to write a structure of base64 encoded certificate and base64 encoded keypair to the smartcard. It can be used as a surrogate to writing a PKCS#12 container directly to the smartcard (even with root and intermediate certificates, that have no private key attached).

Define like this in the encoding description:

Description of the elements:

Delete certificates and other objects

Delete certificates

To delete certificates (and optionally their associated keys) on a token, it can be necessary to select special certificates by a selection criteria.

Define like this in the encoding description:

Description of the elements:

Delete orphan keys

Orphan keys are private and/or public keys that have no matching certificate on the card. This can happen for example when a keypair is created but the certification request fails because the CA is unreachable. Typically this leads to a useless keypair on the card.

You can delete such orphan keys. The keys can be selected by their label or you can delete all orphan keys of a card. If a key does have a matching certificate, it will not be deleted without raising any error.

Define like this in the encoding description:

Description of the elements:

Delete all objects from smartcard

This use case clears all objects (actually just public- and private keys and certificates) from the smartcard, instead of re-initializing the smartcard. This is done by searching all objects on the smartcard and executing a delete operation on each returned object handle. (You just need to login with PIN, to be able to also search for private keys and delete them. No PUK or SO-PIN needed.)

Define like this in the encoding description:

Description of the elements:

Save certificate with specific object relation type

Save certificate with specific object relation type

You can specify the relation type between card and certificates. Otherwise the default is used (see Object Relation section in Identity Manager Admin):

Define like this in the encoding description:

Description of the elements:

PKCS#10 requests

Generates a key pair on the smartcard and then invokes a PKCS#10 request (Certificate Signing Request) to a CA (defined by a certificate template name). After receiving the response from the CA with the signed certificate (and optional CA certificates), the user certificate will be written to the beforehand generated key pair. Available CA certificates will also be written to the smartcard to form the chain of trust (can optionally be disabled, see heading "Skip Writing CA Certificates"). Afterwards the CKA_ID and labels of the keys will be modified to match the ones of the written user certificate.

Define like this in the encoding description:

Description of the elements:

Temporary revoke a certificate right after P10-request

When requesting a certificate by CSR (P10-Request), it is very useful to also revoke that certificate right after it has been requested (inside jpki_encoder), that is, on client-side before communicating back to the server. This helps in cases where an error occurs and the server could, for example, not fulfil further steps with this certificate. It also benefits from better security when the certificates remains temporary revoked on the CA as long as the user, for example, retracts the temporary revocation on his certificate(s). This triggers a new communication to the CA right after the P10-Request.

On each application which requests a certificate, you could add a flag to indicate temporary revocation:

Define like this in the encoding description:

Description of the elements:

Create external card serial number and reuse value (CM)

Return card serial number from CM

Nexus Certificate Manager (CM) supports the token procedure type Smart Card. This token procedure type is used to describe various certificates on one type of smart card. When such a card is personalized, CM creates a unique card serial number. 

Define like this in the encoding description to let CM create the CM card serial number and return the value:

Description of the elements:

Map the field in CardSerialNumberReturnField to the ${carddatapool_cardnumber} (or to generally any other process variable) and activate the 'read' option. In the example above the cardnumber value would be read from CM_CARD_NUMBER_RETURN_FIELD.

Specify card serial number

When requesting a certificate for an existing card, for example, in a second, third... application, you use the CardSerialNumberField and point it to a field containing the card serial number. In the following example, Application_A generates the card serial number and reuses the value in the second application to make sure, that the certificate is created on the same card as the previous certificate from Application_A.

Define like this in the encoding description:

Description of the elements:

Add KeyUsage to specify the corresponding certificate

As a smartcard token procedure contains multiple certificates, we eventually need to specify the Key usage of the according certificate. This is done using the KeyUsage key in the description file. It corresponds to the key usage value(s) in the CM definition.

Define like this in the encoding description:

Required configuration in Identity Manager Admin

The card serial number encoding field (named CM_CARD_NUMBER in the examples above) acts as output and input field for Identity Manager's encoding component.

It is required:

• to map this field in the encoding mappings of the encoding description configuration to a Identity Manager variable or database field using an appropriate JUEL expression and

• to set the Read flag for this field mapping.

Plain-text request

Plain-text requests are relevant, when:

• Personal Desktop Client is used and

• the used card profile does not allow to access the private key to sign the request.

Usually, the JPKI-Encoder creates a PKCS10 request that is sent to the server. But in special cases, a plain text request is required. Such profiles are used when customer's processes define, that the certificate/keypair is only activated in the field (by a separate mechanism). Note that the plain text request also requires a CM Token Procedure of type "Smart card". You cannot use the type "PKCS10" and "PKCS12" for this request. To turn on the plain text request, SendPlainTextRequest must be set to true. Regarding the data which is technically sent, see also the actual REST call content behind.

Define like this in the encoding description:
In the following example, all the certificate related fields (subject/distinguished name fields and subject alternative names, keysize, keyusage, the existing publickey and if keyarchival is requested), will be sent as parameters to the server.

Description of the elements:

For certain cards that contain pre-generated keys with CKA_ID, it may be required to set this as well, to read the existing ID instead of trying to generate it from the public key's modulus:

Key archival

Certificate and key pair are generated on the server and the card is written on the client. When using CardOS middleware, Secure Key Injection (SKI) is supported to transport the private key from the server to the smart card.

Key archival without Secure Key Injection

In the non SKI case, normal PKCS#12 file data is transferred from server to client instead of encrypted key pair.

Define like this in the encoding description:

Encoding Description details:

Description of the elements:

The Result of a P12 request will be stored as base64 encoded value for the requesting application like:

Key archival with Secure Key Injection

See section PKCS#12 requests with Secure Key Injection.

Repackage PKCS#12 file right after KeyArchival request

To support renaming of the friendly name according to a configurable pattern (also with case-sensitivity) and for renaming friendly names of the CA certificates (intermediates and the root) according to the same pattern, inject this PKCS#12 Repackager mechanism into the KeyArchivalRequestPreProcessor:

Note the value of "naming" - here "§{CN} - _!CERT_SERIAL_NUM", where you can mix Juel-like expressions (here with "§" (paragraph) which is resolved out of the certificates' DN), free text and a special identifier _!CERT_SERIAL_NUM (that is replaced by the real certificate serial number of the certificate).

With the property "certSerialInHex" as boolean flag, you can change the usage of the certificate serial number in the friendly name by applying it in hexadecimal (true) or decimal (false) notation. Prefix and suffix are free text options to be attached in front of the resolved naming or behind, however, there is no resolving inside the pre- and suffix, just in the "naming" string sequence.

Key recovery

Certificates and corresponding private keys are fetched from from the certificate authority (CA). The requested certificates can be provided either as a list of Core Object IDs or CoreObjectDescriptors via the RecoveryCertificateData attribute of encoding description. Thus the certificates to be recovered can either be looked up via Cert: Load Key History List or Processes: Execute Search Task or any other way that can provide either format. 

Key recovery without Secure Key Injection

Define like this in the encoding description:

Description of the elements:

Key recovery with Secure Key Injection

See section PKCS#12 requests with Secure Key Injection.

PKCS#12 requests with Secure Key Injection

To prevent eavesdropping during key import onto the card (e.g. during key archival or key recovery), you can enable Secure Key Injection (SKI), which transfers the key through an encrypted channel from the server to the card.

This is supported by the CardOS 5.4W14 middleware or later on CardOS 5.3+ cards.

Prerequisites

• The Identity Manager server must be running on Microsoft Windows.

• The required CardOS middleware (including Minidriver) must be installed on the Identity Manager server.

Define like this in the encoding description (in addition to the definition for non-SKI):

Description of the elements:

The ForceSKI flag has priority over the EnableSKI flag. The ForceSKI flag enables forcefully execution of SKI use cases even though the EnableSKI flag is not set. Here are some use cases:

Key pair generation and discovery

Generate key pair

To explicitly generate a key pair, trigger it in an application part of the encoding description.

Define like this in the encoding description:

Description of the elements:

Discover generated key pair

When you re-use already generated key pairs on the smartcard, you can search such a key pair to place a certificate to it. This is especially done for signature- and authentication certificates in the context of Nexus Personal Desktop, which creates 2 such key pairs on initialization of the smartcard with a special card profile. A key pair can be searched by an object criteria specifying the following 4 parameters:

• The constant of objects type to be found, for example, CKO_PUBLIC_KEY

• The constant of attribute type to be found, for example, CKA_LABEL

• The type of attribute to be found, for example, string

• The value of the attribute to be found, for example, a label name

Define like this in the encoding description:

Description of the elements:

Skip writing CA certificates

If you would like to just write user certificates without intermediate certificates and without a root certificate to the smartcard, you can add an encoding property to your certificate application:

Define like this in the encoding description:

Description of the elements:

Object labels

The label (CKA_LABEL value) for certificates, public and private keys using the default template, is generated using the CN from the DN followed by a white space and a two digit counter that starts by 01. The CN is limited to 36 characters. Doing so, the complete value is never longer than 39 characters. The reason for that is that CSPs in Windows have issues with longer values.

For example: Max Mustermann 01

Applying these values, each certificate and key pair bundle carries a unique name. However, the generation of the label can be configured using the keys Description/labelCounter and Application_X/LabelTemplate.

LabelCounter is the start value for the global counter.

LabelTemplate is the template that instructs the generation of the label. It has following syntax: LabelTemplate=[<labelAttr>=<value>],[<labelAttr>=<value>],…

Valid values for labelAttr:

Corresponding to this definition, the default label template is:

labeltemplate=limitedname=36,blank=1,certcounter

The content of the every type of LabelTemplate can also be concatenated using the fields in the Fields section of the encoding description, using an expression language based on the exclamation mark. See Spring Expression Language (SpEL) :: Spring Framework for details.
Examples:

Define like this in the encoding description:

Define the attribute set (PKCS#11 template)

Template

When an object (certificate, public or private key) on the card is stored or created, it contains a set of attributes as defined by the PKCS#11 standard. The PKCS#11 standard typically names this set as template. For our use cases, templates are used for:

• storing a certificate (using a certificate template),

• storing a private key (using a private key template),

• creating a key pair (using a private key and public key template).

The set of attributes are basically "hard coded" by the JPKIEncoder. However, the attribute sets can be varied by the corresponding description file entry. Using such an entry,

• may change the value of the corresponding attribute,

• may extend the default list of attributes inclusive defining their values.

Template for storing a certificate

Template for storing a private key

Template for generating a private key

Template for generating a public key

Notes for CKA_ID

The CKA_ID establishes the link between certificate, private and public key.

Variant 1: It is stored as twenty bytes long value, generated from the public key’s modulus using the SHA-1 hash algorithm.

Variant 2: Alternatively, the SubjectKeyIdentifier of the object bundle is used, when this field is contained in the corresponding certificate of the object bunch. The SubjectKeyIdentifier is then stored in its DER encoded form.

Example for variant 2:

A certificates' SubjectKeyIdentifier is defined in the x509 extensions section, as seen in this image:

Open

• This SubjectKeyIdentifier is then taken for CKA_ID generation with the following generation rules:

  1. Byte is an encoding identifier. Generally DER encoding is preferred, represented by the byte sequence 04h.

  2. Byte is the length of the SubjectKeyIdentifier (here 6 bytes, therefore 06h).

  3. The following Bytes are the SubjectKeyIdentifier bytes.

• The resulting CKA_ID (8 bytes length) then is: 0406014B2ADD5F66 (=example)

Apply extra attributes
To change the default sets used by the JPKIEncoder, define like this in the encoding description:

Description of the elements:

These attributes are supported to be overwritten or added to the JPKIEncoder’s default templates:

Optional attributes

Similar to the definition of extra attributes, the encoding description allows the definition of optional attributes (which is, however, a JPKIEncoder internal name for the way to consider these attributes). The general meaning of this feature is also minor, see the remarks below.

The mechanism to apply optional attributes, works like this:

• A Smartcard object (certificate, public key, private key) is created on the card. It then owns some attributes as described above in the section for standard and default attributes.

• When optional attributes are defined in the description file, the JPKIEncoder checks if such an attribute exists and if it has a different value from the requested one. If so, it updates the existing value.

The mechanism basically exists to support various middleware with various support of such attributes - without having knowledge how far a middleware uses such attributes.

Define the optional attributes like this in the encoding description:

Description of the elements

The examples above demonstrate the usage of optional attributes for allowed use cases. Please note the specialty of the separate and global attribute definition for root and intermediate certificates. Attributes for user certificates are always taken from the corresponding Application_X section, but if an Application_X defined use case provides root or intermediate certificates, their definition is taken from the global Description section. The table describes all allowed attributes that may be used as optional attributes. The actual usage of an attribute depends on the corresponding object and use case.

Attributes of type CK_BBOOL and CK_ULONG require a corresponding value in the encoding description. CK_DATE and Byte array values are implicitly generated from the related certificate and do not require a value. That means, the different kind of attributes are defined like this:

^{AttributesCertOpt=CKA_ALWAYS_AUTHENTICATE=TRUE,CKA_CERTIFICATE_CATEGORY=1,CKA_START_DATE,CKA_HASH_OF_SUBJECT_PUBLIC_KEY}

Transport certificates

Example of transport certificate

Transport certificates (TC) are a Nexus Personal Desktop feature for cards that are pre-personalized with keypairs. The purpose of a transport certificate is to guarantee the originator of the pre-personalized card, to avoid that other cards, with non-secret private keys, are used when issuing certificates. The public keys on a pre-personalized smart card produced in the Key Generation System (KGS) are normally not signed and therefore not protected against tampering during the transport from the KGS to the Registration Authority (RA) where the cards are personalized. To improve the security of the issuing system, the public key can be embedded in a transport certificate signed by a dedicated "transport CA". When the personalization takes place in the RA, a special token procedure must be selected by the officer. The token procedure must include a special modifier that checks the signature and validity of the transport certificate.

Generally, a certificate requested using a TC will replace the TC on the card. When - in the future - the requested certificate is renewed, the requested certificate will in turn act as a TC.

Identity Manager supports transport certificates. Nexus CM must be used as a CA. If pre-personalized cards with generated keypairs are being used, any transport certificates matching the generated keys will automatically be used. The requested certificate will automatically replace the TC. No further configuration is needed in Identity Manager. The JPKIEncoder Log will indicate whether a transport certificate was found or not.

This is an example of an encoding description:

Generate card with transport certificate

1.  Install current version of CM Key Generation System

2. Install Personal Desktop Client, see Install Personal Desktop Client.

3. In C:\Program Files (x86)\Nexus\Certificate Manager\Key Generation System\Cardprofiles you can find some CPFs. The ones that end with "Transport" are relevant. Choose one fitting the card you want to use, for example, RaP15Siemens50_2FCa1P_2048_OKG_KAR_Transport.cpf for a CardOS 5.0 ("50" stands for the CardOS version) token, and copy it to some directory. Uncomment the following lines in your copy:

   .cpf

   and comment out the previous values for SEC_*. Note that the profile for 5.0 cards specifies PIN minlength = 8. Initializing with "132435" will seem to work but you won't be able to log in or change PIN. To be sure, search for "minlength" in the cpf you use.

4. Some certificates are needed. Example certificates can be found in C:\Program Files (x86)\Nexus\Certificate Manager\Key Generation System\Certificates. Open the Personal GUI > View > Preferences > Electronic Identity Token Search > Browse > open the aforementioned folder > Add.
   You should now see tcsigner in your Nexus Personal GUI, its PIN is 1234 . This will be the the CA for signing the transport certificates.

5. Edit C:\Program Files (x86)\Nexus\Certificate Manager\Key Generation System\ppa.cfg or %APPDATA%\Nexus\Certificate Manager\Key Generation System\ppa.cf (the latter wins, if it exists), and make the following adjustments:

   ppa.cfg

6. Start KGS.

7. Select Target card reader.

8. Insert an erased card with the OS that fits your CPF.

9. Click Start.

10. In case of errors, consult the logfile specified in the [Trace] section.

Configure CM for transport certificates

1. Copy config\certformats\rfc5280.conf to config\certformats\rfc5280-tc.conf

2. Edit rfc5280-tc.conf and add transport certificate module after ID2Legacy:

3. Edit config\tcconfig.conf as you see fit.

4. Restart CM.

5. Clone an existing certificate procedure using rfc5280 certificate format and edit it

   • Rename appropriately

   • Set Certificate Format to rfc5280-tc (the one you just created)

6. Clone a token procedure that uses the certificate procedure you just cloned and edit it

   • Rename appropriatelly

   • Set Certificate Procedure to the one you just created

   • Set Storage Profile to PKCS10

7. Further information can be found here:

   • Configure the Certificate Factory in Certificate Manager, heading "Configure transport certificates"

   • Configure Key Generation System in Certificate Manager

   • Troubleshooting Certificate Manager clients, heading "Error situations related to transport certificates"

   • Key Generation System, Operator's Guide, sections:

     • 2.1. A Stand-alone System

     • 2.3. Transport Certificates

     • 2.4.1.7. Transport CA

   • CM Technical Description:

     • 2.2.5.4. Transport Certificate

     • 3.4.2. Using Transport Certificates

     • 3.7.3. Key Generation System

Use elliptic curves cryptography

The type of the created keys is coded into the KeySize property. The value is 'ECC/' plus a curve name. Supported curves are limited by Bouncy Castle, the PKCS#11 middleware and the certificate authority. For details, refer to the respective documentation. The PKCS10SigningAlgorithm needs to be specified when using elliptic curves cryptography.

• PRIME 3.9: Elliptic curves is only supported for Cryptovision and Nexus Certificate Manager. Other middlewares are guaranteed to NOT work, while other CA connectors are not tested.

• PRIME 3.10: Support is added for TCOS cards with ECC. Note that those only support SHA1_ECDSA as PKCS10SigningAlgorithm, SHA2-variants do not work.

• PRIME 3.11: Support is added for EJBCA.

Define like this in the encoding description: