diff --git a/doc/Security.xml b/doc/Security.xml index b2b0969dd..835012b12 100644 --- a/doc/Security.xml +++ b/doc/Security.xml @@ -4,12 +4,12 @@ Security Service Specification Security Configuration - 25.06 + 25.12 Draft ONVIF™ www.onvif.org - June 2025 + December 2025 @@ -20,9 +20,24 @@ ONVIF™ All rights reserved. - Recipients of this document may copy, distribute, publish, or display this document so long as this copyright notice, license and disclaimer are retained with all copies of the document. No license is granted to modify this document. - THIS DOCUMENT IS PROVIDED "AS IS," AND THE CORPORATION AND ITS MEMBERS AND THEIR AFFILIATES, MAKE NO REPRESENTATIONS OR WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO, WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, NON-INFRINGEMENT, OR TITLE; THAT THE CONTENTS OF THIS DOCUMENT ARE SUITABLE FOR ANY PURPOSE; OR THAT THE IMPLEMENTATION OF SUCH CONTENTS WILL NOT INFRINGE ANY PATENTS, COPYRIGHTS, TRADEMARKS OR OTHER RIGHTS. - IN NO EVENT WILL THE CORPORATION OR ITS MEMBERS OR THEIR AFFILIATES BE LIABLE FOR ANY DIRECT, INDIRECT, SPECIAL, INCIDENTAL, PUNITIVE OR CONSEQUENTIAL DAMAGES, ARISING OUT OF OR RELATING TO ANY USE OR DISTRIBUTION OF THIS DOCUMENT, WHETHER OR NOT (1) THE CORPORATION, MEMBERS OR THEIR AFFILIATES HAVE BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES, OR (2) SUCH DAMAGES WERE REASONABLY FORESEEABLE, AND ARISING OUT OF OR RELATING TO ANY USE OR DISTRIBUTION OF THIS DOCUMENT.  THE FOREGOING DISCLAIMER AND LIMITATION ON LIABILITY DO NOT APPLY TO, INVALIDATE, OR LIMIT REPRESENTATIONS AND WARRANTIES MADE BY THE MEMBERS AND THEIR RESPECTIVE AFFILIATES TO THE CORPORATION AND OTHER MEMBERS IN CERTAIN WRITTEN POLICIES OF THE CORPORATION. + Recipients of this document may copy, distribute, publish, or display this document so + long as this copyright notice, license and disclaimer are retained with all copies of the + document. No license is granted to modify this document. + THIS DOCUMENT IS PROVIDED "AS IS," AND THE CORPORATION AND ITS MEMBERS AND THEIR + AFFILIATES, MAKE NO REPRESENTATIONS OR WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT + LIMITED TO, WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, + NON-INFRINGEMENT, OR TITLE; THAT THE CONTENTS OF THIS DOCUMENT ARE SUITABLE FOR ANY PURPOSE; + OR THAT THE IMPLEMENTATION OF SUCH CONTENTS WILL NOT INFRINGE ANY PATENTS, COPYRIGHTS, + TRADEMARKS OR OTHER RIGHTS. + IN NO EVENT WILL THE CORPORATION OR ITS MEMBERS OR THEIR AFFILIATES BE LIABLE FOR ANY + DIRECT, INDIRECT, SPECIAL, INCIDENTAL, PUNITIVE OR CONSEQUENTIAL DAMAGES, ARISING OUT OF OR + RELATING TO ANY USE OR DISTRIBUTION OF THIS DOCUMENT, WHETHER OR NOT (1) THE CORPORATION, + MEMBERS OR THEIR AFFILIATES HAVE BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES, OR (2) + SUCH DAMAGES WERE REASONABLY FORESEEABLE, AND ARISING OUT OF OR RELATING TO ANY USE OR + DISTRIBUTION OF THIS DOCUMENT.  THE FOREGOING DISCLAIMER AND LIMITATION ON LIABILITY DO NOT + APPLY TO, INVALIDATE, OR LIMIT REPRESENTATIONS AND WARRANTIES MADE BY THE MEMBERS AND THEIR + RESPECTIVE AFFILIATES TO THE CORPORATION AND OTHER MEMBERS IN CERTAIN WRITTEN POLICIES OF + THE CORPORATION. @@ -50,7 +65,8 @@ Dirk Stegemann, Stefan Andersson - Change Request 1268, 1276, 1349, 1350, 1351, 1352, 1376, 1377, 1378, 1379, 1380, 1381, 1382, 1390 + Change Request 1268, 1276, 1349, 1350, 1351, 1352, 1376, 1377, 1378, 1379, 1380, + 1381, 1382, 1390 1.1 @@ -58,7 +74,8 @@ Dirk Stegemann - Change Request 1528, 1529, 1530, 1531, 1532, 1533, 1534, 1535, 1536, 1543, 1554 + Change Request 1528, 1529, 1530, 1531, 1532, 1533, 1534, 1535, 1536, 1543, + 1554 1.2 @@ -66,7 +83,8 @@ Dirk Stegemann - Change Request 1552, 1555, 1565, 1580, 1583, 1590, 1615, 1616, 1617, 1618, 1619. Added certificate-based client authentication + Change Request 1552, 1555, 1565, 1580, 1583, 1590, 1615, 1616, 1617, 1618, 1619. + Added certificate-based client authentication 1.3 @@ -114,7 +132,8 @@ Oksana Tyushkina, Rick Boer - Fix typo in commands names. Fix inconsistency in Security NoMatchingPrivateKey + Fix typo in commands names. Fix inconsistency in Security + NoMatchingPrivateKey 22.06 @@ -122,7 +141,8 @@ Hans Busch - Fix fault namespace prefix and remove requirement to accept missing MAC when passphrase is present. + Fix fault namespace prefix and remove requirement to accept missing MAC when + passphrase is present. 22.12 @@ -130,7 +150,8 @@ Hans Busch - Do not require to support multiple identical pathes. Remove CRL requirement on client authentication. + Do not require to support multiple identical pathes. Remove CRL requirement on + client authentication. 23.06 @@ -146,7 +167,8 @@ Ottavio Campana, Fredrik Svensson - Added support for ECC cryptography, JSON Web Tokens, Authorization Servers using OAuth2 and OpenID Connect. + Added support for ECC cryptography, JSON Web Tokens, Authorization Servers using + OAuth2 and OpenID Connect. 24.06 @@ -154,13 +176,15 @@ Sriram Bhetanabottla, Hans Busch - Improve readability of section on authorization server. Move JWT example to annex. + Improve readability of section on authorization server. Move JWT example to + annex. 24.12 Dec-2024 - Fredrik Svensson, Sriram Bhetanabottla, Hans Busch, Jose Melancon, Sujith Raman, Kieran McCartan + Fredrik Svensson, Sriram Bhetanabottla, Hans Busch, Jose Melancon, Sujith + Raman, Kieran McCartan Add media signing capabilities and operations. Clarify JWT and OAuth sections. Add CertPathValidationPolicyId to AuthorizationServer & StorageConfiguration. Recommend strong signature selection. Update CreateEccKeyPair and Curve name references. Add annex on TLS ciphers. @@ -176,71 +200,131 @@ Scope - This document defines the web service interface for ONVIF security configuration features such as a keystore and a TLS server on an ONVIF device. - Web service usage is outside of the scope of this document. Please refer to the ONVIF core specification. + This document defines the web service interface for ONVIF security configuration features + such as a keystore and a TLS server on an ONVIF device. + Web service usage is outside of the scope of this document. Please refer to the ONVIF core + specification. Normative References - Basic Security Profile Version 1.1 Committee Specification 01, OASIS Standard, 22 October 2004 - <https://docs.oasis-open.org/ws-brsp/BasicSecurityProfile/v1.1/cs01/BasicSecurityProfile-v1.1-cs01.pdf> + Basic Security Profile Version 1.1 Committee Specification 01, OASIS Standard, 22 October + 2004 + <https://docs.oasis-open.org/ws-brsp/BasicSecurityProfile/v1.1/cs01/BasicSecurityProfile-v1.1-cs01.pdf> IANA TLS Supported Groups, Elliptic curve groups - <> + <> IEEE 802.1X, Port-Based Network Access Control - <http://standards.ieee.org/getieee802/download/802.1X-2004.pdf> + <http://standards.ieee.org/getieee802/download/802.1X-2004.pdf> ONVIF Core Specification - <http://www.onvif.org/specs/core/ONVIF-Core-Specification.pdf> + <http://www.onvif.org/specs/core/ONVIF-Core-Specification.pdf> ONVIF Media Signing Specification <http://www.onvif.org/specs/stream/ONVIF-MediaSigning-Specification.pdf> IETF RFC 2246 The TLS Protocol Version 1.0 - <http://www.ietf.org/rfc/rfc2246.txt> + <http://www.ietf.org/rfc/rfc2246.txt> IETF RFC 2898 PKCS#5 Password-based Cryptography Specification v2.0 - <http://www.ietf.org/rfc/rfc2898.txt> + <http://www.ietf.org/rfc/rfc2898.txt> IETF RFC 2986 PKCS #10: Certification RequestSyntaxSpecification Version 1.7 - <http://www.ietf.org/rfc/rfc2986.txt> - IETF RFC 3279 Algorithms and Identifiers for the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile - <http://www.ietf.org/rfc/rfc3279.txt> - IETF RFC 3447 Public Key Cryptography Standards #1: RSA Cryptography Specifications Version 2.1 - <http://www.ietf.org/rfc/rfc3447.txt> - IETF RFC 4055 Additional Algorithms and Identifiers for RSA Cryptography for use in the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile - <http://www.ietf.org/rfc/rfc4055.txt> + <http://www.ietf.org/rfc/rfc2986.txt> + IETF RFC 3279 Algorithms and Identifiers for the Internet X.509 Public Key Infrastructure + Certificate and Certificate Revocation List (CRL) Profile + <http://www.ietf.org/rfc/rfc3279.txt> + IETF RFC 3447 Public Key Cryptography Standards #1: RSA Cryptography Specifications + Version 2.1 + <http://www.ietf.org/rfc/rfc3447.txt> + IETF RFC 4055 Additional Algorithms and Identifiers for RSA Cryptography for use in the + Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) + Profile + <http://www.ietf.org/rfc/rfc4055.txt> IETF RFC 4346 The Transport Layer Security (TLS) Protocol Version 1.1 - <http://www.ietf.org/rfc/rfc4346.txt> - IETF RFC 5208 Public-Key Cryptography Standards (PKCS) #8: Private-Key Information Syntax Specification v1.2 - <http://www.ietf.org/rfc/rfc5208.txt> + <http://www.ietf.org/rfc/rfc4346.txt> + IETF RFC 5208 Public-Key Cryptography Standards (PKCS) #8: Private-Key Information Syntax + Specification v1.2 + <http://www.ietf.org/rfc/rfc5208.txt> IETF RFC 5246 The Transport Layer Security (TLS) Protocol Version 1.2 - <http://www.ietf.org/rfc/rfc5246.txt> - IETF RFC 8422 Elliptic Curve Cryptography (ECC) Cipher Suites for Transport Layer Security (TLS) Versions 1.2 and Earlier - <https://www.ietf.org/rfc/rfc8422.txt> - IETF RFC 5280 Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile - <http://www.ietf.org/rfc/rfc5280.txt> - IETF RFC 5958 Asymmetric Key Packages - <http://www.ietf.org/rfc/rfc5958.txt> - IETF RFC 5959 Algorithms for Asymmetric Key Package Content Type - <http://www.ietf.org/rfc/rfc5959.txt> + <http://www.ietf.org/rfc/rfc5246.txt> + IETF RFC 8422 Elliptic Curve Cryptography (ECC) Cipher Suites for Transport Layer Security + (TLS) Versions 1.2 and Earlier + <https://www.ietf.org/rfc/rfc8422.txt> + IETF RFC 5280 Internet X.509 Public Key Infrastructure Certificate and Certificate + Revocation List (CRL) Profile + <http://www.ietf.org/rfc/rfc5280.txt> IETF RFC 6749 The OAuth 2.0 Authorization Framework - <http://www.ietf.org/rfc/rfc6749.txt> + <http://www.ietf.org/rfc/rfc6749.txt> IETF RFC 6750 The OAuth 2.0 Authorization Framework: Bearer Token Usage - <http://www.ietf.org/rfc/rfc6750.txt> + <http://www.ietf.org/rfc/rfc6750.txt> + RFC 7292 - PKCS #12: Personal Information Exchange Syntax v1.1 + <> IETF RFC 7517 JSON Web Key (JWK) - <http://www.ietf.org/rfc/rfc7517.txt> + <http://www.ietf.org/rfc/rfc7517.txt> IETF RFC 7518 JSON Web Algorithms (JWA) - <http://www.ietf.org/rfc/rfc7518.txt> + <http://www.ietf.org/rfc/rfc7518.txt> IETF RFC 7519 JSON Web Token (JWT) - <http://www.ietf.org/rfc/rfc7519.txt> + <http://www.ietf.org/rfc/rfc7519.txt> IETF RFC 7643 System for Cross-domain Identity Management: Core Schema - <http://www.ietf.org/rfc/rfc7643.txt> + <http://www.ietf.org/rfc/rfc7643.txt> IETF RFC 8414 OAuth 2.0 Authorization Server Metadata - <http://www.ietf.org/rfc/rfc8414.txt> - IETF RFC 8705 OAuth 2.0 Mutual-TLS Client Authentication and Certificate-Bound Access Tokens - <http://www.ietf.org/rfc/rfc8705.txt> + <http://www.ietf.org/rfc/rfc8414.txt> + IETF RFC 8705 OAuth 2.0 Mutual-TLS Client Authentication and Certificate-Bound Access + Tokens + <http://www.ietf.org/rfc/rfc8705.txt> Unified Modeling Language (UML) - <http://www.omg.org/spec/UML> + <http://www.omg.org/spec/UML> OpenID Connect Core - <https://openid.net/specs/openid-connect-core-1_0.html> + <https://openid.net/specs/openid-connect-core-1_0.html> OpenID Connect Discovery - <https://openid.net/specs/openid-connect-discovery-1_0.html> + <https://openid.net/specs/openid-connect-discovery-1_0.html> PKCS#5 Password-based Encryption Standard v1.5, RSA Laboratories, 1993 PKCS#12: Personal Information Exchange Syntax v1.0, RSA Laboratories, 1999 @@ -387,23 +471,33 @@ CA - Certification Authority + + Certification Authority + CN - Common Name + + Common Name + CRL - Certificate Revocation List + + Certificate Revocation List + CSR - Certificate Signing Request (also called Certification Request) + + Certificate Signing Request (also called Certification Request) + EAP - Extensible Authentication Protocol + + Extensible Authentication Protocol + ECC @@ -413,59 +507,87 @@ HTTP - Hypertext Transfer Protocol + + Hypertext Transfer Protocol + IEEE - Institute of Electrical and Electronics Engineers + + Institute of Electrical and Electronics Engineers + JWS - JSON Web Signature + + JSON Web Signature + JWT - JSON Web Token + + JSON Web Token + MAC - Message Authentication Code + + Message Authentication Code + MD5 - Message Digest Algorithm 5 + + Message Digest Algorithm 5 + MSCHAPv2 - Microsoft’s Challenge Handshake Authentication Protocol version 2 + + Microsoft’s Challenge Handshake Authentication Protocol version 2 + PEAP - Protected EAP + + Protected EAP + SCTP - Stream Control Transmission Protocol + + Stream Control Transmission Protocol + SHA - Secure Hashing Algorithm + + Secure Hashing Algorithm + SSL - Secure Socket Layer + + Secure Socket Layer + TLS - Transport Layer Security + + Transport Layer Security + TTLS - Tunneled TLS + + Tunneled TLS + WS - Web Services + + Web Services + @@ -569,265 +691,311 @@
Certificate Path Verification -
- Certification Path Validation Algorithm Parameters - By default, a device shall use the values defined in for the algorithm parameters defined in RFC 5280, Sect. 6.1.1. - - Default parameter values for the certification path validation algorithm - - - - - - - - Parameter - - - Default - - - Default Value Semantics - - - - - - - User-initial-policy-set - - - Any-policy - - - The device is not concerned about certificate policy. - - - - - Initial-policy-mapping-inhibit - - - 0 - - - Policy mapping is not inhibited. - - - - - Initial-explicit-policy - - - 0 - - - The prospective certification path does not have to be valid for at least one certificate policy in the user-initial-policy-set - - - - - Initial-any-policy-inhibit - - - 0 - - - The any-policy identifier, if asserted in a certificate, does not have to be ignored - - - - - Initial-permitted-subtrees - - - (not specified) - - - No restrictions on the subtree within which all subject names in every certificate in the prospective certification path must fall. - - - - - Initial-excluded-subtrees - - - (not specified) - - - No restrictions on the subtree within which no subject names in any certificate in the prospective certification path may fall. - - - - - CA-information-source-for-v1-and-v2 - - - None - - - The device shall consider X.509 version 1 and version 2 certificates as non-CA certificates. - - - - -
-
-
- Revocation Status Checking - By default, a device shall use the parameter values defined in + Certification Path Validation Algorithm Parameters + By default, a device shall use the values defined in + for the algorithm parameters defined in RFC 5280, Sect. 6.1.1. + + Default parameter values for the certification path validation algorithm + + + + + + + + Parameter + + + Default + + + Default Value Semantics + + + + + + + User-initial-policy-set + + + Any-policy + + + The device is not concerned about certificate policy. + + + + + Initial-policy-mapping-inhibit + + + 0 + + + Policy mapping is not inhibited. + + + + + Initial-explicit-policy + + + 0 + + + The prospective certification path does not have to be valid for at least + one certificate policy in the user-initial-policy-set + + + + + Initial-any-policy-inhibit + + + 0 + + + The any-policy identifier, if asserted in a certificate, does not have to be + ignored + + + + + Initial-permitted-subtrees + + + (not specified) + + + No restrictions on the subtree within which all subject names in every + certificate in the prospective certification path must fall. + + + + + Initial-excluded-subtrees + + + (not specified) + + + No restrictions on the subtree within which no subject names in any + certificate in the prospective certification path may fall. + + + + + CA-information-source-for-v1-and-v2 + + + None + + + The device shall consider X.509 version 1 and version 2 certificates as + non-CA certificates. + + + + +
+
+
+ Revocation Status Checking + By default, a device shall use the parameter values defined in for the parameters specified in RFC 5280, section 6.3.1. For CRL processing see section 6.3.3 of RFC 5280. - - Default parameter values for the revocation status checking algorithm - - - - - - - - Parameter - - - Default - - - Default Value Semantics - - - - - - - Use-deltas - - - False - - - Delta CRLs, if available, are applied to CRLs. - - - - - Relevant-reason-codes - - - All-reasons - - - The device considers a certificate revoked if it has been revoked for any reason defined in RFC 5280. - - - - -
- By default, a device shall consider all trusted sources of revocation information that it has access to when determining the revocation status of a certificate. The device shall consider the certificate in question revoked if and only if at least one such source indicates that the certificate in question is revoked. If one such source is unavailable, the device shall behave as if this source had provided the reply UNDETERMINED. - A device shall consider at least the CRLs that are present in the keystore of the device. - By default, certificates that are considered revoked shall not be included in prospective certification paths. -
-
- Trust Anchors - The trust anchors assigned to the certification path validation policy shall be used as trust anchor input to the certification path validation algorithm specified in RFC 5280. -
-
- Certificate Repository for constructing Certification Paths - By default, the certification path validation shall consider all certificates in the + + Default parameter values for the revocation status checking algorithm + + + + + + + + Parameter + + + Default + + + Default Value Semantics + + + + + + + Use-deltas + + + False + + + Delta CRLs, if available, are applied to CRLs. + + + + + Relevant-reason-codes + + + All-reasons + + + The device considers a certificate revoked if it has been revoked for any + reason defined in RFC 5280. + + + + +
+ By default, a device shall consider all trusted sources of revocation information that + it has access to when determining the revocation status of a certificate. The device shall + consider the certificate in question revoked if and only if at least one such source + indicates that the certificate in question is revoked. If one such source is unavailable, + the device shall behave as if this source had provided the reply UNDETERMINED. + A device shall consider at least the CRLs that are present in the keystore of the + device. + By default, certificates that are considered revoked shall not be included in + prospective certification paths. +
+
+ Trust Anchors + The trust anchors assigned to the certification path validation policy shall be used + as trust anchor input to the certification path validation algorithm specified in RFC + 5280. +
+
+ Certificate Repository for constructing Certification Paths + By default, the certification path validation shall consider all certificates in the keystore on the device when constructing prospective certification paths. -
-
+
+
+ Specific certification path validation parameters + + defines additional certification path validation + parameters. + Specific certification path validation parameters - - defines additional certification path validation parameters. -
- Specific certification path validation parameters - - - - - - - - Parameter - - - Default - - - Default Value Semantics - - - - - - - RequireTLSWWWClientAuthExtendedKeyUsage - - - False - - - If true, a TLS server shall only allow TLS clients to connect that present a client certificate containing the Require WWW client auth extended key usage extension as specified in RFC 5280, Sect. 4.2.1.12. - - - - -
-
+ + + + + + + + Parameter + + + Default + + + Default Value Semantics + + + + + + + RequireTLSWWWClientAuthExtendedKeyUsage + + + False + + + If true, a TLS server shall only allow TLS clients to connect that present a + client certificate containing the Require WWW client auth extended key usage + extension as specified in RFC 5280, Sect. 4.2.1.12. + + + + +
+
JWT-based client authorization
General - Unlike with HTTP Digest and WS-UsernameToken authentication, this specification defines how to associate clients with the different User Levels as defined in the ONVIF Core Specification. Devices are not expected to have the user credentials stored in their memory, instead they will verify that the user has been correctly authenticated by a trusted service based on OpenID Connect and authorize accessing different functions, based on the claims presented in the supplied JWT. JWTs can be presented as headers in case of HTTPS or RTSP, or they can be embedded in SOAP messages, in the form of binary security tokens. In case JWTs are embedded in binary security tokens, their content is base64url-encoded according to RFC 7519. - JWTs consists of three elements: - - - - JOSE header - - - Payload - - - Signature - - - - The JOSE header shall declare that the encoded object is a JSON Web Token by setting the typ parameter to JWT, and the JWT is a JWS that is signed using the algorithm identified by the alg claim with a value defined in RFC7518. Since the keystore does not support symmetric encryption, this specification only mandates asymmetric encryption. - The JWT payload shall include the following standard claims: - - - - iss: Issuer, the URI of the server that generated the JWT. - - - aud: Audience, a list of strings representing the recipients that the JWT is intended for. Each principal intended to process the JWT shall identify itself with a value in the audience claim. If the principal processing the claim does not identify itself with a value in the audience claim when this claim is present, then the JWT shall be rejected. - - - exp: Expiration Time. - - - nbf: Not before. - - - - For the exp, nbf claims, a device shall reject a token when the current time is not within the range of claims nbf and exp. It shall reject a token when at least one of the claims is missing. - The JWT payload shall include the roles claim, as defined within RFC 7643: - - - - roles: Access class. One of the authenticated classes of the default access policy prefixed with the string onvif:, i.e. "onvif:Administrator", "onvif:Operator" or "onvif:User" as defined also within the ONVIF Core Specification. This access level will be used to authorize access to the required function. - - - - The signature is evaluated by applying ECDSA using secp256r1 and SHA-256 hashing to the base64url-encoded header and payload, concatenated by a '.' - ECDSA-SHA256 (base64UrlEncode(header) + "." + + Unlike with HTTP Digest and WS-UsernameToken authentication, this specification + defines how to associate clients with the different User Levels as defined in the ONVIF + Core Specification. Devices are not expected to have the user credentials stored in their + memory, instead they will verify that the user has been correctly authenticated by a + trusted service based on OpenID Connect and authorize accessing different functions, based + on the claims presented in the supplied JWT. JWTs can be presented as headers in case of + HTTPS or RTSP, or they can be embedded in SOAP messages, in the form of binary security + tokens. In case JWTs are embedded in binary security tokens, their content is + base64url-encoded according to RFC 7519. + JWTs consists of three elements: + + + + JOSE header + + + Payload + + + Signature + + + + The JOSE header shall declare that the encoded object is a JSON Web Token by setting + the typ parameter to JWT, and the JWT is a JWS + that is signed using the algorithm identified by the alg claim with a + value defined in RFC7518. Since the keystore does not support symmetric encryption, this + specification only mandates asymmetric encryption. + The JWT payload shall include the following standard claims: + + + + iss: Issuer, the URI of the server that generated the + JWT. + + + aud: Audience, a list of strings representing the + recipients that the JWT is intended for. Each principal intended to process the JWT + shall identify itself with a value in the audience claim. If the principal + processing the claim does not identify itself with a value in the audience claim + when this claim is present, then the JWT shall be rejected. + + + exp: Expiration Time. + + + nbf: Not before. + + + + For the exp, nbf claims, a device shall + reject a token when the current time is not within the range of claims nbf and exp. It + shall reject a token when at least one of the claims is missing. + The JWT payload shall include the roles claim, as defined within + RFC 7643: + + + + roles: Access class. One of the authenticated classes of + the default access policy prefixed with the string onvif:, i.e. + "onvif:Administrator", "onvif:Operator" or "onvif:User" as defined also within the + ONVIF Core Specification. This access level will be used to authorize access to the + required function. + + + + The signature is evaluated by applying ECDSA using secp256r1 and SHA-256 hashing to + the base64url-encoded header and payload, concatenated by a '.' + ECDSA-SHA256 (base64UrlEncode(header) + "." + base64UrlEncode(payload), secp256r1)) - The evaluated signature is further appended to the encoded header and payload with a '.' separator, to get the final JWT. Appendix demonstrates the construction or a JWT. - The signature is used to protect the JWT data integrity and JWT source authenticity. + The evaluated signature is further appended to the encoded header and payload with a + '.' separator, to get the final JWT. Appendix demonstrates + the construction or a JWT. + The signature is used to protect the JWT data integrity and JWT source + authenticity.
Configuration @@ -835,24 +1003,33 @@ Audiences - One or more audience strings. A device shall reject a token if none of the provided strings matches. + + One or more audience strings. A device shall reject a token if none of the + provided strings matches. + TrustedIssuer - Optional list of trusted issuer metadata URIs. A device shall reject a token if the list is - non-empty and the token does not match the information provided via one of the - issuer metadata URIs. + + Optional list of trusted issuer metadata URIs. A device shall reject a token if + the list is non-empty and the token does not match the information provided via one + of the issuer metadata URIs. + KeyID - Optional list of keys. A device shall reject a token if this list is non-empty and none of - the provided keys can verify the signature. + + Optional list of keys. A device shall reject a token if this list is non-empty + and none of the provided keys can verify the signature. + ValidationPolicy - Optional cert path validation policies to verify trusted issuers. If this list is non-empty a - device shall only accept trusted issuers with matching TLS server - certificates. + + Optional cert path validation policies to verify trusted issuers. If this list + is non-empty a device shall only accept trusted issuers with matching TLS server + certificates. + CustomClaims @@ -862,16 +1039,25 @@
Usage of JWT-based client authentication over HTTP - Since authentication tokens contain sensitive information that could be easily used to perform replay attacks, JWT-based client authentication shall not be used over unencrypted HTTP connections. + Since authentication tokens contain sensitive information that could be easily used to + perform replay attacks, JWT-based client authentication shall not be used over unencrypted + HTTP connections.
Usage of JWT-based client authentication over HTTPS - Usage JWT-based client authentication over HTTPS shall adhere to the Authorization Request header Field, as specified by RFC 6750. In case of authentication failure, ONVIF-compliant devices shall respond with the error codes specified by RFC 6750. + Usage JWT-based client authentication over HTTPS shall adhere to the Authorization + Request header Field, as specified by RFC 6750. In case of authentication failure, + ONVIF-compliant devices shall respond with the error codes specified by RFC 6750.
Usage of JWT-based client authentication over SCTP - In scenarios where a SCTP channel is used to exchange commands and responses between the device and the client, it is not possible to embed a JWT within a header. In this case, the JWT can be embedded in the Security Token of the SOAP message, as defined in the WS-Security Basic Security Profile. - A client shall use both ValueType and EncodingType. The device shall reject any Binary Security Token not using both ValueType and EncodingType. + In scenarios where a SCTP channel is used to exchange commands and responses between + the device and the client, it is not possible to embed a JWT within a header. In this + case, the JWT can be embedded in the Security Token of the SOAP message, as defined in the + WS-Security Basic Security Profile. + A client shall use both ValueType and EncodingType. The device shall reject any Binary + Security Token not using both ValueType and + EncodingType. The EncodingType attribute shall have the value of http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security-1.0#BinarySecurityToken The ValueType attribute shall have the value of @@ -879,19 +1065,30 @@
Usage of JWT-based client authentication over RTSP - Since authentication tokens contain sensitive information that could be easily used to perform replay attacks, JWT-based client authentication shall be used with RTSP connections only when HTTPS transport is selected. + Since authentication tokens contain sensitive information that could be easily used to + perform replay attacks, JWT-based client authentication shall be used with RTSP + connections only when HTTPS transport is selected.
Usage of JWT-based client authentication over RTSPS - Since the RTSPS protocol is similar to HTTPS, JWT-based client authentication over RTSPS behaves in the same way as JWT-based client authentication over HTTPS. + Since the RTSPS protocol is similar to HTTPS, JWT-based client authentication over + RTSPS behaves in the same way as JWT-based client authentication over HTTPS.
IEEE 802.1X - IEEE 802.1X is an IEEE standard for port based network access control for the purpose of providing authentication and authorization of the devices attached to LAN ports. It allows access to the LAN port to devices that are configured for access, and prevents access to the LAN port to devices that are not correctly configured. - This specification recommends the adoption of IEEE 802.1X for port based authentication for wireless networks. - This specification defines a set of commands to configure and manage a device’s IEEE 802.1X configurations, both for wireless and hardwired network interfaces. It assumes that IEEE 802.1X configuration and reconfiguration is performed outside of the IEEE 802.1X-secured network. - Many schema elements in this specification include Dot1X as shorthand for IEEE 802.1X. This convention increases the readability of source code generated from the WSDL. + IEEE 802.1X is an IEEE standard for port based network access control for the purpose of + providing authentication and authorization of the devices attached to LAN ports. It allows + access to the LAN port to devices that are configured for access, and prevents access to the + LAN port to devices that are not correctly configured. + This specification recommends the adoption of IEEE 802.1X for port based authentication + for wireless networks. + This specification defines a set of commands to configure and manage a device’s IEEE + 802.1X configurations, both for wireless and hardwired network interfaces. It assumes that + IEEE 802.1X configuration and reconfiguration is performed outside of the IEEE + 802.1X-secured network. + Many schema elements in this specification include Dot1X as shorthand for IEEE 802.1X. + This convention increases the readability of source code generated from the WSDL.
Authorization Servers @@ -1192,7 +1389,8 @@ IEEE 802.1X - The design and data model of the ONVIF Security Configuration Service is reflected in . + The design and data model of the ONVIF Security Configuration Service is reflected in + .
ONVIF Security Configuration Service UML Class Diagram @@ -1206,26 +1404,51 @@ Keystore
Elements of the Keystore - The keystore security feature handles the storage and management of passphrases, keys, and certificates on an ONVIF device. - The keystore specified in this document supports passphrases, keys, key pairs, RSA and ECC key pairs, which are particular types of key pairs, certificates, certification paths, certificate revocation lists, and certification path validation policies. - The boolean attribute externallyGenerated of a key shall be true if and only if the key was generated outside the device. - The boolean attribute securelyStored of a key shall be true if and only if the key is stored in a specially protected hardware component (e.g., a trusted platform module) inside the device. + The keystore security feature handles the storage and management of passphrases, keys, + and certificates on an ONVIF device. + The keystore specified in this document supports passphrases, keys, key pairs, RSA and + ECC key pairs, which are particular types of key pairs, certificates, certification paths, + certificate revocation lists, and certification path validation policies. + The boolean attribute externallyGenerated of a key shall be true + if and only if the key was generated outside the device. + The boolean attribute securelyStored of a key shall be true if + and only if the key is stored in a specially protected hardware component (e.g., a trusted + platform module) inside the device.
Unique Identifiers - An ID is used to uniquely identify objects of a particular type in the keystore on a device, i.e., no two objects of the same type shall have the same ID at any time. - Passphrases in the keystore shall be uniquely identified by passphrase IDs, keys shall be uniquely identified by key IDs, certificates shall be uniquely identified by certificate IDs, certification paths in the keystore shall be uniquely identified by certification path IDs, certificate revocation lists shall be uniquely identified by certificate revocation list IDs, certification path validation policies shall be uniquely identified by certification path validation policy IDs, and IEEE 802.1X configurations shall be uniquely identified by IEEE 802.1X configuration IDs. - It shall be noted that while IDs within a specific type shall be unique, no requirement exists for the uniqueness of IDs across different types. For example, there may be a key and a certificate in the keystore that share the same ID. - Devices may assign the ID of a deleted identified object to another, subsequently generated object. However, devices should avoid re-using IDs as long as possible to avoid race conditions on the client side. - A client may supply an alias for passphrases, keys, certificates, certification paths, certificate revocation lists, certification path validation policies and IEEE 802.1X configurations upon creation, e.g., to facilitate recognizing the created object at a later time. The device shall treat such aliases as unstructured data. + An ID is used to uniquely identify objects of a particular type in the keystore on a + device, i.e., no two objects of the same type shall have the same ID at any time. + Passphrases in the keystore shall be uniquely identified by passphrase IDs, keys shall + be uniquely identified by key IDs, certificates shall be uniquely identified by + certificate IDs, certification paths in the keystore shall be uniquely identified by + certification path IDs, certificate revocation lists shall be uniquely identified by + certificate revocation list IDs, certification path validation policies shall be uniquely + identified by certification path validation policy IDs, and IEEE 802.1X configurations + shall be uniquely identified by IEEE 802.1X configuration IDs. + It shall be noted that while IDs within a specific type shall be unique, no + requirement exists for the uniqueness of IDs across different types. For example, there + may be a key and a certificate in the keystore that share the same ID. + Devices may assign the ID of a deleted identified object to another, subsequently + generated object. However, devices should avoid re-using IDs as long as possible to avoid + race conditions on the client side. + A client may supply an alias for passphrases, keys, certificates, certification paths, + certificate revocation lists, certification path validation policies and IEEE 802.1X + configurations upon creation, e.g., to facilitate recognizing the created object at a + later time. The device shall treat such aliases as unstructured data.
Uniqueness of Objects in the Keystore - A device shall allow multiple copies of the same passphrase to be present in the keystore under different IDs simultaneously. - A device shall allow multiple copies of the same certificate revocation list to be present in the keystore under different IDs, respectively. - A device shall allow multiple copies of the same certification path validation policy to be present in the keystore under different IDs, respectively. - A device shall allow multiple copies of the same IEEE 802.1X configuration to be present in the keystore under different IDs simultaneously. - A device shall not allow multiple copies of the same key to be present in the keystore simultaneously. + A device shall allow multiple copies of the same passphrase to be present in the + keystore under different IDs simultaneously. + A device shall allow multiple copies of the same certificate revocation list to be + present in the keystore under different IDs, respectively. + A device shall allow multiple copies of the same certification path validation policy + to be present in the keystore under different IDs, respectively. + A device shall allow multiple copies of the same IEEE 802.1X configuration to be + present in the keystore under different IDs simultaneously. + A device shall not allow multiple copies of the same key to be present in the keystore + simultaneously.
Referential Integrity @@ -1265,49 +1488,79 @@ Certification path validation policies and security features - A device shall enforce the following referential integrity rules for delete operations: + A device shall enforce the following referential integrity rules for delete + operations: - A key shall not be deleted if it is referenced by a certificate or a security feature. + A key shall not be deleted if it is referenced by a certificate or a security + feature. - A certificate shall not be deleted if it is referenced by a certification path, a certificate revocation list, a certification path validation policy, or a security feature. + A certificate shall not be deleted if it is referenced by a certification path, a + certificate revocation list, a certification path validation policy, or a security + feature. - A certification path shall not be deleted if it is referenced by an IEEE 802.1X configuration or a security feature. + A certification path shall not be deleted if it is referenced by an IEEE 802.1X + configuration or a security feature. - A passphrase shall not be deleted if it is referenced by an IEEE 802.1X configuration. + A passphrase shall not be deleted if it is referenced by an IEEE 802.1X + configuration. - A certification path validation policy shall not be deleted if it is referenced by a security feature. + A certification path validation policy shall not be deleted if it is referenced by + a security feature. - An IEEE 802.1X configuration shall not be deleted if it is referenced by a security feature. + An IEEE 802.1X configuration shall not be deleted if it is referenced by a + security feature. - This integrity rule may be enforced by the following mechanism. Reference counters are maintained for keys, certificates, certification paths, passphrases, and IEEE 802.1X configurations. Each time a reference to an object of these types is added, e.g., by associating a certificate to a key pair or assigning a key pair or certificate to a security feature, the reference counter of the object is incremented. Conversely, if a reference to an object is deleted, the reference counter of the referenced object is decremented. Deleting a key, certificate, or certification path is only permitted if the corresponding reference counter is equal to zero. - A device shall enforce the following referential integrity rules for update operations: + This integrity rule may be enforced by the following mechanism. Reference counters are + maintained for keys, certificates, certification paths, passphrases, and IEEE 802.1X + configurations. Each time a reference to an object of these types is added, e.g., by + associating a certificate to a key pair or assigning a key pair or certificate to a + security feature, the reference counter of the object is incremented. Conversely, if a + reference to an object is deleted, the reference counter of the referenced object is + decremented. Deleting a key, certificate, or certification path is only permitted if the + corresponding reference counter is equal to zero. + A device shall enforce the following referential integrity rules for update + operations: - A key shall not be updated if it is referenced by a certificate or a security feature. However, a private key may be added to an existing key pair if the private key matches the public key in the key pair. If a private key is about to be added to a key pair that already contains the private key to be added, the adding operation shall have no effect. + A key shall not be updated if it is referenced by a certificate or a security + feature. However, a private key may be added to an existing key pair if the + private key matches the public key in the key pair. If a private key is about to be + added to a key pair that already contains the private key to be added, the adding + operation shall have no effect. - A certificate shall not be updated if it is referenced by a certification path, a certificate revocation list, a certification path validation policy, or a security feature. + A certificate shall not be updated if it is referenced by a certification path, a + certificate revocation list, a certification path validation policy, or a security + feature. - A certification path validation policy shall not be updated if it is referenced by a security feature. + A certification path validation policy shall not be updated if it is referenced by + a security feature. - This specification omits APIs for modifying keys or certificates. If a key or certificate is to be updated, it has to be deleted and newly generated with the updated information. If other API exists that allows for modification of keys or certificates, special care shall be taken in order not to break the referential integrity rule. + This specification omits APIs for modifying keys or certificates. If a key or + certificate is to be updated, it has to be deleted and newly generated with the updated + information. If other API exists that allows for modification of keys or certificates, + special care shall be taken in order not to break the referential integrity rule. A device shall enforce the following invariants: - The private key and the public key in an asymmetric key pair in the keystore shall always match, i.e., the asymmetric operation under the public key is the inverse of the corresponding operation under the private key. + The private key and the public key in an asymmetric key pair in the keystore shall + always match, i.e., the asymmetric operation under the public key is the inverse of + the corresponding operation under the private key. - The public key in a certificate in the keystore and the public key in an associated key pair in the keystore shall always be equal for all associated key pairs. + The public key in a certificate in the keystore and the public key in an + associated key pair in the keystore shall always be equal for all associated key + pairs.
@@ -1321,11 +1574,14 @@ - generating (The key is being generated and not yet ready for use) + generating (The key is being generated and not yet ready for + use) - corrupt (The key is corrupt and shall not be used, e.g., because it was not properly generated or a hardware fault corrupted a key that was ready to be used) + corrupt (The key is corrupt and shall not be used, e.g., because + it was not properly generated or a hardware fault corrupted a key that was ready to be + used)
@@ -1336,10 +1592,15 @@
UploadPassphrase This operation uploads a passphrase to the keystore of the device. - Passphrases are uniquely identified using passphrase IDs. The device shall generate a new passphrase ID for the uploaded passphrase. - If the command was successful, the device shall return the ID of the uploaded passphrase. - If the device does not have enough storage capacity for storing the passphrase to be uploaded, the device shall produce a maximum number of passphrases reached fault and shall not upload the supplied passphrase. - If the device cannot process the passphrase to be uploaded, the device shall produce a BadPassphrase fault and shall not upload a passphrase. + Passphrases are uniquely identified using passphrase IDs. The device shall + generate a new passphrase ID for the uploaded passphrase. + If the command was successful, the device shall return the ID of the uploaded + passphrase. + If the device does not have enough storage capacity for storing the passphrase to + be uploaded, the device shall produce a maximum number of passphrases reached fault + and shall not upload the supplied passphrase. + If the device cannot process the passphrase to be uploaded, the device shall + produce a BadPassphrase fault and shall not upload a passphrase. request @@ -1360,10 +1621,13 @@ faults - env:Receiver - ter:Action - ter:MaximumNumberOfPassphrasesReached - The device does not have enough storage space to store the passphrase to be uploaded. + env:Receiver - ter:Action - + ter:MaximumNumberOfPassphrasesReached + The device does not have enough storage space to store the + passphrase to be uploaded. env:Sender - ter:InvalidArgVal - ter:BadPassphrase - The provided passphrase cannot be processed by the device. + The provided passphrase cannot be processed by the + device. @@ -1376,9 +1640,12 @@
GetAllPassphrases - 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 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. request @@ -1389,8 +1656,10 @@ response - PassphraseAttribute - optional, unbounded [tas:PassphraseAttribute] - List of passphrase attributes. Each attribute contains information about a passphrase in the keystore. + PassphraseAttribute - optional, unbounded + [tas:PassphraseAttribute] + List of passphrase attributes. Each attribute contains + information about a passphrase in the keystore. @@ -1410,14 +1679,20 @@
DeletePassphrase This operation deletes a passphrase from the keystore of the device. - Passphrases are uniquely identified using passphrase IDs. If no passphrase is stored under the requested passphrase ID in the keystore, a device shall produce an invalid passphrase ID fault. If there is a passphrase under the requested passphrase ID stored in the keystore and the passphrase could not be deleted, a device shall produce a passphrase deletion failed fault. - After a passphrase is successfully deleted, the device may assign its former ID to other passphrases. + Passphrases are uniquely identified using passphrase IDs. If no passphrase is + stored under the requested passphrase ID in the keystore, a device shall produce an + invalid passphrase ID fault. If there is a passphrase under the requested passphrase + ID stored in the keystore and the passphrase could not be deleted, a device shall + produce a passphrase deletion failed fault. + After a passphrase is successfully deleted, the device may assign its former ID to + other passphrases. request PassphraseID - [tas:PassphraseID] - The ID of the passphrase that is to be deleted from the keystore. + The ID of the passphrase that is to be deleted from the + keystore. @@ -1430,9 +1705,11 @@ faults env:Receiver - ter:Action - ter:PassphraseDeletionFailed - Deleting the passphrase with the requested PassphraseID failed. + Deleting the passphrase with the requested PassphraseID + failed. env:Sender - ter:InvalidArgVal - ter:PassphraseID - No passphrase is stored under the requested PassphraseID. + No passphrase is stored under the requested + PassphraseID. @@ -1448,10 +1725,29 @@ Key Management
CreateRSAKeyPair - This operation triggers the asynchronous generation of an RSA key pair of a particular keylength (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 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 (see Sect. ) whether the generation has finished. The client may also subscribe to Key Status events (see Sect. ) 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.Implementors may estimate the key generation time for a fixed key length as the average elapsed time of a number of key generation operations for this key length. 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 triggers the asynchronous generation of an RSA key pair of a + particular keylength (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 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 (see Sect. ) whether the generation has + finished. The client may also subscribe to Key Status events (see Sect. ) 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. + Implementors may estimate the key generation time for a fixed key length as + the average elapsed time of a number of key generation operations for this key + length. + 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. request @@ -1468,14 +1764,17 @@ KeyID - [tas:KeyID] The key ID of the key pair being generated. EstimatedCreationTime - [xs:duration] - Best-effort estimation of how long the key generation will take. + Best-effort estimation of how long the key generation will + take. faults - env:Receiver - ter:Action - ter:MaximumNumberOfKeysReached - The keystore does not have enough storage space to store the key pair that has to be generated. + env:Receiver - ter:Action - + ter:MaximumNumberOfKeysReached + The keystore does not have enough storage space to store the + key pair that has to be generated. env:Sender - ter:InvalidArgVal - ter:KeyLength The specified key length is not supported by the device. @@ -1490,16 +1789,37 @@
CreateECCKeyPair - This operation triggers the asynchronous generation of an ECC key pair using a particular elliptic curve as specified in RFC 8422, with a suitable key generation mechanism on the device. Keys, especially ECC key pairs, are uniquely identified using key IDs. - If the device does not have 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 (see Sect. ) whether the generation has finished. The client may also subscribe to Key Status events (see Sect. ) 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.Implementors may estimate the key generation time for a fixed key length as the average elapsed time of a number of key generation operations for this key length. 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 triggers the asynchronous generation of an ECC key pair using a + particular elliptic curve as specified in RFC 8422, with a suitable key generation + mechanism on the device. Keys, especially ECC key pairs, are uniquely identified using + key IDs. + If the device does not have 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 (see Sect. ) whether the generation has + finished. The client may also subscribe to Key Status events (see Sect. ) 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. + Implementors may estimate the key generation time for a fixed key length as + the average elapsed time of a number of key generation operations for this key + length. + 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. request EllipticCurve - [xs:string] - The name of the elliptic curve to be used for generating the ECC keypair. Supported curve names can be found in the IANA TLS Supported Groups section, under the Description field. + The name of the elliptic curve to be used for generating the + ECC keypair. Supported curve names can be found in the IANA TLS Supported Groups + section, under the Description field. Alias - optional [xs:string] The client-defined alias of the key. @@ -1510,85 +1830,21 @@ KeyID - [tas:KeyID] The key ID of the key pair being generated. EstimatedCreationTime - [xs:duration] - Best-effort estimation of how long the key generation will take. + Best-effort estimation of how long the key generation will + take. faults - env:Receiver - ter:Action - ter:MaximumNumberOfKeysReached - The keystore does not have enough storage space to store the key pair that has to be generated. - env:Sender - ter:InvalidArgVal - ter:UnsupportedEllipticCurve - The specified elliptic curve is not supported by the device. - - - - access class - - WRITE_SYSTEM - - - -
-
- UploadKeyPairInPKCS8 - This operation uploads a key pair in a PKCS#8 data structure as specified in [RFC 5958, RFC 5959]. - If a passphrase is either directly provided or as ID reference to a previously - uploaded passphrase, the device shall assume that the KeyPair parameter contains an - EncryptedPrivateKeyInfo ASN.1 structure that is encrypted with the given passphrase. - In case neither a passphrase nor a passphrase ID is provided 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. - If the supplied key pair cannot be processed by the device, the device shall produce an UnsupportedPublicKeyAlgorithm fault and shall not store the uploaded key pair in the keystore. - Key pairs are uniquely identified using key IDs. If a key pair exists in the keystore with the public key equal to the public key in the request and this key pair does not contain a private key, the device shall add the supplied private key to the existing key pair and return the ID of this key pair. - If a key pair exists in the keystore with the public key equal to the public key in the request and this key pair contains a private key, the device shall leave the key pair unchanged and return the ID of this key pair. - If the existing key pair does not have status ok, the device shall produce an InvalidKeyStatus fault and shall not modify the existing key pair. - If no key pair exists in the keystore with the public key equal to the public key in the request, the device shall generate a new key pair with the supplied private key and the supplied public key, status ok and the externally generated attribute set to true. Furthermore, the device shall return the ID of this key pair. - If a new key pair is created, the device shall assign the supplied alias to it. Otherwise, the device shall ignore an eventually supplied alias. - If decryption of the EncryptedPrivateKeyInfo failed, the device shall produce a DecryptionFailed fault and shall not store the uploaded key pair in the keystore. - If the device does not have 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. - If no passphrase exists under the ID specified by EncryptionPassphraseID, the device shall produce an invalid passphrase ID fault and shall not store the uploaded key pair in the keystore. - If the supplied PKCS#8 data structure cannot be processed by the device, the device shall produce a BadPKCS8File fault and shall not store the uploaded key pair in the keystore. - If the public key in the uploaded key pair does not match the uploaded private key, the device shall produce a PublicPrivateKeyMismatch fault and shall not store the uploaded key pair in the keystore. - If the command was successful, the device shall return the ID of the key pair in the keystore that contains the supplied public and private key. - - - request - - KeyPair - [tas:Base64DERencodedASN1Value] - The key pair to be uploaded in a PKCS#8 data structure. - Alias - optional [xs:string] - The client-defined alias of the key pair. - EncryptionPassphraseID - optional [tas:PassphraseID] - The ID of the passphrase to use for decrypting the uploaded key pair. - EncryptionPassphrase - optional [xs:string] - The passphrase to use for decrypting the uploaded key pair. - - - - response - - KeyID - [tas:KeyID] - The key ID of the uploaded key pair. - - - - faults - - env:Receiver - ter:Action - ter:MaximumNumberOfKeysReached - The device does not have enough storage space to store the key pair to be uploaded. - env:Sender - ter:InvalidArgVal - ter:PassphraseID - No passphrase is stored under the requested PassphraseID. - env:Sender - ter:InvalidArgVal - ter:DecryptionFailed - The given date could not be decrypted. - env:Sender - ter:InvalidArgVal - ter:UnsupportedPublicKeyAlgorithm - The public key algorithm of the supplied key pair is not supported by the device. - env:Sender - ter:InvalidArgVal - ter:InvalidKeyStatus - The key with the requested KeyID has an inappropriate status. - env:Sender - ter:InvalidArgVal - ter:BadPKCS8File - The PKCS#8 data structure cannot be processed by the device. - env:Sender - ter:InvalidArgVal - ter:PublicPrivateKeyMismatch - The supplied private key does not match the supplied public key. + env:Receiver - ter:Action - + ter:MaximumNumberOfKeysReached + The keystore does not have enough storage space to store the + key pair that has to be generated. + env:Sender - ter:InvalidArgVal - + ter:UnsupportedEllipticCurve + The specified elliptic curve is not supported by the + device. @@ -1601,8 +1857,12 @@
GetKeyStatus - This operation returns the status of a key as defined in Sect. . - 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 the status of a key as defined in Sect. . + An ONVIF conformant device shall support this command. + 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. request @@ -1615,7 +1875,8 @@ response KeyStatus - [xs:string] - Status of the requested key. The value should be one of the values in the tas:KeyStatus enumeration. + Status of the requested key. The value should be one of the + values in the tas:KeyStatus enumeration. @@ -1636,15 +1897,22 @@
GetPrivateKeyStatus (deprecated) 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, an invalid key ID fault shall be produced. If a key is stored under the requested key ID in the keystore, but this key is not a key pair, an invalid key type fault shall be produced. - Otherwise, this operation returns true if the key pair identified by the key ID contains a private key, and false otherwise. - This command is deprecated. Use GetAllKeys (see Sect. ) instead. + Keys are uniquely identified using key IDs. If no key is stored under the + requested key ID in the keystore, an invalid key ID fault shall be produced. If a key + is stored under the requested key ID in the keystore, but this key is not a key pair, + an invalid key type fault shall be produced. + Otherwise, this operation returns true if the key pair + identified by the key ID contains a private key, and false + otherwise. + This command is deprecated. Use GetAllKeys (see Sect. ) instead. request KeyID - [tas:KeyID] - The ID of the key pair for which to return whether it contains a private key. + The ID of the key pair for which to return whether it contains + a private key. @@ -1660,7 +1928,8 @@ ter:Sender - ter:InvalidArgVal - ter:KeyID No key is stored under the requested KeyID. ter:Sender - ter:InvalidArgVal - ter:InvalidKeyType - The key stored in the keystore under the requested KeyID is of an invalid type. + The key stored in the keystore under the requested KeyID is of + an invalid type. @@ -1673,9 +1942,12 @@
GetAllKeys - 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 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. An ONVIF conformant + device shall support this command. request @@ -1687,7 +1959,8 @@ response KeyAttribute - optional, unbounded [tas:KeyAttribute] - List of key attributes. Each attribute contains information about a key in the keystore. + List of key attributes. Each attribute contains information + about a key in the keystore. @@ -1706,15 +1979,25 @@
DeleteKey - 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 deletes a key from the device’s keystore. An ONVIF conformant + device shall support this command. + 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. request KeyID - [tas:KeyID] - The ID of the key that is to be deleted from the keystore. + The ID of the key that is to be deleted from the + keystore. @@ -1747,14 +2030,36 @@ Certificate Management
CreatePKCS10CSR - 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. - The subject parameter describes the entity that the public key belongs to. Additional attributes can be included in the attribute parameter. - Distinguished name attribute values shall be supplied either in UTF-8 or in hexadecimal form as specified in RFC 4514. - If the distinguished name attribute value is supplied in hexadecimal form, the device shall encode the attribute in the format given in the hexadecimal format. - If the distinguished name attribute value is supplied in UTF-8 and the attribute value has a uniquely defined encoding (e.g., CountryName is defined as PrintableString), the device shall encode the attribute as the defined encoding. Otherwise, the device shall encode the attribute value as UTF-8. - 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. 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 specified subject is invalid or incomplete, a Subject invalid fault shall be produced and no CSR shall be created. If an attribute is invalid or incomplete, an Attribute invalid 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 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. + The subject parameter describes the entity that the public key belongs to. + Additional attributes can be included in the attribute parameter. + Distinguished name attribute values shall be supplied either in UTF-8 or in + hexadecimal form as specified in RFC 4514. + If the distinguished name attribute value is supplied in hexadecimal form, the + device shall encode the attribute in the format given in the hexadecimal + format. + If the distinguished name attribute value is supplied in UTF-8 and the attribute + value has a uniquely defined encoding (e.g., CountryName is defined as + PrintableString), the device shall encode the attribute as the defined encoding. + Otherwise, the device shall encode the attribute value as UTF-8. + 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. 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 specified subject is invalid or incomplete, a + Subject invalid fault shall be produced and no CSR shall be created. If an attribute + is invalid or incomplete, an Attribute invalid 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. request @@ -1764,7 +2069,8 @@ KeyID - [tas:KeyID] The ID of the key for which the CSR shall be created. CSRAttribute - optional, unbounded [tas:CSRAttribute] - List of CSR attributes. Each attribute contains an attribute to be included in the CSR. + List of CSR attributes. Each attribute contains an attribute to + be included in the CSR. SignatureAlgorithm - [tas:AlgorithmIdentifier] The signature algorithm to be used to sign the CSR. @@ -1780,15 +2086,21 @@ faults ter:Receiver - ter:Action - CSRCreationFailed - The generation of the PKCS#10 certification request failed. + The generation of the PKCS#10 certification request + failed. ter:Sender - ter:InvalidArgVal - ter:KeyID No key is stored under the requested KeyID. - ter:Sender - ter:InvalidArgVal - ter:UnsupportedSignatureAlgorithm - The specified signature algorithm is not supported by the device. - ter:Sender - ter:InvalidArgVal - ter:KeySignatureAlgorithmMismatch - The specified public key is an invalid input to the specified signature algorithm. + ter:Sender - ter:InvalidArgVal - + ter:UnsupportedSignatureAlgorithm + The specified signature algorithm is not supported by the + device. + ter:Sender - ter:InvalidArgVal - + ter:KeySignatureAlgorithmMismatch + The specified public key is an invalid input to the specified + signature algorithm. ter:Sender - ter:InvalidArgVal - ter:InvalidKeyStatus - The key with the requested KeyID has an inappropriate status. + The key with the requested KeyID has an inappropriate + status. ter:Sender - ter:InvalidArgVal - ter:InvalidSubject The specified subject is invalid or incomplete. ter:Sender - ter:InvalidArgVal - ter:InvalidAttribute @@ -1805,41 +2117,90 @@
CreateSelfSignedCertificate - 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. If no X509Version is specified in the request, the device shall produce an X.509v3 certificate. - 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. - If the specified subject is invalid or incomplete, an InvalidSubject fault shall be produced and no certificate shall be created. - The notValidBefore parameter specifies at which point in time the validity period of the generated certificate shall begin. If this parameter is not specified in the request, the device shall use its current time or a time before its current time as starting point of the validity period. The notValidAfter parameter specifies at which point in time the validity period of the generated certificate shall end. If this parameter is not specified in the request, the device shall assign the GeneralizedTime value of 99991231235959Z as specified in RFC 5280 to the notValidAfter parameter. If the notValidBefore parameter is invalid, an invalid DateTime fault shall be produced and no certificate shall be generated. If the notValidAfter parameter is invalid, an invalid DateTime fault shall be produced 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. - 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 RFC5280, Sect. 4.2 as mandatory for CAs that issue self-signed certificates. - Distinguished name attribute values shall be supplied either in UTF-8 or in hexadecimal form as specified in RFC 4514. - If the distinguished name attribute value is supplied in hexadecimal form, the device shall encode the attribute in the format given in the hexadecimal format. - If the distinguished name attribute value is supplied in UTF-8 and the attribute value has a uniquely defined encoding (e.g., CountryName is defined as PrintableString), the device shall encode the attribute as the defined encoding. Otherwise, the device shall encode the attribute value as UTF-8. - RFC 5280, Sect. 4.1.2.2 mandates that the certificate serial numbers be unique for each certificate issued by a given issuer (a CA). Since the subject is equal to the issuer in a self-signed certificate, the serial number shall be unique for each self-signed certificate that the device issues for a given subject. - The generated certificate shall not contain a unique identifier as specified in RFC 5280, Sect. 4.1.2.8. The device shall not mark the generated certificate as trusted. - 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 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 generates for a 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 certificates as defined in the security baseline and may additionally be + able to handle other X.509 certificate formats as indicated by the X.509Versions + capability. If no X509Version is specified in the request, the device shall produce a + certificate accordinting to the baseline. + 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. + If the specified subject is invalid or incomplete, an InvalidSubject fault shall + be produced and no certificate shall be created. + The notValidBefore parameter specifies at which point in time the validity period + of the generated certificate shall begin. If this parameter is not specified in the + request, the device shall use its current time or a time before its current time as + starting point of the validity period. The notValidAfter parameter specifies at which + point in time the validity period of the generated certificate shall end. If this + parameter is not specified in the request, the device shall assign the GeneralizedTime + value of 99991231235959Z as specified in RFC 5280 to the notValidAfter parameter. If + the notValidBefore parameter is invalid, an invalid DateTime fault shall be produced + and no certificate shall be generated. If the notValidAfter parameter is invalid, an + invalid DateTime fault shall be produced 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. + 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 the security baseline, Sect. 4.2 as mandatory for CAs + that issue self-signed certificates. + Distinguished name attribute values shall be supplied either in UTF-8 or in + hexadecimal form as specified in RFC 4514. + If the distinguished name attribute value is supplied in hexadecimal form, the + device shall encode the attribute in the format given in the hexadecimal + format. + If the distinguished name attribute value is supplied in UTF-8 and the attribute + value has a uniquely defined encoding (e.g., CountryName is defined as + PrintableString), the device shall encode the attribute as the defined encoding. + Otherwise, the device shall encode the attribute value as UTF-8. + RFC 5280, Sect. 4.1.2.2 mandates that the certificate serial numbers be unique for + each certificate issued by a given issuer (a CA). Since the subject is equal to the + issuer in a self-signed certificate, the serial number shall be unique for each + self-signed certificate that the device issues for a given subject. + The generated certificate shall not contain a unique identifier as specified in + RFC 5280, Sect. 4.1.2.8. The device shall not mark the generated certificate as + trusted. + 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 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. request X509Version - optional [xs:positiveInteger] - The X.509 version that the generated certificate shall comply to. + The X.509 version that the generated certificate shall comply + to. Subject - [tas:DistinguishedName] - Distinguished name of the entity that the certificate shall belong to. + Distinguished name of the entity that the certificate shall + belong to. KeyID - [tas:KeyID] - The ID of the key for which the certificate shall be created. + The ID of the key for which the certificate shall be + created. Alias - optional [xs:string] - The client-defined alias of the certificate to be created. + The client-defined alias of the certificate to be + created. notValidBefore - optional [xs:dateTime] - The X.509 not valid before information to be included in the certificate. Defaults to a time equal to or before the device’s current time. + The X.509 not valid before information to be included in the + certificate. Defaults to a time equal to or before the device’s current + time. notValidAfter - optional [xs:dateTime] - The X.509 not valid after information to be included in the certificate. Defaults to the time 99991231235959Z as specified in RFC 5280. + The X.509 not valid after information to be included in the + certificate. Defaults to the time 99991231235959Z as specified in RFC + 5280. SignatureAlgorithm - [tas:AlgorithmIdentifier] - The signature algorithm to be used for signing the certificate. + The signature algorithm to be used for signing the + certificate. Extension - optional, unbounded [tas:X509v3Extension] - List of X.509v3 extensions to be included in the certificate. + List of X.509v3 extensions to be included in the + certificate. @@ -1852,22 +2213,34 @@ faults - ter:Receiver - ter:Action - ter:CertificateCreationFailed + ter:Receiver - ter:Action - + ter:CertificateCreationFailed The generation of the self-signed certificate failed. - ter:Receiver - ter:Action - ter:MaximumNumberOfCertificatesReached - The device does not have enough storage space to store the certificate to be created. - ter:Sender - ter:InvalidArgVal - ter:UnsupportedX509Version - The specified X.509 version is not supported by the device. + ter:Receiver - ter:Action - + ter:MaximumNumberOfCertificatesReached + The device does not have enough storage space to store the + certificate to be created. + ter:Sender - ter:InvalidArgVal - + ter:UnsupportedX509Version + The specified X.509 version is not supported by the + device. ter:Sender - ter:InvalidArgVal - ter:KeyID No key is stored under the requested KeyID. - ter:Sender - ter:InvalidArgVal - ter:UnsupportedSignatureAlgorithm - The specified signature algorithm is not supported by the device. - ter:Sender - ter:InvalidArgVal - ter:KeySignatureAlgorithmMismatch - The specified public key is an invalid input to the specified signature algorithm. - ter:Sender - ter:InvalidArgVal - ter:X509VersionExtensionsMismatch - The request contains extensions which are not supported by the X509Version in the request. + ter:Sender - ter:InvalidArgVal - + ter:UnsupportedSignatureAlgorithm + The specified signature algorithm is not supported by the + device. + ter:Sender - ter:InvalidArgVal - + ter:KeySignatureAlgorithmMismatch + The specified public key is an invalid input to the specified + signature algorithm. + ter:Sender - ter:InvalidArgVal - + ter:X509VersionExtensionsMismatch + The request contains extensions which are not supported by the + X509Version in the request. ter:Sender - ter:InvalidArgVal - ter:InvalidKeyStatus - The key with the requested KeyID has an inappropriate status. + The key with the requested KeyID has an inappropriate + status. ter:Sender - ter:InvalidArgVal - ter:InvalidSubject The specified subject is invalid or incomplete. ter:Sender - ter:InvalidArgVal - ter:InvalidDateTime @@ -1884,43 +2257,90 @@
UploadCertificate - 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. - 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. + 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. + An ONVIF compliant device supporting the security service shall support this + command. + 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 key pair 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, then NoMatchingPrivateKey fault shall be produced and the certificate shall not be stored 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 key pair 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, then NoMatchingPrivateKey fault shall be + produced and the certificate shall not be stored in the keystore. The device shall assign the supplied Alias to the uploaded certificate. - If a new key pair is generated, the device shall assign the supplied KeyAlias to it. Otherwise, the device shall ignore an eventually supplied KeyAlias. - How the link between the uploaded certificate and a key pair is established is illustrated in . + If a new key pair is generated, the device shall assign the supplied KeyAlias to + it. Otherwise, the device shall ignore an eventually supplied KeyAlias. + How the link between the uploaded certificate and a key pair is established is + illustrated in . + An ONVIF compliant device shall support this command.
- Link establishment between certificate and key pair for Upload Certificate + Link establishment between certificate and key pair for Upload + Certificate
- If the key pair that the certificate shall be linked to does not have status ok, an InvalidKeyStatus fault is produced, and the uploaded certificate is not stored in the keystore. - If the signature algorithm that the signature of the supplied certificate is based on is not supported by the device, the device shall generate an UnsupportedSignatureAlgorithm fault and shall not store the uploaded certificate nor the contained public key 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. + If the key pair that the certificate shall be linked to does not have status + ok, an InvalidKeyStatus fault is produced, and the uploaded + certificate is not stored in the keystore. + If the signature algorithm that the signature of the supplied certificate is based + on is not supported by the device, the device shall generate an + UnsupportedSignatureAlgorithm fault and shall not store the uploaded certificate nor + the contained public key 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. The device shall not mark the uploaded certificate as trusted. - If the device does not have 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 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. - If the command was successful, the device returns the ID of the uploaded certificate and the ID of the key pair that contains the public key in the certificate. + If the device does not have 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 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. + If the command was successful, the device returns the ID of the uploaded + certificate and the ID of the key pair that contains the public key in the + certificate. request Certificate - [tas:Base64DERencodedASN1Value] - The base64-encoded DER representation of the X.509 certificate to be uploaded. + The base64-encoded DER representation of the X.509 certificate + to be uploaded. Alias - optional [xs:string] The client-defined alias of the certificate. KeyAlias - optional [xs:string] The client-defined alias of the key pair. PrivateKeyRequired - optional [xs:boolean] - Indicates if the device shall verify that a matching key pair with a private key exists in the keystore. + Indicates if the device shall verify that a matching key pair + with a private key exists in the keystore. @@ -1929,24 +2349,35 @@ CertificateID - [tas:CertificateID] The ID of the uploaded certificate. KeyID - [tas:KeyID] - The ID of the key that the uploaded certificate certifies. + The ID of the key that the uploaded certificate + certifies. faults - ter:Receiver - ter:Action - ter:MaximumNumberOfCertificatesReached - The device does not have enough storage space to store the certificate to be uploaded. - ter:Receiver - ter:Action - ter:MaximumNumberOfKeysReached - The device does not have enough storage space to store the key pair to be uploaded. + ter:Receiver - ter:Action - + ter:MaximumNumberOfCertificatesReached + The device does not have enough storage space to store the + certificate to be uploaded. + ter:Receiver - ter:Action - + ter:MaximumNumberOfKeysReached + The device does not have enough storage space to store the key + pair to be uploaded. ter:Receiver - ter:Action - ter:NoMatchingPrivateKey - The keystore does not contain a key pair with a private key that matches the public key in the uploaded certificate. + The keystore does not contain a key pair with a private key that + matches the public key in the uploaded certificate. ter:Sender - ter:InvalidArgVal - ter:BadCertificate - The supplied certificate file cannot be processed by the device. - ter:Sender - ter:InvalidArgVal - ter:UnsupportedPublicKeyAlgorithm - The public key algorithm of the public key in the certificate is not supported by the device. - ter:Sender - ter:InvalidArgVal - ter:UnsupportedSignatureAlgorithm - The specified signature algorithm is not supported by the device. + The supplied certificate file cannot be processed by the + device. + ter:Sender - ter:InvalidArgVal - + ter:UnsupportedPublicKeyAlgorithm + The public key algorithm of the public key in the certificate + is not supported by the device. + ter:Sender - ter:InvalidArgVal - + ter:UnsupportedSignatureAlgorithm + The specified signature algorithm is not supported by the + device. ter:Sender - ter:InvalidArgVal - ter:InvalidKeyStatus The key pair has an inappropriate status. ter:Sender - ter:InvalidArgVal - ter:Duplicate @@ -1963,77 +2394,145 @@
UploadCertificateWithPrivateKeyInPKCS12 - 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. - If a passphrase is supplied, the device shall ignore an eventually supplied integrity passphrase ID and an eventually supplied encryption passphrase ID, and the device shall use the supplied passphrase to check the integrity of the PKCS#12 PFX and to decrypt the PKCS8ShroudedKeyBag and the CertBag instances. If a passphrase is supplied, but a CertBag is not encrypted, the device shall ignore the supplied passphrase when processing this CertBag. If a passphrase is supplied, but a KeyBag is supplied instead of a PKCS8ShroudedKeyBag, the device shall ignore the supplied passphrase when processing the KeyBag. - If decryption of either the PKCS8ShroudedKeyBag or an encrypted CertBag failed, the device shall produce a DecryptionFailed fault and shall not store the uploaded certificates nor key pair in the keystore. - If the signature algorithm of a supplied certificate is not supported by the device, the device shall produce an UnsupportedSignatureAlgorithm fault and shall not upload a certificate nor key pair. - If the supplied key pair cannot be processed by the device, the device shall produce an UnsupportedPublicKeyAlgorithm fault and shall not store the uploaded key pair nor the uploaded certificates in the keystore. - Certificates are uniquely identified using certificate IDs. The device shall store the uploaded certificates in the keystore and generate a new certificate ID for each of the uploaded certificates. - Certification paths are uniquely identified using certification path IDs. The device shall create a certification path from the uploaded certificates. In this certification path, the certificates shall appear in the same order as in the PKCS#12 file. The device shall generate a new certification path ID for the created certification path and assign the eventually supplied CertificationPathAlias to the created certification path. - The signature of each certificate in the sequence of uploaded certificates except for the last one shall be verifiable with the public key contained in the next certificate in the sequence. If there is a certificate in the request other than the last certificate for which the signature cannot be verified with the public key in the next certificate, the device shall produce an invalid certification path fault and shall not store the uploaded certificates nor uploaded private key in the keystore. - If the device cannot process one of the uploaded certificates, it shall produce a BadCertificate fault and neither store the uploaded certificates nor private key in the 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 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. + A device signaling support for PKCS12 shall support uploading of PKCS12 files + according to RFC 7292. + 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. + If an integrity passphrase ID is supplied, the device shall use the corresponding + passphrase in the keystore to decrypt 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 any encrypted content. + If a passphrase is supplied, the device shall ignore an eventually supplied + integrity passphrase ID and an eventually supplied encryption passphrase ID, and the + device shall use the supplied passphrase to check the integrity and to decrypt the + encrypted content. + If decryption of either the PKCS8ShroudedKeyBag or an encrypted CertBag failed, + the device shall produce a DecryptionFailed fault and shall not store the uploaded + certificates nor key pair in the keystore. + If the signature algorithm of a supplied certificate is not supported by the + device, the device shall produce an UnsupportedSignatureAlgorithm fault and shall not + upload a certificate nor key pair. + If the supplied key pair cannot be processed by the device, the device shall + produce an UnsupportedPublicKeyAlgorithm fault and shall not store the uploaded key + pair nor the uploaded certificates in the keystore. + Certificates are uniquely identified using certificate IDs. The device shall store + the uploaded certificates in the keystore and generate a new certificate ID for each + of the uploaded certificates. + Certification paths are uniquely identified using certification path IDs. The + device shall create a certification path from the uploaded certificates. In this + certification path, the certificates shall appear in the same order as in the PKCS#12 + file. The device shall generate a new certification path ID for the created + certification path and assign the eventually supplied CertificationPathAlias to the + created certification path. + The signature of each certificate in the sequence of uploaded certificates except + for the last one shall be verifiable with the public key contained in the next + certificate in the sequence. If there is a certificate in the request other than the + last certificate for which the signature cannot be verified with the public key in the + next certificate, the device shall produce an invalid certification path fault and + shall not store the uploaded certificates nor uploaded private key in the + keystore. + If the device cannot process one of the uploaded certificates, it shall produce a + BadCertificate fault and neither store the uploaded certificates nor private key in + the 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. The device shall not mark the uploaded certificates as trusted. - The uploaded certificates have to be linked to key pairs in the keystore. Key pairs are uniquely identified using key IDs. - If a key pair exists in the keystore with the public key equal to the public key in a certificate in the request, the device shall link the uploaded certificate to the key pair in the keystore by adding a reference from the certificate to the key pair. If the key pair in the keystore does not contain a private key and the private key contained in the KeyBag or PKCS8ShroudedKeyBag that matches the public key in the key pair, the device shall add the private key contained in the KeyBag or PKCS8ShroudedKeyBag to the key pair. - If no key pair exists in the keystore with the public key equal to the public key in a certificate in the request, the device shall create a new key pair with status ok, externally generated attribute set to true, and the public and private keys from the request, and shall link this key pair to the uploaded certificate by adding a reference from the certificate to the key pair. - If a new key pair is created for the uploaded private key, the device shall assign the supplied KeyAlias to it. Otherwise, the device shall ignore an eventually supplied KeyAlias. - How the link between an uploaded certificate and a key pair is established is illustrated in . + The uploaded certificates have to be linked to key pairs in the keystore. Key + pairs are uniquely identified using key IDs. + If a key pair exists in the keystore with the public key equal to the public key + in a certificate in the request, the device shall link the uploaded certificate to the + key pair in the keystore by adding a reference from the certificate to the key pair. + If the key pair in the keystore does not contain a private key and the private key + contained in the KeyBag or PKCS8ShroudedKeyBag that matches the public key in the key + pair, the device shall add the private key contained in the KeyBag or + PKCS8ShroudedKeyBag to the key pair. + If no key pair exists in the keystore with the public key equal to the public key + in a certificate in the request, the device shall create a new key pair with status + ok, externally generated attribute set to true, and the public + and private keys from the request, and shall link this key pair to the uploaded + certificate by adding a reference from the certificate to the key pair. + If a new key pair is created for the uploaded private key, the device shall assign + the supplied KeyAlias to it. Otherwise, the device shall ignore an eventually supplied + KeyAlias. + How the link between an uploaded certificate and a key pair is established is + illustrated in .
- Link establishment between certificates and key pair for Upload Certificate with Private Key in PKCS#12 + Link establishment between certificates and key pair for Upload Certificate + with Private Key in PKCS#12
- If the key pair that a certificate shall be linked to does not have status ok, the device shall produce an invalid key status fault and shall not store the uploaded certificates nor the uploaded key pair in the keystore. - If the device does not have enough storage capacity for storing the certificates to be uploaded, the device shall produce a maximum number of certificates reached fault and shall not store the uploaded certificates nor the uploaded key pair in the keystore. - If the device does not have 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 store a key pair and shall not store the uploaded certificates in the keystore. - If the device does not have enough storage capacity for storing the certification path to be created, the device shall produce a maximum number of certification paths reached fault and shall not store the uploaded certificates nor the uploaded key pair in the keystore. - If no passphrase exists under the ID specified by IntegrityPassphraseID, the device shall produce an invalid passphrase ID fault and shall not store the uploaded certificates nor the uploaded key pair in the keystore. - If no passphrase exists under the ID specified by EncryptionPassphraseID, the device shall produce an invalid passphrase ID fault and shall not store the uploaded certificates nor the uploaded key pair in the keystore. - If the supplied PKCS#12 data structure cannot be processed by the device, the device shall produce a BadPKCS12File fault and shall not store the uploaded certificates nor the uploaded key pair in the keystore. - If the public key in the first uploaded certificate does not match the uploaded private key, the device shall produce a PublicPrivateKeyMismatch fault and shall not store the uploaded certificates nor the uploaded key pair in the keystore. - If the command was successful, the device shall return the ID of the created certification path and the ID of the key pair that contains the public key in the certificate. + If the key pair that a certificate shall be linked to does not have status + ok, the device shall produce an invalid key status fault and + shall not store the uploaded certificates nor the uploaded key pair in the + keystore. + If the device does not have enough storage capacity for storing the certificates + to be uploaded, the device shall produce a maximum number of certificates reached + fault and shall not store the uploaded certificates nor the uploaded key pair in the + keystore. + If the device does not have 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 store a key pair and shall not store + the uploaded certificates in the keystore. + If the device does not have enough storage capacity for storing the certification + path to be created, the device shall produce a maximum number of certification paths + reached fault and shall not store the uploaded certificates nor the uploaded key pair + in the keystore. + If no passphrase exists under the ID specified by IntegrityPassphraseID, the + device shall produce an invalid passphrase ID fault and shall not store the uploaded + certificates nor the uploaded key pair in the keystore. + If no passphrase exists under the ID specified by EncryptionPassphraseID, the + device shall produce an invalid passphrase ID fault and shall not store the uploaded + certificates nor the uploaded key pair in the keystore. + If the supplied PKCS#12 data structure cannot be processed by the device, the + device shall produce a BadPKCS12File fault and shall not store the uploaded + certificates nor the uploaded key pair in the keystore. + If the public key in the first uploaded certificate does not match the uploaded + private key, the device shall produce a PublicPrivateKeyMismatch fault and shall not + store the uploaded certificates nor the uploaded key pair in the keystore. + If the command was successful, the device shall return the ID of the created + certification path and the ID of the key pair that contains the public key in the + certificate. request CertWithPrivateKey - [tas:Base64DERencodedASN1Value] - The certifcates and key pair to be uploaded in a PKCS#12 data structure. + The certifcates and key pair to be uploaded in a PKCS#12 data + structure. CertificationPathAlias - optional [xs:string] The client-defined alias of the certification path. KeyAlias - optional [xs:string] The client-defined alias of the key pair. IgnoreAdditionalCertificates - optional [xs:boolean] - True if and only if the device shall behave as if the client had only supplied the first certificate in the sequence of certificates. + True if and only if the device shall behave as if the client + had only supplied the first certificate in the sequence of certificates. IntegrityPassphraseID - optional [tas:PassphraseID] - 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 integrity checking of the + uploaded PKCS#12 data structure. EncryptionPassphraseID - optional [tas:PassphraseID] - The ID of the passphrase to use for decrypting the uploaded PKCS#12 data structure. + The ID of the passphrase to use for decrypting the uploaded + PKCS#12 data structure. Passphrase - optional [xs:string] - The passphrase to use for integrity checking and decrypting the uploaded PKCS#12 data structure. + The passphrase to use for integrity checking and decrypting the + uploaded PKCS#12 data structure. response CertificationPathID - [tas:CertificationPathID] - The certification path ID of the uploaded certification path. + The certification path ID of the uploaded certification + path. KeyID - [tas:KeyID] The key ID of the uploaded key pair. @@ -2043,31 +2542,48 @@ ter:Receiver - ter:Action - ter: - MaximumNumberOfCertificatesReached The device does not have enough storage space to store the certificate to be uploaded. + MaximumNumberOfCertificatesReached The device + does not have enough storage space to store the certificate to be + uploaded. ter:Receiver - ter:Action - ter: - MaximumNumberOfKeysReached The device does not have enough storage space to store the key pair that has to be generated. + MaximumNumberOfKeysReached The device does not + have enough storage space to store the key pair that has to be generated. ter:Receiver - ter:Action - ter: - MaximumNumberOfCertificationPathsReached The device does not have enough storage space to store the certification path to be uploaded. + MaximumNumberOfCertificationPathsReached The + device does not have enough storage space to store the certification path to be + uploaded. ter:Sender - ter:InvalidArgVal - ter:PassphraseID - No passphrase is stored under the requested PassphraseID. + No passphrase is stored under the requested + PassphraseID. env:Sender - ter:InvalidArgVal - ter:DecryptionFailed The given data could not be decrypted. env:Sender - ter:InvalidArgVal - ter:BadCertificate - The supplied certificate file cannot be processed by the device. - env:Sender - ter:InvalidArgVal - ter:UnsupportedPublicKeyAlgorithm - The public key algorithm of the public key in the certificate is not supported by the device. - env:Sender - ter:InvalidArgVal - ter:UnsupportedSignatureAlgorithm - The signature algorithm that the signature of the supplied certificate is based on is not supported by the device. + The supplied certificate file cannot be processed by the + device. + env:Sender - ter:InvalidArgVal - + ter:UnsupportedPublicKeyAlgorithm + The public key algorithm of the public key in the certificate + is not supported by the device. + env:Sender - ter:InvalidArgVal - + ter:UnsupportedSignatureAlgorithm + The signature algorithm that the signature of the supplied + certificate is based on is not supported by the device. env:Sender - ter:InvalidArgVal - ter:InvalidKeyStatus - The key with the requested KeyID has an inappropriate status. + The key with the requested KeyID has an inappropriate + status. env:Sender - ter:InvalidArgVal - ter:BadPKCS12File - The PKCS#12 data structure cannot be processed by the device. - env:Sender - ter:InvalidArgVal - ter:PublicPrivateKeyMismatch - The supplied private key does not match the supplied public key. - env:Sender - ter: InvalidArgVal - ter:InvalidCertificationPath - At least one certificate in the certification path is not correctly signed with the public key in the next certificate in the path. + The PKCS#12 data structure cannot be processed by the + device. + env:Sender - ter:InvalidArgVal - + ter:PublicPrivateKeyMismatch + The supplied private key does not match the supplied public + key. + env:Sender - ter: InvalidArgVal - + ter:InvalidCertificationPath + At least one certificate in the certification path is not + correctly signed with the public key in the next certificate in the path. @@ -2080,10 +2596,14 @@
GetCertificate - 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. + This operation returns a specific certificate from the device’s keystore. An ONVIF + compliant device supporting the security service shall support this command. + 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. The certificate shall be returned in DER encoding. - It shall be noted that this command does not return the private key that is associated with the public key in the certificate. + It shall be noted that this command does not return the private key that is + associated with the public key in the certificate. request @@ -2103,7 +2623,8 @@ faults env:Sender - ter:InvalidArgVal - ter:CertificateID - No certificate is stored under the requested CertificateID. + No certificate is stored under the requested + CertificateID. @@ -2116,10 +2637,14 @@
GetAllCertificates - This operation returns 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. + This operation returns all certificates that are stored in the device’s keystore. + An ONVIF compliant device shall support this command. An ONVIF compliant device + supporting the security service shall support this command. + This operation may be used, e.g., if a client lost track of which certificates are + present on the device. The certificates shall be returned in DER encoding. - If no certificate is stored in the device’s keystore, an empty list is returned. + If no certificate is stored in the device’s keystore, an empty list is + returned. request @@ -2131,7 +2656,8 @@ response Certificate - optional, unbounded [tas:X509Certificate] - List of DER representation of certificates stored in the keystore. + List of DER representation of certificates stored in the + keystore. @@ -2150,11 +2676,20 @@
DeleteCertificate - 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 deletes a certificate from the device’s keystore. An ONVIF + compliant device shall support this command. An ONVIF compliant device supporting the + security service shall support this command. + 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. request @@ -2172,10 +2707,13 @@ faults - ter:Receiver - ter:Action - ter:CertificateDeletionFailed - Deleting the certificate with the requested CertificateID failed. + ter:Receiver - ter:Action - + ter:CertificateDeletionFailed + Deleting the certificate with the requested CertificateID + failed. ter:Sender - ter:InvalidArgVal - ter:CertificateID - No certificate is stored under the requested CertificateID. + No certificate is stored under the requested + CertificateID. ter:Sender - ter:InvalidArgVal - ter:ReferenceExists A reference exists for the specified certificate. @@ -2190,16 +2728,29 @@
CreateCertificationPath - 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 shall 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 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 shall 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. request CertificateIDs - [tas:CertificateIDs] - 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 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. Alias - optional [xs:string] The client-defined alias of the certification path. @@ -2214,12 +2765,16 @@ faults - env:Receiver - ter:Action - ter:MaximumNumberOfCertificationPathsReached - The maximum number of certification paths that may be assigned to the TLS server simultaneously is reached. + env:Receiver - ter:Action - + ter:MaximumNumberOfCertificationPathsReached + The maximum number of certification paths that may be assigned + to the TLS server simultaneously is reached. env:Sender - ter:InvalidArgVal - ter:CertificateID - No certificate is stored under the requested CertificateID. + No certificate is stored under the requested + CertificateID. env:Sender - ter:InvalidArgVal - ter:InvalidCertificationPath - At least one certificate in the certification path is not correctly signed with the public key in the next certificate in the path. + At least one certificate in the certification path is not + correctly signed with the public key in the next certificate in the path. env:Receiver - ter:Action - ter:CertificationPathCreationFailed Creating the certification path failed. @@ -2234,8 +2789,11 @@
GetCertificationPath - 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 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. request @@ -2248,14 +2806,16 @@ response CertificationPath - [tas:CertificationPath] - The certification path that is stored under the given ID in the keystore. + The certification path that is stored under the given ID in the + keystore. faults env:Sender - ter:InvalidArgVal - ter:CertificationPathID - No certification path is stored under the requested certification path ID. + No certification path is stored under the requested + certification path ID. @@ -2268,9 +2828,12 @@
GetAllCertificationPaths - 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 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. request @@ -2281,8 +2844,10 @@ response - CertificationPathID - optional, unbounded [tas:CertificationPathID] - List of IDs of certification paths stored in the keystore. + CertificationPathID - optional, unbounded + [tas:CertificationPathID] + List of IDs of certification paths stored in the + keystore. @@ -2310,7 +2875,10 @@ CertificationPathID - [tas:CertificationPathID] The ID of the certification path to modify. CertificateIDs - [tas:CertificateIDs] - 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 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. Alias - optional [xs:string] The client-defined alias of the certification path. @@ -2325,11 +2893,14 @@ faults env:Sender - ter:InvalidArgVal - ter:CertificationPathID - No certification path is stored under the requested certification path ID. + No certification path is stored under the requested + certification path ID. env:Sender - ter:InvalidArgVal - ter:CertificateID - No certificate is stored under the requested CertificateID. + No certificate is stored under the requested + CertificateID. env:Sender - ter:InvalidArgVal - ter:InvalidCertificationPath - At least one certificate in the certification path is not correctly signed with the public key in the next certificate in the path. + At least one certificate in the certification path is not + correctly signed with the public key in the next certificate in the path. @@ -2343,10 +2914,17 @@
DeleteCertificationPath 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 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. request @@ -2364,10 +2942,13 @@ faults - ter:Receiver - ter:Action - ter:CertificationPathDeletionFailed - Deleting the certification path with the requested certification path ID failed. + ter:Receiver - ter:Action - + ter:CertificationPathDeletionFailed + Deleting the certification path with the requested + certification path ID failed. ter:Sender - ter:InvalidArgVal - ter:CertificationPathID - No certification path is stored under the requested certification path ID. + No certification path is stored under the requested + certification path ID. ter:Sender - ter:InvalidArgVal - ter:ReferenceExists A reference exists for the object that is to be deleted. @@ -2385,10 +2966,16 @@ CRL Management
UploadCRL - 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 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. request @@ -2398,8 +2985,7 @@ Alias - optional [xs:string] The alias to assign to the uploaded CRL. anyParameters - optional, unbounded [xs:any] - - + @@ -2412,13 +2998,17 @@ faults - env:Receiver - ter:Action - ter:MaximumNumberOfCRLsReached - The device does not have enough storage space to store the CRL to be uploaded. + env:Receiver - ter:Action - + ter:MaximumNumberOfCRLsReached + The device does not have enough storage space to store the CRL + to be uploaded. env:Sender - ter:InvalidArgVal - ter:BadCRL The supplied CRL cannot be processed by the device. - env:Sender - ter:InvalidArgVal - ter:UnsupportedSignatureAlgorithm + env:Sender - ter:InvalidArgVal - + ter:UnsupportedSignatureAlgorithm - The specified signature algorithm is not supported by the device. + The specified signature algorithm is not supported by the + device. @@ -2432,8 +3022,10 @@
GetCRL - 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 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. request @@ -2468,8 +3060,10 @@
GetAllCRLs - 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 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. request @@ -2481,7 +3075,8 @@ response Crl - optional, unbounded [tas:CRL] - A list of all CRLs that are stored in the keystore on the device. + A list of all CRLs that are stored in the keystore on the + device. @@ -2500,10 +3095,14 @@
DeleteCRL - 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 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. request @@ -2540,42 +3139,61 @@ Certification Path Validation Policy Management
CreateCertPathValidationPolicy - 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. - 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 creates a certification path validation policy. An ONVIF compliant + device shall support this command. + 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. + 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. request Alias - optional [xs:string] - The alias to assign to the created certification path validation policy. + The alias to assign to the created certification path validation + policy. Parameters - [tas:CertPathValidationParameters] - The parameters of the certification path validation policy to be created. + The parameters of the certification path validation policy to be + created. TrustAnchor - unbounded [tas:TrustAnchor] - The trust anchors of the certification path validation policy to be created. + The trust anchors of the certification path validation policy to + be created. anyParameters - optional [xs:any] - - + response CertPathValidationPolicyID - [tas:CertPathValidationPolicyID] - The ID of the created certification path validation policy. + The ID of the created certification path validation + policy. faults - env:Receiver - ter:Action - ter:MaximumNumberOfCertPathValidationPoliciesReached - The device does not have enough storage to store the certification path validation policy to be created. + env:Receiver - ter:Action - + ter:MaximumNumberOfCertPathValidationPoliciesReached + The device does not have enough storage to store the + certification path validation policy to be created. env:Sender - ter:InvalidArgVal - ter:CertificateID - No certificate is stored under the requested CertificateID. - env:Sender - ter:InvalidArgVal - ter:CertPathValidationParameters - The specified certification path validation parameters are invalid. + No certificate is stored under the requested + CertificateID. + env:Sender - ter:InvalidArgVal - + ter:CertPathValidationParameters + The specified certification path validation parameters are + invalid. @@ -2588,28 +3206,35 @@
GetCertPathValidationPolicy - 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 a certification path validation policy from the keystore on + the device. An ONVIF compliant device shall support this command. + 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. request CertPathValidationPolicyID - [tas:CertPathValidationPolicyID] - The ID of the certification path validation policy to be created. + The ID of the certification path validation policy to be + created. response CertPathValidationPolicy - [tas:CertPathValidationPolicy] - The certification path validation policy that is stored under the requested ID. + The certification path validation policy that is stored under + the requested ID. faults env:Sender - ter:InvalidArgVal - ter:CertPathValidationPolicyID - No certification path validation policy is stored under the requested certification path validation policy ID. + No certification path validation policy is stored under the + requested certification path validation policy ID. @@ -2622,8 +3247,11 @@
GetAllCertPathValidationPolicies - 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 returns all certification path validation policies that are stored + in the keystore on the device. An ONVIF compliant device shall support this + command. + If no certification path validation policy is stored in the device’s keystore, an + empty list is returned. request @@ -2634,8 +3262,10 @@ response - CertPathValidationPolicy - optional, unbounded - [tas:CertPathValidationPolicy] - A list of all certification path validation policies that are stored in the keystore on the device. + CertPathValidationPolicy - optional, unbounded - + [tas:CertPathValidationPolicy] + A list of all certification path validation policies that are + stored in the keystore on the device. @@ -2656,7 +3286,8 @@ SetCertPathValidationPolicy This operation allows to modify a certification path validation policy in the keystore on the device. A device shall support this method if support for SetCertPath - is signaled via its capabilities. + is signaled via its capabilities. A device signaling support via the SetCertPathPolicy + shall support this command. request @@ -2677,7 +3308,8 @@ faults env:Sender - ter:InvalidArgVal - ter:CertPathValidationPolicyID - No certification path validation policy is stored under the requested certification path validation policy ID. + No certification path validation policy is stored under the + requested certification path validation policy ID. env:Sender - ter:InvalidArgVal - ter:CertificateID No certificate is stored under the requested CertificateID. @@ -2697,16 +3329,24 @@
DeleteCertPathValidationPolicy - 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 CertPathValidationPolicyID 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. + 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 + CertPathValidationPolicyID 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. request CertPathValidationPolicyID - [tas:CertPathValidationPolicyID] - The ID of the certification path validation policy to be deleted. + The ID of the certification path validation policy to be + deleted. @@ -2719,7 +3359,8 @@ faults env:Sender - ter:InvalidArgVal - ter:CertPathValidationPolicyID - No certification path validation policy is stored under the requested certification path validation policy ID. + No certification path validation policy is stored under the + requested certification path validation policy ID. ter:Sender - ter:InvalidArgVal - ter:ReferenceExists A reference exists for the object that is to be deleted. @@ -2739,18 +3380,36 @@ TLS Server
Elements of the TLS Server - The TLS server security feature implements a TLS server as specified in RFC 2246 and subsequent specifications. - This specification defines how to manage the associations between certification paths and the TLS server. All other TLS server configuration actions are outside the scope of this specification. In particular, enabling and disabling the TLS server on the device shall be performed using the device management service specified in the ONVIF Core Specification. + The TLS server security feature implements a TLS server as specified in RFC 2246 and + subsequent specifications. + This specification defines how to manage the associations between certification paths + and the TLS server. All other TLS server configuration actions are outside the scope of + this specification. In particular, enabling and disabling the TLS server on the device + shall be performed using the device management service specified in the ONVIF Core + Specification.
Authorization of TLS authenticated connections - If TLS client authentication is enabled, connections shall be authenticated as specified in RFC 2246, and the device shall before all validate the client TLS certificate. In case of invalid certificate the TLS connection shall be terminated and the device shall ignore any other credentials received on HTTP or WS layer. - Once a service request is authenticated on the TLS layer, the device shall decide based on its access policy whether the requestor is authorized to receive the service. In order to authorize the requestor, additional information for the device is required. - If CnMapsToUser is true, the name of the user requiring access to the device shall be presented in the Common Name (CN) attribute of the certificate presented by the client to the device. The device shall validate the provided username against its set of credentials, and grant access to the requested function in case of success. If the user is not allowed to access the function, the device shall return a 403 Forbidden. - If CnMapsToUser is false, from this point forward the authorization procedure follows what is specified in the ONVIF Core Specification as part of the security service. - The authentication and authorization process and falling back to the ONVIF Core Specification is illustrated in . + If TLS client authentication is enabled, connections shall be authenticated as + specified in RFC 2246, and the device shall before all validate the client TLS + certificate. In case of invalid certificate the TLS connection shall be terminated and the + device shall ignore any other credentials received on HTTP or WS layer. + Once a service request is authenticated on the TLS layer, the device shall decide + based on its access policy whether the requestor is authorized to receive the service. In + order to authorize the requestor, additional information for the device is + required. + If CnMapsToUser is true, the name of the user requiring access to the device shall be + presented in the Common Name (CN) attribute of the certificate presented by the client to + the device. The device shall validate the provided username against its set of + credentials, and grant access to the requested function in case of success. If the user is + not allowed to access the function, the device shall return a 403 Forbidden. + If CnMapsToUser is false, from this point forward the authorization procedure follows + what is specified in the ONVIF Core Specification as part of the security service. + The authentication and authorization process and falling back to the ONVIF Core + Specification is illustrated in .
- Authentication and authorization flow chart and fallback mechanism to the ONVIF Core Specification. + Authentication and authorization flow chart and fallback mechanism to the ONVIF + Core Specification. @@ -2762,13 +3421,36 @@ TLS Server Operations
AddServerCertificateAssignment - 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, RFC 2246. - Certification paths are identified by their certification path IDs in the keystore. The first certificate in the certification path shall 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, RFC 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 with 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 MaximumNumberOfTLSCertificationPathsReached fault and the requested certification path shall not be assigned to the TLS server. - If the certification path identified by the supplied certification path ID is already assigned to the TLS server, this command shall have no effect. + 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, RFC 2246. + Certification paths are identified by their certification path IDs in the keystore. + The first certificate in the certification path shall 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, RFC + 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 with 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 + MaximumNumberOfTLSCertificationPathsReached fault and the requested certification path + shall not be assigned to the TLS server. + If the certification path identified by the supplied certification path ID is + already assigned to the TLS server, this command shall have no effect. request @@ -2788,11 +3470,15 @@ faults env:Sender - ter:InvalidArgVal - ter:CertificationPathID - No certification path is stored in the keystore under the given certification path ID. + No certification path is stored in the keystore under the given + certification path ID. env:Sender - ter:InvalidArgVal - ter:NoPrivateKey - The key pair that is associated with the first certificate in the certificate chain does not have an associated private key. - env: Receiver - ter: Action - ter:MaximumNumberOfTLSCertificationPathsReached - The maximum number of certification paths that may be assigned to the TLS server simultaneously is reached. + The key pair that is associated with the first certificate in the + certificate chain does not have an associated private key. + env: Receiver - ter: Action - + ter:MaximumNumberOfTLSCertificationPathsReached + The maximum number of certification paths that may be assigned to + the TLS server simultaneously is reached. @@ -2805,14 +3491,19 @@
RemoveServerCertificateAssignment - 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 with the TLS server, an InvalidArgVal fault is produced. - If the TLS server on the device is enabled, the device shall produce a ReferenceExists fault and shall not remove the server certificate assignment. + 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 with the TLS server, an InvalidArgVal fault is + produced. + If the TLS server on the device is enabled, the device shall produce a + ReferenceExists fault and shall not remove the server certificate assignment. request - CertificationPathID - [tas:CertificationPathID] The ID of the certification path to remove from the TLS server. + CertificationPathID - [tas:CertificationPathID] The ID of the + certification path to remove from the TLS server. @@ -2824,8 +3515,10 @@ faults - env:Sender - ter:InvalidArgVal - ter:OldCertificationPathID - No certification path under the given certification path ID is associated with the TLS server. + env:Sender - ter:InvalidArgVal - + ter:OldCertificationPathID + No certification path under the given certification path ID is + associated with the TLS server. env:Sender - ter:InvalidArgVal - ter:ReferenceExists A reference exists for the object that is to be deleted. @@ -2840,21 +3533,45 @@
ReplaceServerCertificateAssignment - 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 with 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 shall 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, RFC 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 with the TLS server. + 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 with 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 shall 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, RFC 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 with the TLS server. request OldCertificationPathID - [tas:CertificationPathID] - The ID of the certification path to remove from the TLS server. + The ID of the certification path to remove from the TLS + server. NewCertificationPathID - [tas:CertificationPathID] - The ID of the certification path to assign to the TLS server. + The ID of the certification path to assign to the TLS + server. @@ -2867,9 +3584,11 @@ faults env:Sender - ter:InvalidArgVal - ter:OldCertificationPathID - No certification path under the given certification path ID is associated with the TLS server. + No certification path under the given certification path ID is + associated with the TLS server. env:Sender - ter:InvalidArgVal - ter:NewCertificationPathID - No certification path is stored in the keystore under the given certification path ID. + No certification path is stored in the keystore under the given + certification path ID. env:Sender - ter:InvalidArgVal - ter:NoPrivateKey The key pair that is associated with the leaf certificate in the certificate chain does not have an associated private key. @@ -2885,9 +3604,12 @@
GetAssignedServerCertificates - This operation returns the IDs of all 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 returns the IDs of all 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. request @@ -2898,7 +3620,8 @@ response - CertificationPathID - optional, unbounded [tas:CertificationPathID] + CertificationPathID - optional, unbounded + [tas:CertificationPathID] List of certification path IDs assigned to the TLS server. @@ -2918,16 +3641,23 @@
SetClientAuthenticationRequired - 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 EnablingClientAuthenticationFailed 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 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 + EnablingClientAuthenticationFailed 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. request clientAuthenticationRequired - [xs:boolean] - Define whether TLS client authentication is active on the device. + Define whether TLS client authentication is active on the + device. @@ -2939,8 +3669,10 @@ faults - env:Receiver - ter:ActionNotSupported - ter:EnablingClientAuthenticationFailed - The device does not support TLS client authentication, or TLS client authentication is not configured appropriately. + env:Receiver - ter:ActionNotSupported - + ter:EnablingClientAuthenticationFailed + The device does not support TLS client authentication, or TLS + client authentication is not configured appropriately. @@ -2965,7 +3697,8 @@ response clientAuthenticationRequired - [xs:boolean] - Report whether TLS client authentication is active on the device. + Report whether TLS client authentication is active on the + device. @@ -2984,14 +3717,17 @@
SetCnMapsToUser - This operation enables or disables mapping of the Common Name present in the TLS client certificate to an existing user name in the device. - The TLS server on the device shall perform mapping if parameter clientAuthenticationRequired is set to true. + This operation enables or disables mapping of the Common Name present in the TLS + client certificate to an existing user name in the device. + The TLS server on the device shall perform mapping if parameter + clientAuthenticationRequired is set to true. request cnMapsToUser - [xs:boolean] - A request for the device to enable or disable Common Name Mapping to User. + A request for the device to enable or disable Common Name Mapping + to User. @@ -3004,7 +3740,8 @@ faults env:Receiver - ter:ActionNotSupported - ter:CnMapsToUserFailed - The device does not support TLS client authentication, or TLS client authentication is not configured appropriately. + The device does not support TLS client authentication, or TLS + client authentication is not configured appropriately. @@ -3048,9 +3785,19 @@
AddCertPathValidationPolicyAssignment - 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 Certificaton Path Validation according to section 6 of RFC 5280 succeeds. - 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 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 Certificaton Path Validation according to section 6 of + RFC 5280 succeeds. + 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. request @@ -3072,8 +3819,10 @@ env:Sender - ter:InvalidArgVal - ter:CertPathValidationPolicyID No certification path validation policy is stored under the requested CertPathValidationPolicyID. - env:Receiver - ter:Action - ter:MaximumNumberOfTLSCertPathValidationPoliciesReached - The maximum number of certification path validation policies that may be assigned to the TLS server simultaneously is reached. + env:Receiver - ter:Action - + ter:MaximumNumberOfTLSCertPathValidationPoliciesReached + The maximum number of certification path validation policies that + may be assigned to the TLS server simultaneously is reached. @@ -3086,14 +3835,18 @@
RemoveCertPathValidationPolicyAssignment - 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 CertPathValidationPolicyID fault. + 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 CertPathValidationPolicyID fault. request CertPathValidationPolicyID - [tas:CertPathValidationPolicyID] - The ID of the certification path validation policy to remove from the TLS server. + The ID of the certification path validation policy to remove from + the TLS server. @@ -3106,7 +3859,8 @@ faults env:Sender - ter:InvalidArgVal - ter:CertPathValidationPolicyID - No certification path validation policy is stored under the requested CertPathValidationPolicyID. + No certification path validation policy is stored under the + requested CertPathValidationPolicyID. @@ -3119,17 +3873,28 @@
ReplaceCertPathValidationPolicyAssignment - 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 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. request OldCertPathValidationPolicyID - [tas:CertPathValidationPolicyID] - The ID of the certification path validation policy to remove from the TLS server. + The ID of the certification path validation policy to remove from + the TLS server. NewCertPathValidationPolicyID - [tas:CertPathValidationPolicyID] - The ID of the certification path validation policy to assign to the TLS server. + The ID of the certification path validation policy to assign to + the TLS server. RESPONSE: This message is empty. @@ -3137,10 +3902,14 @@ faults - env:Sender - ter:InvalidArgVal - ter:OldCertPathValidationPolicyID - No certification path validation policy under the given OldCertPathValidationPolicyID is associated with the TLS server. - env:Sender - ter:InvalidArgVal - ter:NewCertPathValidationPolicyID - No certification path validation policy under the given NewCertPathValidationPolicyID is stored in the device’s keystore. + env:Sender - ter:InvalidArgVal - + ter:OldCertPathValidationPolicyID + No certification path validation policy under the given + OldCertPathValidationPolicyID is associated with the TLS server. + env:Sender - ter:InvalidArgVal - + ter:NewCertPathValidationPolicyID + No certification path validation policy under the given + NewCertPathValidationPolicyID is stored in the device’s keystore. @@ -3153,7 +3922,8 @@
GetAssignedCertPathValidationPolicies - This operation returns the IDs of all certification path validation policies that are assigned to the TLS server on the device. + This operation returns the IDs of all certification path validation policies that + are assigned to the TLS server on the device. request @@ -3164,8 +3934,10 @@ response - CertPathValidationPolicyID - optional, unbounded [tas:CertPathValidationPolicyID] - List of certification path validation policy IDs assigned to the TLS server. + CertPathValidationPolicyID - optional, unbounded + [tas:CertPathValidationPolicyID] + List of certification path validation policy IDs assigned to the + TLS server. @@ -3184,12 +3956,27 @@
SetEnabledTLSVersions - This operation sets the version(s) of TLS which the device shall use. Valid values are taken from the TLSServerSupported capability. - A client initiates a TLS session by sending a ClientHello with the highest TLS version it supports. This suggests to the server that the client can accept any TLS version up to and including that version. - The server then chooses the TLS version to use. This is generally the highest TLS version the server supports that is within the range of the client. For example, if a ClientHello indicates TLS version 1.1, the server can proceed with TLS 1.0 or TLS 1.1. - In the event that an ONVIF installation wishes to disable certain version(s) of TLS, it may do so with this operation. For example, to disable TLS 1.0 on a device signaling support for TLS versions 1.0, 1.1, and 1.2, the enabled version list may be set to "1.1 1.2", omitting 1.0. If a client then attempts to connect with a ClientHello containing TLS 1.0, the server shall send a "protocol_version" alert message and close the connection. This handshake indicates to the client that TLS 1.0 is not supported by the server. The client must try again with a higher TLS version suggestion. - An empty version list is not permitted. Disabling all versions of TLS is not the intent of this operation. See AddServerCertificateAssignment and RemoveServerCertificateAssignment. - A device signalling support for TLS version enabling with the EnabledVersionsSupported capability shall support this command. + This operation sets the version(s) of TLS which the device shall use. Valid values + are taken from the TLSServerSupported capability. + A client initiates a TLS session by sending a ClientHello with the highest TLS + version it supports. This suggests to the server that the client can accept any TLS + version up to and including that version. + The server then chooses the TLS version to use. This is generally the highest TLS + version the server supports that is within the range of the client. For example, if a + ClientHello indicates TLS version 1.1, the server can proceed with TLS 1.0 or TLS + 1.1. + In the event that an ONVIF installation wishes to disable certain version(s) of TLS, + it may do so with this operation. For example, to disable TLS 1.0 on a device signaling + support for TLS versions 1.0, 1.1, and 1.2, the enabled version list may be set to "1.1 + 1.2", omitting 1.0. If a client then attempts to connect with a ClientHello containing + TLS 1.0, the server shall send a "protocol_version" alert message and close the + connection. This handshake indicates to the client that TLS 1.0 is not supported by the + server. The client must try again with a higher TLS version suggestion. + An empty version list is not permitted. Disabling all versions of TLS is not the + intent of this operation. See AddServerCertificateAssignment and + RemoveServerCertificateAssignment. + A device signalling support for TLS version enabling with the + EnabledVersionsSupported capability shall support this command. request @@ -3223,7 +4010,9 @@
GetEnabledTLSVersions - This operation retrieves the version(s) of TLS which are currently enabled on the device. A device signalling support for TLS version enabling with the EnabledVersionsSupported capability shall support this command. + This operation retrieves the version(s) of TLS which are currently enabled on the + device. A device signalling support for TLS version enabling with the + EnabledVersionsSupported capability shall support this command. request @@ -3288,8 +4077,10 @@ faults - env:Receiver - ter:Action - ter:MaximumNumberOfDot1XConfigurationsReached - The device already has the number of configurations specified by MaximumNumberOfDot1XConfigurations. + env:Receiver - ter:Action - + ter:MaximumNumberOfDot1XConfigurationsReached + The device already has the number of configurations specified by + MaximumNumberOfDot1XConfigurations. env:Sender - ter:InvalidArgVal - ter:PassphraseID A supplied passphrase ID cannot be processed by the device. env:Sender - ter:InvalidArgVal - ter:CertificationPathID @@ -3297,9 +4088,11 @@ env:Sender - ter:InvalidArgVal - ter:CertPathValidationPolicyID No certification path validation policy is stored under the requested certification path validation policy ID. env:Sender - ter:InvalidArgVal - ter:Dot1XMethod - A supplied IEEE 802.1X authentication method cannot be processed by the device. + A supplied IEEE 802.1X authentication method cannot be processed by + the device. env:Sender - ter:InvalidArgVal - ter:Dot1XMethodCombination - The combination of IEEE 802.1X authentication methods cannot be processed by the device. + The combination of IEEE 802.1X authentication methods cannot be + processed by the device. @@ -3312,9 +4105,13 @@
GetAllDot1XConfigurations - This operation returns details of all IEEE 802.1X configurations that are on the device. This operation may be used, e.g., if a client lost track of which IEEE 802.1X configurations are present on the device. - If no IEEE 802.1X configurations exist on the device, an empty list is returned. - A device signalling support for IEEE 802.1X configuration with the MaximumNumberOfDot1XConfigurations capability shall support this command. + This operation returns details of all IEEE 802.1X configurations that are on the + device. This operation may be used, e.g., if a client lost track of which IEEE 802.1X + configurations are present on the device. + If no IEEE 802.1X configurations exist on the device, an empty list is + returned. + A device signalling support for IEEE 802.1X configuration with the + MaximumNumberOfDot1XConfigurations capability shall support this command. request @@ -3345,9 +4142,12 @@
GetDot1XConfiguration - This operation returns details of a specific IEEE 802.1X configuration on the device. - If the device cannot process the provided IEEE 802.1X configuration ID, the device shall produce a Dot1XConfigurationID fault. - A device signalling support for IEEE 802.1X configuration with the MaximumNumberOfDot1XConfigurations capability shall support this command. + This operation returns details of a specific IEEE 802.1X configuration on the + device. + If the device cannot process the provided IEEE 802.1X configuration ID, the device + shall produce a Dot1XConfigurationID fault. + A device signalling support for IEEE 802.1X configuration with the + MaximumNumberOfDot1XConfigurations capability shall support this command. request @@ -3367,7 +4167,8 @@ faults env:Sender - ter:InvalidArgVal - ter:Dot1XConfigurationID - The supplied IEEE 802.1X configuration ID cannot be processed by the device. + The supplied IEEE 802.1X configuration ID cannot be processed by the + device. @@ -3381,16 +4182,21 @@
DeleteDot1XConfiguration This operation deletes an IEEE 802.1X configuration from the device. - If the device cannot process the provided IEEE 802.1X configuration ID, the device shall produce a Dot1XConfigurationID fault. - If a reference exists for the specified IEEE 802.1X configuration, the device shall produce a ReferenceExists fault and shall not delete the configuration. - After an IEEE 802.1X configuration has been successfully deleted, the device may assign its former ID to a new configuration. - A device signalling support for IEEE 802.1X configuration with the MaximumNumberOfDot1XConfigurations capability shall support this command. + If the device cannot process the provided IEEE 802.1X configuration ID, the device + shall produce a Dot1XConfigurationID fault. + If a reference exists for the specified IEEE 802.1X configuration, the device shall + produce a ReferenceExists fault and shall not delete the configuration. + After an IEEE 802.1X configuration has been successfully deleted, the device may + assign its former ID to a new configuration. + A device signalling support for IEEE 802.1X configuration with the + MaximumNumberOfDot1XConfigurations capability shall support this command. request Dot1XID - [tas:Dot1XID] - The unique identifier of the 802.1X configuration to be deleted. + The unique identifier of the 802.1X configuration to be + deleted. @@ -3403,9 +4209,11 @@ faults env:Sender - ter:InvalidArgVal - ter:Dot1XConfigurationID - The supplied IEEE 802.1X configuration ID cannot be processed by the device. + The supplied IEEE 802.1X configuration ID cannot be processed by the + device. env:Sender - ter:InvalidArgVal - ter:ReferenceExists - A network interface reference exists for the specified IEEE 802.1X configuration. + A network interface reference exists for the specified IEEE 802.1X + configuration. @@ -3418,18 +4226,35 @@
SetNetworkInterfaceDot1XConfiguration - This operation binds an IEEE 802.1X configuration to a network interface on the device. This operation shall either create a new binding or replace an existing binding. On failure when an existing binding already exists, the existing binding shall remain. - The Device Management SetNetworkInterface operation provides a method of binding an IEEE 802.1X configuration to an IEEE 802.11 (wireless) interface, and that operation may still be used. But there is no ability for SetNetworkInterface to bind an IEEE 802.1X configuration to a hardwired interface. This operation is provided to bind an IEEE 802.1X configuration to either type of interface. - If SetNetworkInterfaceDot1XConfiguration is used to bind an IEEE 802.1X configuration to an IEEE 802.11 (wireless) interface, then the DeviceManagement GetNetworkInterfaces operation shall return the IEEE 802.1X configuration ID along with the rest of that interface’s configuration information. - If the device cannot process the provided network interface token, the device shall produce an InvalidNetworkInterface fault. - If the device cannot process the provided IEEE 802.1X configuration ID, the device shall produce a Dot1XConfigurationID fault. - A device signalling support for IEEE 802.1X configuration with the MaximumNumberOfDot1XConfigurations capability shall support this command. + This operation binds an IEEE 802.1X configuration to a network interface on the + device. This operation shall either create a new binding or replace an existing binding. + On failure when an existing binding already exists, the existing binding shall + remain. + The Device Management SetNetworkInterface operation provides a method of binding an + IEEE 802.1X configuration to an IEEE 802.11 (wireless) interface, and that operation may + still be used. But there is no ability for SetNetworkInterface to bind an IEEE 802.1X + configuration to a hardwired interface. This operation is provided to bind an IEEE 802.1X + configuration to either type of interface. + If SetNetworkInterfaceDot1XConfiguration is used to bind an IEEE 802.1X configuration + to an IEEE 802.11 (wireless) interface, then the DeviceManagement GetNetworkInterfaces + operation shall return the IEEE 802.1X configuration ID along with the rest of that + interface’s configuration information. + If the device cannot process the provided network interface token, the device shall + produce an InvalidNetworkInterface fault. + If the device cannot process the provided IEEE 802.1X configuration ID, the device + shall produce a Dot1XConfigurationID fault. + A device signalling support for IEEE 802.1X configuration with the + MaximumNumberOfDot1XConfigurations capability shall support this command. request token - [xs:string] - 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 common.xsd for this single type, the base type is used here.) + 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 common.xsd for this single type, the base type is used + here.) Dot1XID - [tas:Dot1XID] The unique identifier of the 802.1X configuration to be set. @@ -3438,7 +4263,8 @@ response RebootNeeded - [xs:boolean] - Indicates whether or not a reboot is required after configuration updates. + Indicates whether or not a reboot is required after configuration + updates. @@ -3447,7 +4273,8 @@ env:Sender - ter:InvalidArgVal - ter:InvalidNetworkInterface The supplied network interface token does not exist. env:Sender - ter:InvalidArgVal - ter:Dot1XConfigurationID - The supplied IEEE 802.1X configuration ID cannot be processed by the device. + The supplied IEEE 802.1X configuration ID cannot be processed by the + device. @@ -3460,23 +4287,35 @@
GetNetworkInterfaceDot1XConfiguration - This operation returns the IEEE 802.1X ID and configuration associated with a network interface on the device. If there is no IEEE 802.1X configuration associated with the specified network interface, then the response shall be empty. - If the Device Management SetNetworkInterface operation was used to bind an IEEE 802.1X configuration to an IEEE 802.11 (wireless) interface, then this operation shall return the IEEE 802.1X configuration information as if the SetNetworkInterfaceDot1XConfiguration operation had been used. - If the device cannot process the provided network interface token, the device shall produce an InvalidNetworkInterface fault. - A device signalling support for IEEE 802.1X configuration with the MaximumNumberOfDot1XConfigurations capability shall support this command. + This operation returns the IEEE 802.1X ID and configuration associated with a network + interface on the device. If there is no IEEE 802.1X configuration associated with the + specified network interface, then the response shall be empty. + If the Device Management SetNetworkInterface operation was used to bind an IEEE 802.1X + configuration to an IEEE 802.11 (wireless) interface, then this operation shall return the + IEEE 802.1X configuration information as if the SetNetworkInterfaceDot1XConfiguration + operation had been used. + If the device cannot process the provided network interface token, the device shall + produce an InvalidNetworkInterface fault. + A device signalling support for IEEE 802.1X configuration with the + MaximumNumberOfDot1XConfigurations capability shall support this command. request token - [xs:string] - 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 common.xsd for this single type, the base type is used here.) + 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 common.xsd for this single type, the base type is used + here.) response Dot1XID - optional [tas:Dot1XID] - The unique identifier of 802.1X configuration assigned to the Network Interface. + The unique identifier of 802.1X configuration assigned to the + Network Interface. @@ -3496,24 +4335,41 @@
DeleteNetworkInterfaceDot1XConfiguration - This operation unbinds the IEEE 802.1X configuration associated with a network interface on the device. If there is no IEEE 802.1X configuration associated with the specified network interface, then the operation does nothing. - The Device Management SetNetworkInterface operation provides a method of unbinding an IEEE 802.1X configuration from an IEEE 802.11 (wireless) interface by omitting the configuration ID, and that operation may still be used. But there is no ability for SetNetworkInterface to unbind an IEEE 802.1X configuration from a hardwired interface. This operation is provided to unbind an IEEE 802.1X configuration from either type of interface. - If the Device Management SetNetworkInterface operation was used to bind an IEEE 802.1X configuration to an IEEE 802.11 (wireless) interface, then this operation shall unbind the IEEE 802.1X configuration information as if the SetNetworkInterfaceDot1XConfiguration operation had been used. - If the device cannot process the provided network interface token, the device shall produce an InvalidNetworkInterface fault. - A device signalling support for IEEE 802.1X configuration with the MaximumNumberOfDot1XConfigurations capability shall support this command. + This operation unbinds the IEEE 802.1X configuration associated with a network + interface on the device. If there is no IEEE 802.1X configuration associated with the + specified network interface, then the operation does nothing. + The Device Management SetNetworkInterface operation provides a method of unbinding an + IEEE 802.1X configuration from an IEEE 802.11 (wireless) interface by omitting the + configuration ID, and that operation may still be used. But there is no ability for + SetNetworkInterface to unbind an IEEE 802.1X configuration from a hardwired interface. + This operation is provided to unbind an IEEE 802.1X configuration from either type of + interface. + If the Device Management SetNetworkInterface operation was used to bind an IEEE 802.1X + configuration to an IEEE 802.11 (wireless) interface, then this operation shall unbind the + IEEE 802.1X configuration information as if the SetNetworkInterfaceDot1XConfiguration + operation had been used. + If the device cannot process the provided network interface token, the device shall + produce an InvalidNetworkInterface fault. + A device signalling support for IEEE 802.1X configuration with the + MaximumNumberOfDot1XConfigurations capability shall support this command. request token - [xs:string] - 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 common.xsd for this single type, the base type is used here.) + 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 common.xsd for this single type, the base type is used + here.) response RebootNeeded - [xs:boolean] - Indicates whether or not a reboot is required after configuration updates. + Indicates whether or not a reboot is required after configuration + updates. @@ -3537,11 +4393,11 @@
Overview Signing of media that is generated by the device is described in the [Media Signing - Specification]. Media is signed using a private - key that is provisioned during factory production that is stored in a specially protected - hardware component (e.g., a trusted platform module). This private key is associated with - a certificate that holds the public key. In addition to the factory provisioned key one - additional private key can be used to sign media. + Specification]. Media is signed using a private key that is provisioned during factory + production that is stored in a specially protected hardware component (e.g., a trusted + platform module). This private key is associated with a certificate that holds the public + key. In addition to the factory provisioned key one additional private key can be used to + sign media.
AddMediaSigningCertificateAssignment @@ -3635,7 +4491,8 @@ signing on the device. This operation will always return the factory provisioned certification path and can additionally return a certification path that has been added by AddMediaSigningCertificateAssignment. - A device shall support this command if the MediaSigningSupported capability is true. + A device shall support this command if the MediaSigningSupported capability is + true. request @@ -3669,7 +4526,9 @@
Autorization Server Configuration - This chapter describes configuration of external authorization servers. For an overview of this see . + This chapter describes configuration of external authorization servers. For an overview + of this see .
GetAuthorizationServerConfigurations This operation retrieves an existing authorization server configuration, or all @@ -3686,7 +4545,8 @@ response - Configuration - optional, unbounded [tas:AuthorizationServerConfiguration] + Configuration - optional, unbounded + [tas:AuthorizationServerConfiguration] List of authorization server configurations. @@ -3731,7 +4591,8 @@ faults env:Receiver - ter:Action - ter:MaxAuthorizationServers - The maximum number of configurations supported by the device has been reached. + The maximum number of configurations supported by the device has + been reached. env:Sender - ter:InvalidArgVal - ter:InvalidConfig The configuration parameters are not possible to set. @@ -3819,11 +4680,13 @@
JWT-based authentication - The following functions are defined to control the set of accepted aud claims. See also . + The following functions are defined to control the set of accepted + aud claims. See also .
GetJWTConfiguration This operation returns the parameters of the JWT authorization used by the device. A - device shall support this command if the capability JsonWebToken in the device service capabilities is set. + device shall support this command if the capability JsonWebToken in the device service + capabilities is set. request @@ -3856,8 +4719,10 @@
SetJWTConfiguration This operation sets the parameters of the JWT authorization used by the device. A - device shall support this command if the capability JsonWebToken in the device service capabilities is set. - JWT client authorization of the device is enabled when at least one key or trusted issuer URI is provided. + device shall support this command if the capability JsonWebToken in the device service + capabilities is set. + JWT client authorization of the device is enabled when at least one key or trusted + issuer URI is provided. request @@ -3883,7 +4748,8 @@ ter:Sender - ter:InvalidArgVal - ter:MaxIssuersExceeded Too many trusted issuers provided. env:Sender - ter:InvalidArgVal - ter:CertPathValidationPolicyID - No certification path validation policy is stored under the requested certification path validation policy ID. + No certification path validation policy is stored under the + requested certification path validation policy ID. @@ -3893,14 +4759,18 @@ - A device shall support assignment of as many keys as its key store can hold. A device shall support at least two trusted issuers. + A device shall support assignment of as many keys as its key store can hold. A device + shall support at least two trusted issuers.
Capabilities
GetServiceCapabilities - The capabilities reflect optional functions and functionality of the different features in the security configuration service. The service capabilities consist of keystore capabilities and TLS server capabilities. The information is static and does not change during device operation. + The capabilities reflect optional functions and functionality of the different + features in the security configuration service. The service capabilities consist of + keystore capabilities and TLS server capabilities. The information is static and does not + change during device operation. A device shall support this command. @@ -3932,142 +4802,91 @@
Keystore Capabilities - The keystore capabilities reflect optional functions and functionality of the keystore on a device. The following capabilities are available: + The keystore capabilities reflect optional functions and functionality of the keystore + on a device. The following capabilities are available: Keystore Capabilities - - - - - - - Capability Name - - - - - Capability Semantics - - - - - - - - MaximumNumberOfPassphrases - - - Indicates the maximum number of passphrases that the device is able to store simultaneously. - - - - - MaximumNumberOfKeys - - - Indicates the maximum number of keys that the device is able store simultaneously. - - - - - MaximumNumberOfCertificates - - - Indicates the maximum number of certificates that the device is able to store simultaneously. - - - - - MaximumNumberOfCertificationPaths - - - Indicates the maximum number of certificate paths that the device is able to store simultaneously. - - - - SetCertPath - Indicates support for modifying an existing certification path or - certification path validation policy. - - - - RSAKeyPairGeneration - - - Indicates support for on-board RSA key pair generation. - - + + + - ECCKeyPairGeneration + + Capability Name + - Indicates support for on-board ECC key pair generation. + + Capability Semantics + + + - KeyPairGeneration + MaximumNumberOfPassphrases - Indicates support for on-board key pair generation. + Indicates the maximum number of passphrases that the device is able to store + simultaneously. - RSAKeyLengths + MaximumNumberOfKeys - Indicates which RSA key lengths are supported by the device. + Indicates the maximum number of keys that the device is able store + simultaneously. - EllipticCurves + MaximumNumberOfCertificates - Indicates which elliptic curves are supported by the device. + Indicates the maximum number of certificates that the device is able to + store simultaneously. - PKCS8RSAKeyPairUpload + MaximumNumberOfCertificationPaths - Indicates support for uploading an RSA key pair in a PKCS#8 data structure. + Indicates the maximum number of certificate paths that the device is able to + store simultaneously. - - PKCS8 - - - Indicates support for uploading supported key pair in a PKCS#8 data structure. - + SetCertPath + Indicates support for modifying an existing certification path or + certification path validation policy. - PKCS12CertificateWithRSAPrivateKeyUpload + KeyPairGeneration - Indicates support for uploading a certificate along with an RSA private key in a PKCS#12 data structure. + List of supported allgorithm for on-board key pair generation. - PKCS12 + RSAKeyLengths - Indicates support for uploading a certificate along with a private key in a PKCS#12 data structure. + Indicates which RSA key lengths are supported by the device. - PKCS10ExternalCertificationWithRSA + EllipticCurves - Indicates support for creating PKCS#10 requests for RSA keys and uploading the certificate obtained from a CA. + Indicates which elliptic curves are supported by the device. @@ -4075,15 +4894,17 @@ PKCS10 - Indicates support for creating PKCS#10 requests for asymetric key pair and uploading the certificate obtained from a CA. + Indicates support for creating PKCS#10 requests for asymetric key pair and + uploading the certificate obtained from a CA. - SelfSignedCertificateCreationWithRSA + PKCS12 - Indicates support for creating self-signed certificates for RSA keys. + Indicates support for uploading a certificate along with a private key in a + PKCS#12 data structure. @@ -4107,15 +4928,16 @@ PasswordBasedEncryptionAlgorithms - Indicates which password-based encryption algorithms are supported by the device. + Indicates which password-based encryption algorithms are supported by the + device. - PasswordBasedMACAlgorithms + SymmetricEncryptionAlgorithms - Indicates which password-based MAC algorithms are supported by the device. + List of symmetric encryption alogrithm supported by the device (AES128-GCM-SHA256, AEAD_AES256_GCM_SHA_384, ...). @@ -4123,7 +4945,12 @@ X.509Versions - Indicates which X.509 versions are supported by the device.If a device supports X.509v3 certificates, this fact shall also be signalled by this capability. X.509 versions shall be encoded as version numbers, e.g., 1, 2, 3. + Indicates which X.509 versions are supported by the device. + If a device supports X.509v3 certificates, this fact shall also be + signalled by this capability. + X.509 versions shall be encoded as version numbers, e.g., 1, 2, + 3. @@ -4131,7 +4958,8 @@ MaximumNumberOfCRLs - Indicates the maximum number of CRLs that the device is able to store simultaneously. + Indicates the maximum number of CRLs that the device is able to store + simultaneously. @@ -4139,7 +4967,8 @@ MaximumNumberOfCertificationPathValidationPolicies - Indicates the maximum number of certification path validation policies 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. @@ -4147,7 +4976,8 @@ EnforceTLSWebClientAuthExtKeyUsage - Indicates whether a device supports checking for the TLS WWW client auth extended key usage extension while validating certification paths. + Indicates whether a device supports checking for the TLS WWW client auth + extended key usage extension while validating certification paths. @@ -4155,13 +4985,18 @@ NoPrivateKeySharing - Indicates the device requires that each certificate with private key has its own unique key. + Indicates the device requires that each certificate with private key has its + own unique key. - SetCertPath - The device supports modification of certificate path and certificate - validation path. + + SetCertPath + + + The device supports modification of certificate path and certificate + validation path. + @@ -4169,7 +5004,9 @@
TLS Server Capabilities - The TLS server capabilities reflect optional functions and functionality of the TLS server. The information is static and does not change during device operation. The following capabilities are available: + The TLS server capabilities reflect optional functions and functionality of the TLS + server. The information is static and does not change during device operation. The + following capabilities are available:
TLS Server Capabilities @@ -4181,7 +5018,8 @@ TLSServerSupported - Indicates which TLS server versions are supported by the device. Server versions shall be encoded as version numbers, e.g., “1.0 1.1 1.2”. + Indicates which TLS server versions are supported by the device. Server + versions shall be encoded as version numbers, e.g., “1.0 1.1 1.2”. @@ -4189,7 +5027,8 @@ MaximumNumberOfTLSCertificationPaths - Indicates the maximum number of certification paths that may be assigned to the TLS server simultaneously. + Indicates the maximum number of certification paths that may be assigned to + the TLS server simultaneously. @@ -4197,7 +5036,8 @@ TLSClientAuthSupported - Indicates whether the device supports TLS client authentication as defined in this specification. + Indicates whether the device supports TLS client authentication as defined + in this specification. @@ -4205,7 +5045,8 @@ CnMapsToUserSupported - Indicates whether the device supports TLS client authorization using common name to local user mapping as defined in this specification + Indicates whether the device supports TLS client authorization using common + name to local user mapping as defined in this specification @@ -4213,7 +5054,8 @@ MaximumNumberOfTLSCertificationPathValidationPolicies - Indicates the maximum number of certification path validation policies that may be assigned to the TLS server simultaneously + Indicates the maximum number of certification path validation policies that + may be assigned to the TLS server simultaneously @@ -4221,7 +5063,8 @@ EnabledVersionsSupported - Indicates whether the device supports enabling and disabling specific TLS versions. + Indicates whether the device supports enabling and disabling specific TLS + versions. @@ -4230,7 +5073,9 @@
IEEE 802.1X Capabilities - The IEEE 802.1X configuration capabilities reflect optional functions and functionality of IEEE 802.1X configuration on a device. The following additional capabilites are defined: + The IEEE 802.1X configuration capabilities reflect optional functions and + functionality of IEEE 802.1X configuration on a device. The following additional + capabilites are defined:
Additional IEEE 802.1X Configuration Capabilities @@ -4252,7 +5097,8 @@ MaximumNumberOfDot1XConfigurations - Indicates the maximum number of IEEE 802.1X configurations that the device is able to configure simultaneously. + Indicates the maximum number of IEEE 802.1X configurations that the device + is able to configure simultaneously. @@ -4260,7 +5106,8 @@ Dot1XMethods - A list of authentication method outer/inner (phase1/phase2) combinations supported by the device. + A list of authentication method outer/inner (phase1/phase2) combinations + supported by the device. @@ -4335,8 +5182,8 @@ MaxConfigurations - Indicates the maximum number of authorization server configurations that - the device is able to configure simultaneously. + Indicates the maximum number of authorization server configurations that the + device is able to configure simultaneously. @@ -4345,13 +5192,15 @@ A list of authorization server configuration types that is supported by the - device, see for possible values. + device, see for possible values. ClientAuthenticationMethodsSupported - A list of authentication methods that is supported by the device, see for possible values. - + A list of authentication methods that is supported by the device, see for + possible values. @@ -4360,7 +5209,9 @@
Capability-implied Requirements - summarizes for each capability the minimum requirements that a device signaling this capability shall satisfy; it should not be seen as a recommendation. + summarizes for each capability the minimum requirements + that a device signaling this capability shall satisfy; it should not be seen as a + recommendation.
Requirements implied by Capabilities @@ -4394,34 +5245,21 @@ DeletePassphrase - If greater than zero, the device shall support passphrases that consist of characters from the ASCII character set and that have a length of up to 40 characters. + If greater than zero, the device shall support passphrases that consist of + characters from the ASCII character set and that have a length of up to 40 + characters. - - MaximumNumberOfKeys - - - If greater than zero, then the following commands shall be supported: - - - GetKeyStatus - - - GetAllKeys - - - DeleteKey - - - + MaximumNumberOfKeys + Shall be at least four MaximumNumberOfCertificates - If greater than zero, then MaximumNumberOfKeys>0 shall hold. + Shall be at lest four @@ -4429,64 +5267,53 @@ MaximumNumberOfCertificationPaths - If greater than zero, MaximumNumberOfCertificates>=2 shall hold. + Shall be at least two + + MaximumNumberOfCertificationPathValidationPolicies + Shall be at least two + - RSAKeyPairGeneration + KeyPairGeneration - If true, the following commands shall be supported: + If it contains RSA, then the list of supported RSA key length shall not be + empty and the device shall support the command: CreateRSAKeyPair - If true, the list of supported RSA key lengths as indicated by the RSAKeyLengths capability shall not be empty. - If true, MaximumNumberOfKeys>0 shall hold. - - - - - ECCKeyPairGeneration - - - If true, the following commands shall be supported: + If it contains ECC, then the list of supported elliptic curves indicated by + the EllipticCurves capability shall not be empty and the device shall support + the commands: CreateECCKeyPair - If true, the list of supported elliptic curves indicated by the EllipticCurves capability shall not be empty. If true, MaximumNumberOfKeys>0 shall hold. - PKCS8 + PKCS10 - If true, the following commands shall be supported: + If true, the following operations shall be supported: - UploadKeyPairInPKCS8 + Creating a CSR with the CreatePKCS10CSR command. + + + Uploading the certificate created for the CSR as well as the certificate + of the created certificate’s signer with the UploadCertificate + command. - If true, MaximumNumberOfKeys > 0 shall hold. - If true, the list of supported password-based encryption algorithms as - indicated by the PasswordBasedEncryptionAlgorithms capability shall contain at - least the algorithm pbeWithSHAAnd3-KeyTripleDES-CBC. - If true, at least one capability between EllipticCurves and RSAKeyLengths shall be specified. - - - - - PKCS8RSAKeyPairUpload - - - If true, the conditions of PKCS8 shall be supported: - If true, the list of supported RSA key lengths as indicated by the RSAKeyLengths capability shall not be empty. + If true, the capability KeyPairGeneration shall not be empty. @@ -4499,15 +5326,6 @@ UploadCertificateWithPrivateKeyInPKCS12 - - GetCertificate - - - GetAllCertificates - - - DeleteCertificate - GetCertificationPath @@ -4518,71 +5336,14 @@ DeleteCertificationPath - If true, MaximumNumberOfKeys >=2 shall hold. - If true, MaximumNumberOfCertificates >=2 shall hold. - If true, MaximumNumberOfCertificattionPaths >0 shall hold. - If true, the list of supported password-based encryption algorithms as indicated by the PasswordBasedEncryptionAlgorithms capability shall contain at least the algorithm pbeWithSHAAnd3-KeyTripleDES-CBC. - If true, the list of supported password-based MAC algorithms as indicated by the PasswordBasedMACAlgorithms capability shall contain at least the algorithm hmacWithSHA256. - If true, the list of supported X.509 versions as indicated by the X.509Versions capability shall contain at least the value 3. - - - - - PKCS12CertificateWithRSAPrivateKeyUpload - - - If true, the conditions of capability PKCS12 shall be fulfilled. - If true, the list of supported RSA key lengths as indicated by the RSAKeyLengths capability shall not be empty. - - - - - PKCS10 - - - If true, the following operations shall be supported: - - - Creating a CSR with the CreatePKCS10CSR command. - - - GetCertificate - - - GetAllCertificates - - - DeleteCertificate - - - Uploading the certificate created for the CSR as well as the certificate of the created certificate’s signer with the UploadCertificate command. - - - If true, MaximumNumberOfCertificates>=2 and MaximumNumberOfCertificationPaths>0 shall hold. - If true, MaximumNumberOfKeys>=2 shall hold. - If true and the capability RSAKeyLengths is not empty the following condition shall be fulfilled: - - - The capability RSAKeyPairGeneration shall be specified . - - - If true and the capability EllipticCurves is provided, the following conditions shall be fulfilled: - - - The capability ECCKeyPairGeneration shall be specified. - - - The list of supported signature algorithms as indicated by the SignatureAlgorithms capability shall contain at least the algorithms ECDSA-With-SHA1 and ECDSA-With-SHA256. - - - - - - - PKCS10ExternalCertificationWithRSA - - If true, the conditions of capability PKCS10 shall be fulfilled. - If true, the list of supported RSA key lengths as indicated by the RSAKeyLengths capability shall not be empty. + If true, the list of supported password-based encryption algorithms as + indicated by the PasswordBasedEncryptionAlgorithms capability shall include the + baseline specified in the ONVIF Security Baseline. + If true, the list of supported password-based MAC algorithms as indicated by + the PasswordBasedMACAlgorithms capability shall include the baseline specified + in table Key Derivation Functions of the ONVIF Security Baseline. + If true, the list of supported X.509 versions as indicated by the + X.509Versions capability shall contain at least the value 3. @@ -4595,55 +5356,23 @@ CreateSelfSignedCertificate - - GetCertificate - - - GetAllCertificates - - - DeleteCertificate - - If true, MaximumNumberOfCertificates> 0 shall hold. If true, the following operations shall be supported: - Key pair generation as signaled by the RSAKeyPairGeneration or ECCKeyPairGeneration capability or key pair upload as signaled by the PKCS8 capability or key pair upload as signaled by the PKCS12CertificateWithRSAPrivateKeyUpload capability - - - If true and the capability RSAKeyLengths is not empty the following conditions shall be fulfilled: - - - The capability RSAKeyPairGeneration shall be specified . - - - The list of supported signature algorithms as indicated by the SignatureAlgorithms capability shall contain at least the algorithms sha1-WithRSAEncryption and sha256WithRSAEncryption. - - - If true and the capability EllipticCurves is provided, the following condition shall be fulfilled: - - - The capability ECCKeyPairGeneration shall be specified. + Key pair generation as signaled by the KeyPairGeneration or key pair + upload as signaled by PKCS12 capability. - - - SelfSignedCertificateCreationWithRSA - - - If true, the conditions of the SelfSignedCertificateCreation capability shall be supported. - If true, the list of supported RSA key lengths as indicated by the RSAKeyLengths capability shall not be empty. - - TLSServerSupported - If not empty, PKCS10ExternalCertificationWithRSA or SelfSignedCertificateCreationWithRSA or PKCS10 or SelfSignedCertificateCreation shall be true. + If not empty, PKCS10, PKCS12 or SelfSignedCertificateCreation shall be + true. If not empty, the following commands shall be supported: @@ -4671,31 +5400,7 @@ GetAssignedServerCertificates - If not empty, MaximumNumberOfCertificationPaths>=2 and MaximumNumberOfTLSCertificationPaths>0 shall hold. - - - - - TLSServerSupported and PKCS10ExternalCertificationWithRSA - - - If TLSServerSupported is non-empty and PKCS10ExternalCertificationWithRSA is true, MaximumNumberOfCertificates>=3 shall hold. - - - - - TLSServerSupported and PKCS10 - - - If TLSServerSupported is non-empty and PKCS10 is true, MaximumNumberOfCertificates>=3 shall hold. - - - - - MaximumNumberOfTLSCertificationPaths - - - If greater than zero, MaximumNumberOfCertificationPaths>0 shall hold. + If not empty, MaximumNumberOfTLSCertificationPaths>0 shall hold. @@ -4720,8 +5425,13 @@ - If X.509v3 is supported, the device shall support the distinguished name attribute types - country, organization, organizational unit, distinguished name qualifier, state or province name, common name, and serial number. + If X.509v3 is supported, the device shall support the distinguished name + attribute types + country, organization, + organizational unit, distinguished name + qualifier, state or province name, + common name, and serial + number. @@ -4744,29 +5454,15 @@ DeleteCRL - - - - - MaximumNumberOfCertificationPathValidationPolicies - - - If greater than zero, then the following command shall be supported + If greater than zero, then processing X.509 CRLs that are compliant to the + CRL profile defined in RFC 5280, Sect. 5 and that - CreateCertPathValidationPolicy - - - GetCertPathValidationPolicy - - - GetAllCertPathValidationPolicies - - - DeleteCertPathValidationPolicy + are complete direct CRLs as defined in RFC 5280 that are signed with the + same signature key as the signature key that the CA uses to sign issued + certificates - If greater than zero, PKCS12CertificateWithRSAPrivateKeyUpload, PKCS10ExternalCertificationWithRSA or SelfSignedCertificateCreationWithRSA or PKCS12 or PKCS10 or SelfSignedCertificateCreation shall be true. @@ -4796,34 +5492,17 @@ If true, TLSServerSupported shall not be empty. - If true, MaximumNumberOfCertificationPathValidationPolicies>=2 and MaximumNumberOfTLSCertificationPathValidationPolicies>0 shall hold. + If true, MaximumNumberOfTLSCertificationPathValidationPolicies>0 shall + hold. If true, the device shall support - validating certification paths containing X.509v3 certificates that are signed with signatures of type sha1-WithRSAEncryption or sha256WithRSAEncrpytion - - - processing X.509 CRLs that are compliant to the CRL profile defined in RFC 5280, Sect. 5 and that - - - are signed with signatures of type sha1-WithRSAEncryption or, sha256WithRSAEncryption and - - - are complete direct CRLs as defined in RFC 5280 that are signed with the same signature key as the signature key that the CA uses to sign issued certificates - - + validating certification paths containing X.509v3 certificates that are + signed with signature algorithm listed in the security baseline. - - - MaximumNumberOfTLSCertificationPathValidationPolicies - - - If greater than zero, MaximumNumberOfCertificationPathValidationPolicies >0 shall hold. - - MaximumNumberOfDot1XConfigurations @@ -4853,7 +5532,8 @@ DeleteNetworkInterfaceDot1XConfiguration - If greater than zero, the Dot1XMethods capability shall be present and shall contain at least the EAP-PEAP MSCHAPv2 method. + If greater than zero, the Dot1XMethods capability shall be present and shall + contain at least the EAP-PEAP MSCHAPv2 method. @@ -4861,7 +5541,8 @@ Dot1XMethods - If not empty, shall contain at least the “EAP-PEAP/MSCHAPv2” method, and MaximumNumberOfDot1XConfigurations shall be greater than zero. + If not empty, shall contain at least the “EAP-PEAP/MSCHAPv2” method, and + MaximumNumberOfDot1XConfigurations shall be greater than zero. @@ -4883,7 +5564,10 @@ EllipticCurves - The list of supported elliptic curves. + + The list of supported elliptic curves. + If the entry is non-empty it shall contain at least the baseline + AuthorizationServer.MaxConfigurations @@ -4898,7 +5582,9 @@ Events
Key Status - A device that indicates support for key handling via the MaximumNumberOfKeys capability shall provide information about key status changes through key status events. + A device that indicates support for key handling via the MaximumNumberOfKeys + capability shall provide information about key status changes through key status + events. A device shall include optional item OldStatus unless NewStatus is generating. @@ -4923,49 +5609,74 @@ This section is informative. - Faults and their types shall not disclose sensitive information to an attacker that he could not obtain otherwise. + Faults and their types shall not disclose sensitive information to an attacker that he + could not obtain otherwise. Secure up to date signature algorithm should be implemented by devices and clients. Devices signal the supported algorithm via their capabilities and clients should select - the algorithm with highest security strength supported by both parties. As common baseline - this specification requires device side support for SHA-2, particularly - sha256WithRSAEncryption as specified in RFC 4055. Note that for backward compatibility of - some usages this specification currently mandates device side support for - sha1WithRSAEncryption as specified in RFC 3279. - - - Operations with arguments that need protection against eavesdropping or manipulation shall only be executed over sufficiently protected communication channels. + the algorithm with highest security strength supported by both parties. See ONVIF Security + Baseline for algorithm to be supported. - It is good practice not to use the same key for different purposes. In order to prevent the device from using the same key for different purposes unnoticedly, this specification mandates that all keys in the keystore be distinct. + Operations with arguments that need protection against eavesdropping or manipulation + shall only be executed over sufficiently protected communication channels. - Private keys must be protected against disclosure to unauthorized parties. If a private key is uploaded in an encrypted PKCS#8 or PKCS#12 structure, the passphrase that is used to encrypt the structure must be uploaded to the device over a communication channel that is protected against eavesdropping in order to preserve the confidentiality of the private key. Moreover, the confidentiality of the uploaded private key depends on the strength of the encryption passphrase. It is therefore strongly recommended to use random passwords with sufficient length. + It is good practice not to use the same key for different purposes. In order to + prevent the device from using the same key for different purposes unnoticedly, this + specification mandates that all keys in the keystore be distinct. - In general, externally generated keys must be regarded less trustworthy than keys that are generated by the device because the probability of being disclosed to an attacker is higher for an externally generated key than for an internally generated key. A client may determine whether a key was generated by the device from the externallyGenerated attribute of the key. + Private keys must be protected against disclosure to unauthorized parties. If a + private key is uploaded in an encrypted PKCS#12 structure, the passphrase that is used to + encrypt the structure must be uploaded to the device over a communication channel that is + protected against eavesdropping in order to preserve the confidentiality of the private + key. Moreover, the confidentiality of the uploaded private key depends on the strength of + the encryption passphrase. It is therefore strongly recommended to use random passwords + with sufficient length. - While new specifications should be based on PKCS#5 v2.0 or higher, adoption of this standard is still limited. Therefore, this specification intends to balance security and interoperability by mandating cryptographic algorithms based on PKCS#5 v1.5 as interoperability baseline while strongly encouraging the use of PKCS#5 v2.0 or higher. Future versions of this specification or specifications referring to this specification may mandate additional cryptographic algorithms. + In general, externally generated keys must be regarded less trustworthy than keys that + are generated by the device because the probability of being disclosed to an attacker is + higher for an externally generated key than for an internally generated key. A client may + determine whether a key was generated by the device from the + externallyGenerated attribute of the key. - Although PKCS#8 RFC 5208 is widely used for exchanging cryptographic keys, this specification is based on the successor standard RFC 5958, particularly in order to incorporate both private key and public key in the same data structure. + The default certification path validation policy is designed as a permissive + interoperability baseline based on the certification path validation algorithm defined in + RFC 5280. - The default certification path validation policy is designed as a permissive interoperability baseline based on the certification path validation algorithm defined in RFC 5280. + CRLs can be expected to be available from virtually any CA as a source of revocation + information. The benefit of OCSP RFC 6960 as a means to obtain revocation information is + increasingly under question, since a man-in-the-middle attacker blocking OCSP traffic + combined with a permissive validator that silently accepts certificates for which no + revocation is available limits the effective security gain of using OCSP. Therefore, this + specification mandates support for CRLs as interoperability baseline and leaves other + revocation information sources to future versions. - CRLs can be expected to be available from virtually any CA as a source of revocation information. The benefit of OCSP RFC 6960 as a means to obtain revocation information is increasingly under question, since a man-in-the-middle attacker blocking OCSP traffic combined with a permissive validator that silently accepts certificates for which no revocation is available limits the effective security gain of using OCSP. Therefore, this specification mandates support for CRLs as interoperability baseline and leaves other revocation information sources to future versions. + Devices may be required to use different trust anchors for different security + features. Therefore, trust in a certificate is indicated as part of a certification path + validation policy rather than globally, e.g., with an attribute of the X509Certificate + data type. - Devices may be required to use different trust anchors for different security features. Therefore, trust in a certificate is indicated as part of a certification path validation policy rather than globally, e.g., with an attribute of the X509Certificate data type. + RFC 5280, Sect. 6.1.4 (k) mandates that every certificate in a certification path + except for the end entity certificate must be verified to be a CA certificate. For X.509 + version 3 certificates, this is verified through the CA attribute in the basic constraints + extension. For X.509 version 1 and 2 certificates, this information must be supplied by + out-of-band mechanisms. Within the scope of this specification, the only means to obtain + this information is the trust anchor information contained in the certification path + validation algorithm. - RFC 5280, Sect. 6.1.4 (k) mandates that every certificate in a certification path except for the end entity certificate must be verified to be a CA certificate. For X.509 version 3 certificates, this is verified through the CA attribute in the basic constraints extension. For X.509 version 1 and 2 certificates, this information must be supplied by out-of-band mechanisms. Within the scope of this specification, the only means to obtain this information is the trust anchor information contained in the certification path validation algorithm. - - - When configuring IEEE 802.1X, it is usually necessary to upload a password to the device’s keystore. This should be done either on a private network (e.g., using a direct network connection between a laptop and a device) or using TLS (SSL) on the device to encrypt client / device traffic. + When configuring IEEE 802.1X, it is usually necessary to upload a password to the + device’s keystore. This should be done either on a private network (e.g., using a direct + network connection between a laptop and a device) or using TLS (SSL) on the device to + encrypt client / device traffic. @@ -4974,28 +5685,77 @@ This section is informative.
General Design Goals - The Security Configuration Service is designed for modularity and extensibility. Therefore, each security feature is encapsulated in a separate port type within the service. Later revisions of this specification may add port types to enhance the Security Configuration Service by additional security features. - Within a security feature, capabilities indicate support for sub-features and configuration options. Later revisions of this specification may add additional sub-features to existing features and identify them by additional capabilities. - Port types and capabilities enable devices to support well-defined subsets of this specification and to communicate this information to clients effectively. + The Security Configuration Service is designed for modularity and extensibility. + Therefore, each security feature is encapsulated in a separate port type within the service. + Later revisions of this specification may add port types to enhance the Security + Configuration Service by additional security features. + Within a security feature, capabilities indicate support for sub-features and + configuration options. Later revisions of this specification may add additional sub-features + to existing features and identify them by additional capabilities. + Port types and capabilities enable devices to support well-defined subsets of this + specification and to communicate this information to clients effectively.
Keystore - The keystore design assumes that passphrases are chosen by clients. Therefore, an operation for retrieving passphrases from a device is deliberately omitted. If client loses a previously uploaded passphrase, the client should create a new passphrase, upload the new passphrase to the device, and delete the old passphrase from the device. - This specification deliberately deviates from the terminology in PKCS#8 and PKCS#12 by using the term ‘passphrase’ instead of ‘password’ in order to avoid confusion with the password that is assigned to ONVIF device users and the corresponding API in the ONVIF Device Management Service. - The keystore design is based on the rationale that an RSA key pair is a special type of key pair and a key pair is a special type of key. Therefore, key-related operations in the keystore deliberately refer to the most generic possible type in this hierarchy. For example, the DeleteKey operation (see Sect. ) refers to a key instead of a key pair or even an RSAKeyPair because it is applicable to all keys. On the other hand, the GetPrivateKeyStatus command refers to a key pair instead of a key, since this command is not meaningful for a key that is not a key pair, e.g., a symmetric key. - While this revision of the keystore specification only supports RSA key pairs as key pairs, later revisions of this specification may add other types of key pairs or symmetric keys as special types of keys. - Some interactions with the keystore, e.g., retrieving the private key for a public key that is contained in a certificate, are required device-internally, but need not be accessible to clients and may even, as in the above example, imply a security risk when made available outside the device. Such operations are therefore deliberately omitted from this specification. - The certificate-based client authentication specification intends to balance security concerns, interoperability, and implementation effort in order to facilitate adoption. Therefore, the certification path validation algorithm defined in RFC 5280 serves as interoperability baseline. The parameter values in the default certification path validation policy have been selected such that widely used implementations of the certification path validation algorithm can be used in their default configurations as much as permitted by the objective to provide an acceptable security baseline. - At the same time, more fine grained customization of the default certification path validation behavior in future versions of this specification is enabled by an extensible CertValidationPolicyParameters data type and capabilities that indicate which configuration options a device supports. As an example, checking for the TLS WWW client authentication key usage extension in client certificates is included in this specification, which can be implemented with moderate effort on the device side (e.g., with the OpenSSL option –purpose sslclient). Customization options for other parameters of the certification path validation algorithm are deliberately left to future versions of this specification in order to limit the required initial implementation effort. - In order to facilitate future extensions of this specification, the number of certification path validation policies that may be assigned to the TLS server simultaneously is not limited, but the certification path validation behavior is unspecified if more than one policy is assigned to the TLS server at the same time. Therefore, devices implementing this specification should limit the number of simultaneously assigned policies to one. + The keystore design assumes that passphrases are chosen by clients. Therefore, an + operation for retrieving passphrases from a device is deliberately omitted. If client loses + a previously uploaded passphrase, the client should create a new passphrase, upload the new + passphrase to the device, and delete the old passphrase from the device. + This specification deliberately deviates from the terminology in PKCS#12 by using the + term ‘passphrase’ instead of ‘password’ in order to avoid confusion with the password that + is assigned to ONVIF device users and the corresponding API in the ONVIF Device Management + Service. + The keystore design is based on the rationale that an RSA key pair is a special type of + key pair and a key pair is a special type of key. Therefore, key-related operations in the + keystore deliberately refer to the most generic possible type in this hierarchy. For + example, the DeleteKey operation (see Sect. ) refers to a key + instead of a key pair or even an RSAKeyPair because it is applicable to all keys. On the + other hand, the GetPrivateKeyStatus command refers to a key pair instead of a key, since + this command is not meaningful for a key that is not a key pair, e.g., a symmetric + key. + While this revision of the keystore specification only supports RSA and EC key pairs as + key pairs, later revisions of this specification may add other types of key pairs or + symmetric keys as special types of keys. + Some interactions with the keystore, e.g., retrieving the private key for a public key + that is contained in a certificate, are required device-internally, but need not be + accessible to clients and may even, as in the above example, imply a security risk when made + available outside the device. Such operations are therefore deliberately omitted from this + specification. + The certificate-based client authentication specification intends to balance security + concerns, interoperability, and implementation effort in order to facilitate adoption. + Therefore, the certification path validation algorithm defined in RFC 5280 serves as + interoperability baseline. The parameter values in the default certification path validation + policy have been selected such that widely used implementations of the certification path + validation algorithm can be used in their default configurations as much as permitted by the + objective to provide an acceptable security baseline. + At the same time, more fine grained customization of the default certification path + validation behavior in future versions of this specification is enabled by an extensible + CertValidationPolicyParameters data type and capabilities that indicate which configuration + options a device supports. As an example, checking for the TLS WWW client authentication key + usage extension in client certificates is included in this specification, which can be + implemented with moderate effort on the device side (e.g., with the OpenSSL option –purpose + sslclient). Customization options for other parameters of the certification path validation + algorithm are deliberately left to future versions of this specification in order to limit + the required initial implementation effort. + In order to facilitate future extensions of this specification, the number of + certification path validation policies that may be assigned to the TLS server simultaneously + is not limited, but the certification path validation behavior is unspecified if more than + one policy is assigned to the TLS server at the same time. Therefore, devices implementing + this specification should limit the number of simultaneously assigned policies to + one.
TLS Server - This revision of the Security Configuration Service Specification allows to manage assignments of certification paths to the TLS server on a device. It is permitted that a TLS server presents different certification paths to different clients, therefore more than one certification path may be assigned simultaneously to the TLS server to use as a server certificate. - All other configuration of the TLS server on a device is outside the scope of this specification revision and may be addressed by later revisions of this document. + This revision of the Security Configuration Service Specification allows to manage + assignments of certification paths to the TLS server on a device. It is permitted that a TLS + server presents different certification paths to different clients, therefore more than one + certification path may be assigned simultaneously to the TLS server to use as a server + certificate. + All other configuration of the TLS server on a device is outside the scope of this + specification revision and may be addressed by later revisions of this document.
- + JWT Content example Here is an example of JWT components to be encoded into a JWT Token JWT over SCTP example A JWT, whose content example is shown in , can be used in the WS-Security header of the SOAP request. To conform - to the BinarySecurityToken format, the JWT itself must be base64-encoded before being embedded - in the request: + linkend="q5l_q5m_51c"/>, can be used in the WS-Security header of the SOAP request. To + conform to the BinarySecurityToken format, the JWT itself must be base64-encoded before being + embedded in the request: - This encoded token can then be added to the SOAP request in a BinarySecurityToken element. + This encoded token can then be added to the SOAP request in a BinarySecurityToken + element. ]]> - + JWT over HTTPS example - The following exchange between client and device over HTTPS demonstrates a device supporting MD5 and SHA-256 for digest authentication as well as JWT-based client authentication. + The following exchange between client and device over HTTPS demonstrates a device + supporting MD5 and SHA-256 for digest authentication as well as JWT-based client + authentication. Unauthenticated request from the client: - + JWT over RTSPS example - The following exchange between client and device over RTSPS demonstrates a device supporting MD5 and SHA-256 for digest authentication as well as JWT-based client authentication. + The following exchange between client and device over RTSPS demonstrates a device + supporting MD5 and SHA-256 for digest authentication as well as JWT-based client + authentication. Unauthenticated request from the client: - - - Cipher Reference (Informative) - - This Annex is advocating a small subset of Ciphers as part of the ONVIF standard that readers of this specification can use as an informative guide. The following small subset of ciphers covering TLS 1.2 / 1.3 are common recommendations issued as guidance by the bodies Cloudflare, IETF (TLS 1.2, TLS1.3), Mozilla, and ciphersuite.info (TLS 1.2, TLS 1.3). - - While TLS 1.2 and 1.3 are both currently viable, we would suggest that TLS 1.3 is preferred. Do note that the table is not ordered by the strength of the cipher. - -
- TLS 1.3 / 1.2 Cipher list - - - - - - Minimum ProtocolIANA Name - - - - - - TLS 1.3TLS_AES_256_GCM_SHA384 - - - TLS 1.3TLS_CHACHA20_POLY1305_SHA256 - - - TLS 1.2TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 - - - TLS 1.2TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256 - - - TLS 1.2TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 - - - TLS 1.2TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 - - - TLS 1.2TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 - - - TLS 1.2TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 - - - -
+ + Deprecated Capabilities + + The following capabilities from the first version of the specification are still present in the schema files and are also partially referenced by the TLS Configuration Addon. + +
+ Keystore + + Deprecated Keystore Capabilities + + + + + + + + Capability Name + + + + + Replacement + + + + + + + + RSAKeyPairGeneration + + + KeyPairGeneration and RSAKeyLengths + + + + + ECCKeyPairGeneration + + + KeyPairGeneration and EllipticCurves + + + + + PKCS8RSAKeyPairUpload + + + deprecated + + + + + PKCS12CertificateWithRSAPrivateKeyUpload + + + PKCS12 and RSAKeyLengths + + + + + PKCS10ExternalCertificationWithRSA + + + PKCS10 and RSAKeyLengths + + + + + SelfSignedCertificateCreationWithRSA + + + SelfSignedCertificateCreation and RSAKeyLengths + + + + PasswordBasedMACAlgorithms + + + + +
+
- Revision History diff --git a/doc/SecurityBaseline.xml b/doc/SecurityBaseline.xml new file mode 100644 index 000000000..139c82613 --- /dev/null +++ b/doc/SecurityBaseline.xml @@ -0,0 +1,529 @@ + + + + + Security Baseline Specification + SecurityBaseline + 25.12 Draft + + ONVIF™ + www.onvif.org + + March 2025 + + + + + + + 2008-2025 + ONVIF™ All rights reserved. + + + Recipients of this document may copy, distribute, publish, or display this document so + long as this copyright notice, license and disclaimer are retained with all copies of the + document. No license is granted to modify this document. + THIS DOCUMENT IS PROVIDED "AS IS," AND THE CORPORATION AND ITS MEMBERS AND THEIR + AFFILIATES, MAKE NO REPRESENTATIONS OR WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT + LIMITED TO, WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, + NON-INFRINGEMENT, OR TITLE; THAT THE CONTENTS OF THIS DOCUMENT ARE SUITABLE FOR ANY PURPOSE; + OR THAT THE IMPLEMENTATION OF SUCH CONTENTS WILL NOT INFRINGE ANY PATENTS, COPYRIGHTS, + TRADEMARKS OR OTHER RIGHTS. + IN NO EVENT WILL THE CORPORATION OR ITS MEMBERS OR THEIR AFFILIATES BE LIABLE FOR ANY + DIRECT, INDIRECT, SPECIAL, INCIDENTAL, PUNITIVE OR CONSEQUENTIAL DAMAGES, ARISING OUT OF OR + RELATING TO ANY USE OR DISTRIBUTION OF THIS DOCUMENT, WHETHER OR NOT (1) THE CORPORATION, + MEMBERS OR THEIR AFFILIATES HAVE BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES, OR (2) + SUCH DAMAGES WERE REASONABLY FORESEEABLE, AND ARISING OUT OF OR RELATING TO ANY USE OR + DISTRIBUTION OF THIS DOCUMENT.  THE FOREGOING DISCLAIMER AND LIMITATION ON LIABILITY DO NOT + APPLY TO, INVALIDATE, OR LIMIT REPRESENTATIONS AND WARRANTIES MADE BY THE MEMBERS AND THEIR + RESPECTIVE AFFILIATES TO THE CORPORATION AND OTHER MEMBERS IN CERTAIN WRITTEN POLICIES OF + THE CORPORATION. + + + + 25.12 + Dec-2025 + + Hans Busch + + Draft + + + + + Scope + This document defines the security baseline for ONVIF specifications. Its content is based on state of the art technology as published by NIST or BSI. + Note, that any updates to this specification require a review of implications on technical, profile and addon specifications. + Publication of updates to this document must be synchronized with ONVIF Technical and Technical Service Committees. + + + Normative References + NIST FIPS 180-4 Secure Hash Standard (SHS) + <> + NIST FIPS 186-5 Digital Signature Standard (DSS) - February 3, 2023 + <> + BSI – Technical Guideline, Cryptographic Mechanisms: Recommendations and Key Length- January 31, 2025 + <> + RFC 4055 - Additional Algorithms and Identifiers for RSA Cryptography for use in the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile + <> + RFC 4868 - Using HMAC-SHA-256, HMAC-SHA-384, and HMAC-SHA-512 with IPsec + <> + RFC 5116 - An Interface and Algorithms for Authenticated Encryption + <> + RFC 5280 Internet X.509 Public Key Infrastructure Certificate and Certificate + Revocation List (CRL) Profile + <http://www.ietf.org/rfc/rfc5280.txt> + RFC 5758 - Internet X.509 Public Key Infrastructure: Additional Algorithms and Identifiers for DSA and ECDSA + <> + RFC 5869 - HMAC-based Extract-and-Expand Key Derivation Function (HKDF) + <> + RFC 7292 - PKCS #12: Personal Information Exchange Syntax v1.1 + <> + RFC 7714 - AES-GCM Authenticated Encryption in the Secure Real-time Transport Protocol (SRTP) + <> + RFC 8017 - PKCS #1: RSA Cryptography Specifications Version 2.2 + <> + RFC 8018 - PKCS #5: Password-Based Cryptography Specification Version 2.1 + <> + RFC 8439 - ChaCha20 and Poly1305 for IETF Protocols + <> + RFC 9579 - Use of Password-Based Message Authentication Code 1 (PBMAC1) in PKCS #12 Syntax + <> + + + Definitions + + + + + + + + Asymmetric Encryption + + + Encryption with public and private key pair. + + + + + Hash + + + Method to create a unique fingerprint of a large data set. + + + + + Signature + + + Private key signed hash that can be verified with the corresponding public + key. + + + + + + + + Overview + The content of this document is based on state of the art technology as published by the American institute NIST and the German department BSI. + Note, that any updates to this specification require a review of implications on technical, profile and addon specifications. + Publication of updates must synchronized with ONVIF Technical and Technical Service Committee + + + Asymmetric Encryption Schemes and Key Agreement + Baseline for asymmetric encryption and key agreement schemes that a device shall support + when it signals supports for the algorithm. + + Asymmetric Key Schemes + + + + + + + Name + + + Key Length + + + Comment + + + + + + + RSA + + + 3072 Bit + + RSA Baseline + + + secp256r1 + 256 + EC Baseline + + + +
+ + + Symmetric Encryption Schemes + Symmetric encryption algorithm a device shall support + + Symmetric Encryption Schemes + + + + + + + Name + + + Key Length + + + Comment + + + + + + AES-GCM + 128 Bit + RFC 5116 + + + +
+ + + Hash Functions + + + Hashes + + + + + + + Name + + + Size + + + Reference + + + + + + + SHA-2 + + + 256 Bit + + FIPS 180-4 + + + +
+ + + Signatures + + + Signatures + + + + + + + Name + + + Size + + + Reference + + + + + + RSASSA-PSS + >= 3000 Bit + RFC 8017 + + + ECDSA + >= 256 Bit + RFC 5758, X9.62 + + + +
+ + + Key Derivation + + Key Derivation Functions + + + + + + + Name + + + Reference + + + Comment + + + + + + + PBKDF2 + + RFC 8018 & RFC 9579 + for passwords + + + + HKDF + + RFC 5869 + for random keys + + + +
+ + + Certificates + Requirements for certificate upload and creation. + + Signature Baseline + + + + + + Name + + + Reference + + + + + + sha256WithRSAEncryption for RSA keys + RFC 4055 + + + ECDSA for EC keys + RFC 5758, X9.62 + + + +
+ + Baseline for Encrypting Private Key + + + + + + + + Name + + + Reference + + Capability + + + + + + PBKDF2 + + + RFC 8018 + + PasswordBasedEncryptionAlgorithms + + + + AES-128-CBC + + + RFC 7292 + + + + + +
+ + + TLS Cipher Reference (Informative) + + This Annex is advocating a small subset of Ciphers as part of the ONVIF standard that readers of this specification can use as an informative guide. + The following small subset of ciphers covering TLS 1.2 / 1.3 are based on the baseline defined in this document and match common practise by Cloudflare, Mozilla, and ciphersuite.info. + While TLS 1.2 and 1.3 are both currently viable, we would suggest that TLS 1.3 is preferred. Do note that the table is not ordered by the strength of the cipher. + + + TLS 1.3 / 1.2 Cipher list + + + + + + Minimum ProtocolIANA Name + + + + + + TLS 1.3TLS_AES_256_GCM_SHA384 + + + TLS 1.3TLS_CHACHA20_POLY1305_SHA256 + + + TLS 1.2TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 + + + TLS 1.2TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256 + + + TLS 1.2TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 + + + TLS 1.2TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 + + + TLS 1.2TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 + + + TLS 1.2TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 + + + +
+ + + Hybrid Public Key Encryption (Informative) + This section lists the HPKE encryption baseline and links them to the relevant IANA + registry. The listed algorithm map to the definitions in the normative sections above. + + + HPKE KEM Identifiers + + + + + + IANA Registry + Reference + + + + + 0x0010 + DHKEM(P-256, HKDF-SHA256) + + + +
+ + HPKE KDF Identifiers + + + + + + IANA Registry + Reference + + + + + 1 + HKDF-SHA256 + + + +
+ + HPKE AEAD Identifiers + + + + + + IANA Registry + Reference + + + + + 2 + AES-256-GCM + + + +
+ + + + Secure Streaming using SRTP (Informative) + This section lists the security baseline for SRTP streaming and links them to the relevant IANA + registry. The listed algorithm map to the definitions in the normative sections above. + + + SRTP Identifiers + + + + + + Algorithm + Reference + + + + + AEAD_AES_128_GCM + RFC 7714 + + + +
+ + + + Revision History + + + diff --git a/doc/index.html b/doc/index.html index 2984ebd70..9ac5bc8f8 100644 --- a/doc/index.html +++ b/doc/index.html @@ -181,6 +181,11 @@

Document preview

+Security Baseline + + + + Thermal thermal.wsdl radiometry.xsd diff --git a/wsdl/ver10/advancedsecurity/wsdl/advancedsecurity.wsdl b/wsdl/ver10/advancedsecurity/wsdl/advancedsecurity.wsdl index 3575be9c1..243a38cc1 100644 --- a/wsdl/ver10/advancedsecurity/wsdl/advancedsecurity.wsdl +++ b/wsdl/ver10/advancedsecurity/wsdl/advancedsecurity.wsdl @@ -82,7 +82,7 @@ - + @@ -740,12 +740,12 @@ - Indication that the device supports on-board RSA key pair generation. + Deprecated - Indication that the device supports on-board ECC key pair generation. - Indication that the device supports on-board ECC key pair generation. + Deprecated - Indication that the device supports on-board ECC key pair generation. @@ -765,7 +765,7 @@ - Indicates support for creating PKCS#10 requests for RSA keys and uploading the certificate obtained from a CA.. + Deprecated - Indicates support for creating PKCS#10 requests for RSA keys and uploading the certificate obtained from a CA.. @@ -775,7 +775,7 @@ - Indicates support for creating self-signed certificates for RSA keys. + Deprecated - Indicates support for creating self-signed certificates for RSA keys. @@ -795,7 +795,7 @@ - Indicates support for uploading an RSA key pair in a PKCS#8 data structure. + Deprecated - Indicates support for uploading an RSA key pair in a PKCS#8 data structure. @@ -805,7 +805,7 @@ - Indicates support for uploading a certificate along with an RSA private key in a PKCS#12 data structure. + Deprecated - Indicates support for uploading a certificate along with an RSA private key in a PKCS#12 data structure. @@ -2967,7 +2967,7 @@ - This operation uploads a key pair in a PKCS#8 data structure as specified in [RFC 5958, RFC 5959].
+ Deprecated method for uploading 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