Unique identifier for keys in the keystore. Unique identifier for certificates in the keystore. Unique identifier for certification paths in the keystore. The status of a key in the keystore. Key is ready for use Key is being generated Key has not been successfully generated and cannot be used. An object identifier (OID) in dot-decimal form as specified in RFC4512. The distinguished name attribute type encoded as specified in RFC 4514. The distinguished name attribute values are encoded in UTF-8 or in hexadecimal form as specified in RFC 4514. The attributes of a key in the keystore. The ID of the key. The client-defined alias of the key. Absent if the key is not a key pair. True if and only if the key is a key pair and contains a private key. False if and only if the key is a key pair and does not contain a private key. The status of the key. The value should be one of the values in the tas:KeyStatus enumeration. A distinguished name attribute type and value pair. The attribute type. The value of the attribute. A multi-valued RDN A list of types and values defining a multi-valued RDN A country name as specified in X.500. An organization name as specified in X.500. An organizational unit name as specified in X.500. A distinguished name qualifier as specified in X.500. A state or province name as specified in X.500. A common name as specified in X.500. A serial number as specified in X.500. A locality as specified in X.500. A title as specified in X.500. A surname as specified in X.500. A given name as specified in X.500. Initials as specified in X.500. A pseudonym as specified in X.500. A generation qualifier as specified in X.500. A generic type-value pair attribute. A multi-valued RDN An identifier of an algorithm. The OID of the algorithm in dot-decimal form. Optional parameters of the algorithm (depending on the algorithm). A CSR attribute as specified in RFC 2986. The OID of the attribute. The value of the attribute as a base64-encoded DER representation of an ASN.1 value. A CSR attribute as specified in PKCS#10. An X.509v3 extension field. A basic CSR attribute. A base64-encoded ASN.1 value. An X.509v3 extension field as specified in RFC 5280 The OID of the extension field. True if and only if the extension is critical. The value of the extension field as a base64-encoded DER representation of an ASN.1 value. An X.509 cerficiate as specified in RFC 5280. The ID of the certificate. The ID of the key that this certificate associates to the certificate subject. The client-defined alias of the certificate. The base64-encoded DER representation of the X.509 certificate. A sequence of certificate IDs. A certificate ID. An X.509 certification path as defined in RFC 5280. A certificate in the certification path. The client-defined alias of the certification path. A list of RSA key lenghts in bits. A list of X.509 versions. A list of TLS versions. The capabilities of a keystore implementation on a device. The signature algorithms supported by the keystore implementation. Indicates the maximum number of keys that the device can store simultaneously. Indicates the maximum number of certificates that the device can store simultaneously. Indicates the maximum number of certification paths that the device can store simultaneously. Indication that the device supports on-board RSA key pair generation. Indicates which RSA key lengths are supported by the device. Indicates support for creating PKCS#10 requests for RSA keys and uploading the certificate obtained from a CA.. Indicates support for creating self-signed certificates for RSA keys. Indicates which X.509 versions are supported by the device. The capabilities of a TLS server implementation on a device. Indicates which TLS versions are supported by the device. Indicates the maximum number of certification paths that may be assigned to the TLS server simultaneously. The capabilities of an Advanced Security Service implementation on a device. The capabilities of the keystore implementation. The capabilities of the TLS server implementation. The capabilities for the advanced secuirty service is returned in the Capabilities element. The length of the key to be created. The client-defined alias of the key. The key ID of the key pair being generated. Best-effort estimate of how long the key generation will take. The ID of the key for which to return the status. Status of the requested key. The value should be one of the values in the tas:KeyStatus enumeration. The ID of the key pair for which to return whether it contains a private key. True if and only if the key pair contains a private key. Information about a key in the keystore. The ID of the key that is to be deleted from the keystore. The subject to be included in the CSR. The ID of the key for which the CSR shall be created. An attribute to be included in the CSR. The signature algorithm to be used to sign the CSR. Defaults to SHA1 with RSA Encryption. The DER encoded PKCS#10 certification request. The X.509 version that the generated certificate shall comply to. Distinguished name of the entity that the certificate shall belong to. The ID of the key for which the certificate shall be created. The client-defined alias of the certificate to be created. The X.509 not valid before information to be included in the certificate. Defaults to the device's current time or a time before the device's current time. The X.509 not valid after information to be included in the certificate. Defaults to the time 99991231235959Z as specified in RFC 5280. The signature algorithm to be used for signing the certificate. Defaults to SHA1 with RSA Encryption. An X.509v3 extension to be included in the certificate. The ID of the generated certificate. The base64-encoded DER representation of the X.509 certificate to be uploaded. The client-defined alias of the certificate. The client-defined alias of the key pair. Indicates if the device shall verify that a matching key pair with a private key exists in the keystore. The ID of the uploaded certificate. The ID of the key that the uploaded certificate certifies. The ID of the certificate to retrieve. The DER representation of the certificate. A list with all certificates stored in the keystore. A certificate stored in the keystore. The ID of the certificate to delete. The IDs of the certificates to include in the certification path, where each certificate signature except for the last one in the path must be verifiable with the public key certified by the next certificate in the path. The client-defined alias of the certification path. The ID of the generated certification path. The ID of the certification path to retrieve. The certification path that is stored under the given ID in the keystore. An ID of a certification path in the keystore. The ID of the certification path to delete. The IDs of all certification paths that are assigned to the TLS server on the device. Common functionality for all advanced security service parts. Returns the capabilities of the advanced security service. The result is returned in a typed answer. Basic keystore functionality. This operation triggers the asynchronous generation of an RSA key pair of a particular key length (specified as the number of bits) as specified in [RFC 3447], with a suitable key generation mechanism on the device. Keys, especially RSA key pairs, are uniquely identified using key IDs.
If the device does not have not enough storage capacity for storing the key pair to be created, the maximum number of keys reached fault shall be produced and no key pair shall be generated. Otherwise, the operation generates a keyID for the new key and associates the generating status to it.
Immediately after key generation has started, the device shall return the keyID to the client and continue to generate the key pair. The client may query the device with the GetKeyStatus operation whether the generation has finished. The client may also subscribe to Key Status events to be notified about key status changes.
The device also returns a best-effort estimate of how much time it requires to create the key pair. A client may use this information as an indication how long to wait before querying the device whether key generation is completed.
After the key has been successfully created, the device shall assign it the ok status. If the key generation fails, the device shall assign the key the corrupt status. This operation returns the status of a key.
Keys are uniquely identified using key IDs. If no key is stored under the requested key ID in the keystore, an InvalidKeyID fault is produced. Otherwise, the status of the key is returned. This operation returns whether a key pair contains a private key.
Keys are uniquely identified using key IDs. If no key is stored under the requested key ID in the keystore or the key identified by the requested key ID does not identify a key pair, the device shall produce an InvalidKeyID fault. Otherwise, this operation returns true if the key pair identified by the key ID contains a private key, and false otherwise. This operation returns information about all keys that are stored in the device’s keystore.
This operation may be used, e.g., if a client lost track of which keys are present on the device. If no key is stored on the device, an empty list is returned. This operation deletes a key from the device’s keystore.
Keys are uniquely identified using key IDs. If no key is stored under the requested key ID in the keystore, a device shall produce an InvalidArgVal fault. If a reference exists for the specified key, a device shall produce the corresponding fault and shall not delete the key. If there is a key under the requested key ID stored in the keystore and the key could not be deleted, a device shall produce a KeyDeletion fault. If the key has the status generating, a device shall abort the generation of the key and delete from the keystore all data generated for this key. After a key is successfully deleted, the device may assign its former ID to other keys. This operation generates a DER-encoded PKCS#10 v1.7 certification request (sometimes also called certificate signing request or CSR) as specified in RFC 2986 for a public key on the device.
The key pair that contains the public key for which a certification request shall be produced is specified by its key ID. If no key is stored under the requested KeyID or the key specified by the requested KeyID is not an asymmetric key pair, an invalid key ID fault shall be produced and no CSR shall be generated.
A device that supports this command shall as minimum support the sha-1WithRSAEncryption signature algorithm as specified in RFC 3279. If the specified signature algorithm is not supported by the device, an UnsupportedSignatureAlgorithm fault shall be produced and no CSR shall be generated.
If the public key identified by the requested Key ID is an invalid input to the specified signature algorithm, a KeySignatureAlgorithmMismatch fault shall be produced and no CSR shall be generated. If the key pair does not have status ok, a device shall produce an InvalidKeyStatus fault and no CSR shall be generated. This operation generates for a public key on the device a self-signed X.509 certificate that complies to RFC 5280.
The X509Version parameter specifies the version of X.509 that the generated certificate shall comply to. A device that supports this command shall support the generation of X.509v3 certificates as specified in RFC 5280 and may additionally be able to handle other X.509 certificate formats as indicated by the X.509Versions capability.
The key pair that contains the public key for which a self-signed certificate shall be produced is specified by its key pair ID. The subject parameter describes the entity that the public key belongs to. If the key pair does not have status ok, a device shall produce an InvalidKeyStatus fault and no certificate shall be generated. The signature algorithm parameter determines which signature algorithm shall be used for signing the certification request with the public key specified by the key ID parameter. A device that supports this command shall as minimum support the sha-1WithRSAEncryption signature algorithm as specified in RFC 3279. The Extensions parameter specifies potential X509v3 extensions that shall be contained in the certificate. A device that supports this command shall support the extensions that are defined in [RFC 5280], Sect. 4.2] as mandatory for CAs that issue self-signed certificates.
Certificates are uniquely identified using certificate IDs. If the command was successful, the device generates a new ID for the generated certificate and returns this ID.
If the device does not have not enough storage capacity for storing the certificate to be created, the maximum number of certificates reached fault shall be produced and no certificate shall be generated. This operation uploads an X.509 certificate as specified by [RFC 5280] in DER encoding and the public key in the certificate to a device’s keystore.
A device that supports this command shall be able to handle X.509v3 certificates as specified in RFC 5280 and may additionally be able to handle other X.509 certificate formats as indicated by the X.509Versions capability. A device that supports this command shall support sha1-WithRSAEncryption as certificate signature algorithm.
Certificates are uniquely identified using certificate IDs, and key pairs are uniquely identified using key IDs. The device shall generate a new certificate ID for the uploaded certificate.
Certain certificate usages, e.g. TLS server authentication, require the private key that corresponds to the public key in the certificate to be present in the keystore. In such cases, the client may indicate that it expects the device to produce a fault if the matching private key for the uploaded certificate is not present in the keystore by setting the PrivateKeyRequired argument in the upload request to true.
The uploaded certificate has to be linked to a key pair in the keystore. If no private key is required for the public key in the certificate and a key pair exists in the keystore with a public key equal to the public key in the certificate, the uploaded certificate is linked to the key pair identified by the supplied key ID by adding a reference from the certificate to the key pair. If no private key is required for the public key in the certificate and no key pair exists with the public key equal to the public key in the certificate, a new key pair with status ok is created with the public key from the certificate, and this key pair is linked to the uploaded certificate by adding a reference from the certificate to the key pair. If a private key is required for the public key in the certificate, and a key pair exists in the keystore with a private key that matches the public key in the certificate, the uploaded certificate is linked to this keypair by adding a reference from the certificate to the key pair. If a private key is required for the public key and no such keypair exists in the keystore, the NoMatchingPrivateKey fault shall be produced and the certificate shall not be stored in the keystore. If the key pair that the certificate shall be linked to does not have status ok, an InvalidKeyID fault is produced, and the uploaded certificate is not stored in the keystore. If the device cannot process the uploaded certificate, a BadCertificate fault is produced and neither the uploaded certificate nor the public key are stored in the device’s keystore. The BadCertificate fault shall not be produced based on the mere fact that the device’s current time lies outside the interval defined by the notBefore and notAfter fields as specified by [RFC 5280], Sect. 4.1 . This operation shall not mark the uploaded certificate as trusted.
If the device does not have not enough storage capacity for storing the certificate to be uploaded, the maximum number of certificates reached fault shall be produced and no certificate shall be uploaded. If the device does not have not enough storage capacity for storing the key pair that eventually has to be created, the device shall generate a maximum number of keys reached fault. Furthermore the device shall not generate a key pair and no certificate shall be stored. This operation returns a specific certificate from the device’s keystore.
Certificates are uniquely identified using certificate IDs. If no certificate is stored under the requested certificate ID in the keystore, an InvalidArgVal fault is produced. It shall be noted that this command does not return the private key that is associated to the public key in the certificate. This operation returns the IDs of all certificates that are stored in the device’s keystore.
This operation may be used, e.g., if a client lost track of which certificates are present on the device. If no certificate is stored in the device’s keystore, an empty list is returned. This operation deletes a certificate from the device’s keystore.
The operation shall not delete the public key that is contained in the certificate from the keystore. Certificates are uniquely identified using certificate IDs. If no certificate is stored under the requested certificate ID in the keystore, an InvalidArgVal fault is produced. If there is a certificate under the requested certificate ID stored in the keystore and the certificate could not be deleted, a CertificateDeletion fault is produced. If a reference exists for the specified certificate, the certificate shall not be deleted and the corresponding fault shall be produced. After a certificate has been successfully deleted, the device may assign its former ID to other certificates. This operation creates a sequence of certificates that may be used, e.g., for certification path validation or for TLS server authentication.
Certification paths are uniquely identified using certification path IDs. Certificates are uniquely identified using certificate IDs. A certification path contains a sequence of certificate IDs. If there is a certificate ID in the sequence of supplied certificate IDs for which no certificate exists in the device’s keystore, the corresponding fault shall be produced and no certification path shall be created.
The signature of each certificate in the certification path except for the last one must be verifiable with the public key contained in the next certificate in the path. If there is a certificate ID in the request other than the last ID for which the corresponding certificate cannot be verified with the public key in the certificate identified by the next certificate ID, an InvalidCertificateChain fault shall be produced and no certification path shall be created. This operation returns a specific certification path from the device’s keystore.
Certification paths are uniquely identified using certification path IDs. If no certification path is stored under the requested ID in the keystore, an InvalidArgVal fault is produced. This operation returns the IDs of all certification paths that are stored in the device’s keystore.
This operation may be used, e.g., if a client lost track of which certificates are present on the device. If no certification path is stored on the device, an empty list is returned. This operation deletes a certification path from the device’s keystore.
This operation shall not delete the certificates that are referenced by the certification path. Certification paths are uniquely identified using certification path IDs. If no certification path is stored under the requested certification path ID in the keystore, an InvalidArgVal fault is produced. If there is a certification path under the requested certification path ID stored in the keystore and the certification path could not be deleted, a CertificationPathDeletion fault is produced. If a reference exists for the specified certification path, the certification path shall not be deleted and the corresponding fault shall be produced. After a certification path is successfully deleted, the device may assign its former ID to other certification paths. TLS server functionality. This operation assigns a key pair and certificate along with a certification path (certificate chain) to the TLS server on the device. The TLS server shall use this information for key exchange during the TLS handshake, particularly for constructing server certificate messages as specified in RFC 4346 and RFC 2246.
Certification paths are identified by their certification path IDs in the keystore. The first certificate in the certification path must be the TLS server certificate. Since each certificate has exactly one associated key pair, a reference to the key pair that is associated with the server certificate is not supplied explicitly. Devices shall obtain the private key or results of operations under the private key by suitable internal interaction with the keystore.
If a device chooses to perform a TLS key exchange based on the supplied certification path, it shall use the key pair that is associated with the server certificate for key exchange and transmit the certification path to TLS clients as-is, i.e., the device shall not check conformance of the certification path to RFC 4346 norRFC 2246. In order to use the server certificate during the TLS handshake, the corresponding private key is required. Therefore, if the key pair that is associated with the server certificate, i.e., the first certificate in the certification path, does not have an associated private key, the NoPrivateKey fault is produced and the certification path is not associated to the TLS server.
A TLS server may present different certification paths to different clients during the TLS handshake instead of presenting the same certification path to all clients. Therefore more than one certification path may be assigned to the TLS server.
If the maximum number of certification paths that may be assigned to the TLS server simultaneously is reached, the device shall generate a MaximumNumberOfCertificationPathsReached fault and the requested certification path shall not be assigned to the TLS server. This operation removes a key pair and certificate assignment (including certification path) to the TLS server on the device.
Certification paths are identified using certification path IDs. If the supplied certification path ID is not associated to the TLS server, an InvalidArgVal fault is produced. This operation replaces an existing key pair and certificate assignment to the TLS server on the device by a new key pair and certificate assignment (including certification paths).
After the replacement, the TLS server shall use the new certificate and certification path exactly in those cases in which it would have used the old certificate and certification path. Therefore, especially in the case that several server certificates are assigned to the TLS server, clients that wish to replace an old certificate assignment by a new assignment should use this operation instead of a combination of the Add TLS Server Certificate Assignment and the Remove TLS Server Certificate Assignment operations.
Certification paths are identified using certification path IDs. If the supplied old certification path ID is not associated to the TLS server, or no certification path exists under the new certification path ID, the corresponding InvalidArgVal faults are produced and the associations are unchanged. The first certificate in the new certification path must be the TLS server certificate.
Since each certificate has exactly one associated key pair, a reference to the key pair that is associated with the new server certificate is not supplied explicitly. Devices shall obtain the private key or results of operations under the private key by suitable internal interaction with the keystore.
If a device chooses to perform a TLS key exchange based on the new certification path, it shall use the key pair that is associated with the server certificate for key exchange and transmit the certification path to TLS clients as-is, i.e., the device shall not check conformance of the certification path to RFC 4346 norRFC 2246. In order to use the server certificate during the TLS handshake, the corresponding private key is required. Therefore, if the key pair that is associated with the server certificate, i.e., the first certificate in the certification path, does not have an associated private key, the NoPrivateKey fault is produced and the certification path is not associated to the TLS server. This operation returns the IDs of all key pairs and certificates (including certification paths) that are assigned to the TLS server on the device.
This operation may be used, e.g., if a client lost track of the certification path assignments on the device. If no certification path is assigned to the TLS server, an empty list is returned.