Unique identifier for keys in the keystore. Unique identifier for certificates in the keystore. Unique identifier for certification paths in the keystore. Unique identifier for passphrases in the keystore. Unique identifier for 802.1X configurations 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. True if and only if the key was generated outside the device. True if and only if the key is stored in a specially protected hardware component inside the device. 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 Required extension point. It is recommended to not use this element, and instead use GenericAttribute and the numeric Distinguished Name Attribute Type. 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. The ID of the passphrase. The alias of the passphrase. A list of supported 802.1X authentication methods, such as "EAP-PEAP/MSCHAPv2" and "EAP-MD5". The '/' character is used as a separator between the outer and inner methods. The capabilities of the 802.1X implementation on a device. The maximum number of 802.1X configurations that may be defined simultaneously. The authentication methods supported by the 802.1X implementation. The configuration parameters required for a particular authentication method. The identity used in this authentication method, if required. The unique identifier of the certification path used in this authentication method, if required. The identifier for the password used in this authentication method, if required. If Identity is used as an anonymous identity for this authentication method, PassphraseID is ignored. The configuration of the next stage of authentication, if required. The authentication method for this stage (e.g., "EAP-PEAP"). The unique identifier of the IEEE 802.1X configuration. The client-defined alias of the 802.1X configuration. The outer level authentication method used in this 802.1X configuration. True if and only if the TLS server shall not authenticate client certificates that do not contain the TLS WWW client authentication key usage extension as specified in RFC 5280, Sect. 4.2.1.12. True if and only if delta CRLs, if available, shall be applied to CRLs. The certificate ID of the certificate to be used as trust anchor. A list of RSA key lenghts in bits. A list of X.509 versions. A list of TLS versions. A list of password based encryption algorithms. A list of password based MAC algorithms. 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. Indicates the maximum number of passphrases that the device is able to store simultaneously. Indicates support for uploading an RSA key pair in a PKCS#8 data structure. Indicates support for uploading a certificate along with an RSA private key in a PKCS#12 data structure. Indicates which password-based encryption algorithms are supported by the device. Indicates which password-based MAC algorithms are supported by the device. Indicates the maximum number of CRLs that the device is able to store simultaneously. Indicates the maximum number of certification path validation policies that the device is able to store simultaneously. Indicates whether a device supports checking for the TLS WWW client auth extended key usage extension while validating certification paths. 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. Indicates whether the device supports TLS client authentication. Indicates the maximum number of certification path validation policies 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 of the 802.1X 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 key pair to be uploaded in a PKCS#8 data structure. The client-defined alias of the key pair. The ID of the passphrase to use for decrypting the uploaded key pair. The passphrase to use for decrypting the uploaded key pair. The key ID of the uploaded key pair. The certificates and key pair to be uploaded in a PKCS#12 data structure. The client-defined alias of the certification path. The client-defined alias of the key pair. True if and only if the device shall behave as if the client had only supplied the first certificate in the sequence of certificates. The ID of the passphrase to use for integrity checking of the uploaded PKCS#12 data structure. The ID of the passphrase to use for decrypting the uploaded PKCS#12 data structure. The passphrase to use for integrity checking and decrypting the uploaded PKCS#12 data structure. The certification path ID of the uploaded certification path. The key ID of the uploaded key pair. 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 passphrase to upload. The alias for the passphrase to upload. The PassphraseID of the uploaded passphrase. A list with information about all passphrases in the keystore. Information about a passphrase in the keystore. The ID of the passphrase that is to be deleted from the keystore. The IDs of all certification paths that are assigned to the TLS server on the device. The CRL to be uploaded to the device. The alias to assign to the uploaded CRL. The ID of the uploaded CRL. The ID of the CRL to be returned. The CRL with the requested ID. A list of all CRLs that are stored in the keystore on the device. The ID of the CRL to be deleted. The alias to assign to the created certification path validation policy. The parameters of the certification path validation policy to be created. The trust anchors of the certification path validation policy to be created. The ID of the created certification path validation policy. The ID of the certification path validation policy to be created. The certification path validation policy that is stored under the requested ID. A list of all certification path validation policies that are stored in the keystore on the device. The ID of the certification path validation policy to be deleted. The ID of the certification path validation policy to assign to the TLS server. The ID of the certification path validation policy to de-assign from the TLS server. The ID of the certification path validation policy to be de-assigned from the TLS server. The ID of the certification path validation policy to assign to the TLS server. A list of IDs of the certification path validation policies that are assigned to the TLS server. The desired 802.1X configuration. The unique identifier of the created 802.1X configuration. The list of unique identifiers of 802.1X configurations on the device. The unique identifier of the desired 802.1X configuration. The 802.1X configuration, without password information. The unique identifier of the 802.1X configuration to be deleted. The unique identifier of the Network Interface on which the 802.1X configuration is to be set. (NOTE: the network interface token is defined in devicemgmt.wsdl as tt:ReferenceToken, which is a derived type of xs:string. To avoid importing all of onvif.xsd for this single type, the base type is used here.) The unique identifier of the 802.1X configuration to be set. Indicates whether or not a reboot is required after configuration updates. The unique identifier of the Network Interface for which the 802.1X configuration is to be retrieved. (NOTE: the network interface token is defined in devicemgmt.wsdl as tt:ReferenceToken, which is a derived type of xs:string. To avoid importing all of onvif.xsd for this single type, the base type is used here.) The unique identifier of 802.1X configuration assigned to the Network Interface. The unique identifier of the Network Interface for which the 802.1X configuration is to be deleted. (NOTE: the network interface token is defined in devicemgmt.wsdl as tt:ReferenceToken, which is a derived type of xs:string. To avoid importing all of onvif.xsd for this single type, the base type is used here.) Indicates whether or not a reboot is required after configuration updates. 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 uploads a key pair in a PKCS#8 data structure as specified in [RFC 5958, RFC 5959].
If an encryption passphrase ID is supplied in the request, the device shall assume that the KeyPair parameter contains an EncryptedPrivateKeyInfo ASN.1 structure that is encrypted under the passphrase in the keystore that corresponds to the supplied ID, where the EncryptedPrivateKeyInfo structure contains both the private key and the corresponding public key. If no encryption passphrase ID is supplied, the device shall assume that the KeyPair parameter contains a OneAsymmetricKey ASN.1 structure which contains both the private key and the corresponding public key. This operation uploads a certification path consisting of X.509 certificates as specified by [RFC 5280] in DER encoding along with a private key to a device’s keystore. Certificates and private key are supplied in the form of a PKCS#12 file as specified in [PKCS#12].
The device shall support PKCS#12 files that contain the following safe bags:
* one or more instances of CertBag [PKCS#12, Sect. 4.2.3] * either exactly one instance of KeyBag [PKCS#12, Sect. 4.3.1] or exactly one instance of PKCS8ShroudedKeyBag [PKCS#12, Sect. 4.2.2].
If the IgnoreAdditionalCertificates parameter has the value true, the device shall behave as if the client had supplied only the first CertBag in the sequence of CertBag instances. The device shall support PKCS#12 passphrase integrity mode for integrity protection of the PKCS#12 PFX as specified in [PKCS#12, Sect. 4]. The device shall support PKCS8ShroudedKeyBags that are encrypted with the same passphrase as the CertBag instances. If an integrity passphrase ID is supplied, the device shall use the corresponding passphrase in the keystore to check the integrity of the supplied PKCS#12 PFX. If an integrity passphrase ID is supplied, but the supplied PKCS#12 PFX has no integrity protection, the device shall produce a BadPKCS12File fault and shall not store the uploaded certificates nor the uploaded key pair in the keystore. If an encryption passphrase ID is supplied, the device shall use the corresponding passphrase in the keystore to decrypt the PKCS8ShroudedKeyBag and the CertBag instances. If an EncryptionPassphraseID is supplied, but a CertBag is not encrypted, the device shall ignore the supplied EncryptionPassphraseID when processing this CertBag. If an EncryptionPassphraseID is supplied, but a KeyBag is provided instead of a PKCS8ShroudedKeyBag, the device shall ignore the supplied EncryptionPassphraseID when processing the KeyBag. 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. This operation uploads a passphrase to the keystore of the device. This operation returns information about all passphrases that are stored in the keystore of the device. This operation may be used, e.g., if a client lost track of which passphrases are present on the device. If no passphrase is stored on the device, the device shall return an empty list. This operation deletes a passphrase from the keystore of the device. This operation uploads a certificate revocation list (CRL) as specified in [RFC 5280] to the keystore on the device. If the device does not have enough storage space to store the CRL to be uploaded, the device shall produce a MaximumNumberOfCRLsReached fault and shall not store the supplied CRL. If the device is not able to process the supplied CRL, the device shall produce a BadCRL fault and shall not store the supplied CRL. If the device does not support the signature algorithm that was used to sign the supplied CRL, the device shall produce an UnsupportedSignatureAlgorithm fault and shall not store the supplied CRL. This operation returns a specific certificate revocation list (CRL) from the keystore on the device. Certification revocation lists are uniquely identified using CRLIDs. If no CRL is stored under the requested CRLID, the device shall produce a CRLID fault. This operation returns all certificate revocation lists (CRLs) that are stored in the keystore on the device. If no certificate revocation list is stored in the device’s keystore, an empty list is returned. This operation deletes a certificate revocation list (CRL) from the keystore on the device. Certification revocation lists are uniquely identified using CRLIDs. If no CRL is stored under the requested CRLID, the device shall produce a CRLID fault. If a reference exists for the specified CRL, the device shall produce a ReferenceExists fault and shall not delete the CRL. After a CRL has been successfully deleted, a device may assign its former ID to other CRLs. This operation creates a certification path validation policy. Certification path validation policies are uniquely identified using certification path validation policy IDs. The device shall generate a new certification path validation policy ID for the created certification path validation policy. For the certification path validation parameters that are not represented in the certPathValidationParameters data type, the device shall use the default values specified in Sect. 3. If the device does not have enough storage capacity for storing the certification path validation policy to be created, the device shall produce a maximum number of certification path validation policies reached fault and shall not create a certification path validation policy. If there is at least one trust anchor certificate ID in the request for which there exists no certificate in the device’s keystore, the device shall produce a CertificateID fault and shall not create a certification path validation policy. If the device cannot process the supplied certification path validation parameters, the device shall produce a CertPathValidationParameters fault and shall not create a certification path validation policy. This operation returns a certification path validation policy from the keystore on the device. Certification path validation policies are uniquely identified using certification path validation policy IDs. If no certification path validation policy is stored under the requested certification path validation policy ID, the device shall produce a CertPathValidationPolicyID fault. This operation returns all certification path validation policies that are stored in the keystore on the device. If no certification path validation policy is stored in the device’s keystore, an empty list is returned. This operation deletes a certification path validation policy from the keystore on the device. Certification path validation policies are uniquely identified using certification path validation policy IDs. If no certification path validation policy is stored under the requested certification path validation policy ID, the device shall produce an InvalidCertPathValidationPolicyID fault. If a reference exists for the requested certification path validation policy, the device shall produce a ReferenceExists fault and shall not delete the certification path validation policy. After the certification path validation policy has been deleted, the device may assign its former ID to other certification path validation policies. 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. This operation activates or deactivates TLS client authentication for the TLS server on the device. The TLS server on the device shall require client authentication if and only if clientAuthenticationRequired is set to true. If TLS client authentication is requested to be enabled and no certification path validation policy is assigned to the TLS server, the device shall return an EnablingTLSClientAuthenticationFailed fault and shall not enable TLS client authentication. The device shall execute this command regardless of the TLS enabled/disabled state configured in the ONVIF Device Management Service. This operation returns whether TLS client authentication is active. This operation assigns a certification path validation policy to the TLS server on the device. The TLS server shall enforce the policy when authenticating TLS clients and consider a client authentic if and only if the algorithm returns valid. If no certification path validation policy is stored under the requested CertPathValidationPolicyID, the device shall produce a CertPathValidationPolicyID fault. A TLS server may use different certification path validation policies to authenticate clients. Therefore more than one certification path validation policy may be assigned to the TLS server. If the maximum number of certification path validation policies that may be assigned to the TLS server simultaneously is reached, the device shall produce a MaximumNumberOfTLSCertPathValidationPoliciesReached fault and shall not assign the requested certification path validation policy to the TLS server. This operation removes a certification path validation policy assignment from the TLS server on the device. If the certification path validation policy identified by the requested CertPathValidationPolicyID is not associated to the TLS server, the device shall produce a CertPathValidationPolicy fault. This operation replaces a certification path validation policy assignment to the TLS server on the device with another certification path validation policy assignment. If the certification path validation policy identified by the requested OldCertPathValidationPolicyID is not associated to the TLS server, the device shall produce an OldCertPathValidationPolicyID fault and shall not associate the certification path validation policy identified by the NewCertPathValidationPolicyID to the TLS server. If no certification path validation policy exists under the requested NewCertPathValidationPolicyID in the device’s keystore, the device shall produce a NewCertPathValidationPolicyID fault and shall not remove the association of the old certification path validation policy to the TLS server. This operation returns the IDs of all certification path validation policies that are assigned to the TLS server on the device. 802.1X configuration. (to be written) (to be written) (to be written) (to be written) (to be written) (to be written) (to be written)