Security/baseline clarifications

[bsriramprasad]

Security Baseline Clarifications and Structural Improvements

This PR refactors the ONVIF Security Baseline specification to improve structural clarity, technical accuracy, normative completeness, and readability. No baseline requirements have been removed or weakened — all changes are clarifications, reorganisations, or additive.

---

#	Area	What Changed	Why	Value
1	Chapter structure	Renamed chapters to align with standard terminology: Asymmetric Encryption Schemes and Key Agreement → Public Key Cryptography; Key Derivation → Key Derivation Functions under new Key Management parent; JWT → Authentication and Authorization (§ JSON Web Token); Definitions → Terms and Definitions	Original names were technically imprecise or informal (JWT, Key Derivation excludes protection context)	Section names now match IETF/NIST/ISO conventions; stable for cross-document references
2	New Chapter 5 (Informative)	Added use-case-to-section mapping table covering TLS, X.509/PKI, JWT, media signing, SRTP, recording encryption, and HPKE	Document presented isolated algorithm tables with no guidance on where each primitive applies in ONVIF deployments	Gives implementers and reviewers a navigational entry point connecting ONVIF profiles to the normative sections that apply
3	Asymmetric & Signature tables	Merged separate algorithm and OID tables into single consolidated tables per domain; added morerows spanning for RSA PKCS#1 v1.5 (3 hash variants) and ECDSA (3 hash variants)	Splitting algorithm properties from OIDs forced cross-referencing two tables for a single algorithm	Each algorithm row is now self-contained: name, key size, OID, reference, and conformance level in one place
4	Baseline requirement column	Added to all tables, replacing informal Comment values such as "RSA Baseline", "EC Baseline", "for passwords" with explicit Required / Optional	Comment strings were not normative statements; conformance obligations were ambiguous	Conformance requirements are now explicit and unambiguous
5	RSA 4096-bit	Changed from comment "Public key usage" to Optional	The original comment was not a normative statement and could be misread as a requirement	Prevents accidental over-requirement of 4096-bit RSA as a baseline
6	Symmetric Encryption table	Expanded from 3 cols to 6 cols (Algorithm, Key Length, OID, Reference, Usage, Baseline requirement); added NIST AES OIDs for AES-GCM (2.16.840.1.101.3.4.1.6) and AES-128-CBC (2.16.840.1.101.3.4.1.2); AES-CTR marked — (no assigned OID)	AES-CTR and AES-128-CBC were missing OID and usage context; Comment column mixed references and descriptions informally	Symmetric encryption entries are now as complete as asymmetric and signature tables
7	AES-128-CBC placement	Moved from certTable (Private Key Protection) to symTable (Symmetric Encryption); Private Key Protection section now cross-references symTable and keyTable	AES-128-CBC is a symmetric algorithm; its exclusive placement in a key-protection table hid it from implementers enumerating symmetric primitives	Single source of truth for symmetric algorithms; Private Key Protection describes the PKCS#12 composition via cross-references rather than re-declaring algorithms
8	JWT RFC reference	RS256 and ES256: RFC 7519 → RFC 7518	RFC 7519 defines the JWT format; RS256/ES256 algorithm identifiers are defined in RFC 7518 (JSON Web Algorithms)	Normative references now point to the document that actually defines the referenced identifiers
9	Normative References	Added RFC 7518 (JWA) and NIST SP 800-38A (Block Cipher Modes)	Both were referenced in algorithm tables without being listed as normative references	Reference list is now complete and consistent with table citations
10	Public Key Cryptography definition	Added to Terms and Definitions: "Cryptographic operations using a key pair (public and private key), including encryption, key agreement, and digital signatures"	Term is used as a chapter title and in cross-references but was previously undefined	Scope of the term (encryption + key agreement + signatures) is explicit for all readers
11	RSA PKCS notation	RSA PKCS1 v1_5 → RSA PKCS#1 v1.5	Incorrect notation; # and . are part of the standard designation	Correct standard name throughout the document
12	HPKE Annex table headers	"IANA Registry" → "IANA Identifier"; "Reference" → "Algorithm"	Columns contained numeric identifiers and algorithm names, not registry names or references	Column headers now accurately describe their content
13	Grammar and style	"state of the art" → "state-of-the-art"; "Note, that" → "Note that"; "common practise" → "common practice"; "This Annex is advocating" → "This annex presents"; definition wording improved for Asymmetric Encryption, Hash, and Signature	Informal phrasing and grammatical inconsistencies not appropriate for a normative specification	Consistent formal register throughout

[MariaYa0091]

The Baseline requirement column in each table reflects the global minimum for all ONVIF implementations, independent of any specific profile or add-on.

Does this means that last version will be required for all Devices independently on supported Profiles and Add-ons? It is not what was discussed before, but this is how it is sounds like.

[bsriramprasad]

We want to see this like a Pyramid of requirements

• Profiles
  • Add-on
    • Service sepcs
      • Baseline

If baseline makes ALL mandatory, then we lose the flexibility and by default all the others up in the chain are forced to be mandatory.

Hence, we have chosen to mark as mandatory and optional so that, it will leave the flexibility for Profiles or Add-on to enforce additional requirements, if needed.

[MariaYa0091]

No, I'm about the versioning question.

The sentence sounds as absolute requirement for all devices. So even if Device have Add-on which linked to version X of Security Baseline, the latest to be supported by Device in addition to X in any case.

I'm will be happy with this approach, but I want to make sure that this is true.

[MariaYa0091]

Also does it make sense to include Optional requirements here? If them will be added to Add-on only, it will not change the picture. From other point any addition of optional entry will change Baseline version and will require Add-on update (unless the latest one is required for all devices).

[bsriramprasad]

If optional requirement do not have a place here, should they be in layers above like add-on or profile? if they are optional in docs in higher requirement ladder, how will anyone know they should implement them? Do we even add tests for any optional features if listed in add-on or profile? If so why are we doing that?

On the other hand, If they are optional here, there is a scope for us to tighten requirements in add-on or profile so that conformance tests can be added, unless I am missing something here?

[MariaYa0091]

It is not how I interpret the tables before. I thought all is mandatory. So I think tests are not fully valid.

[bsriramprasad]

previously some are marked baseline and not much clarified for other and we made it more clear, we have not changed any requirement as much as I understand.

[MariaYa0091]

I have wrong interpretation of this then.

[MariaYa0091]

For RSA 4096 Bit there was mark before "Public key usage". The interpretation was that device shall accepts certificates with such public key as a requirement, but private keys may not be supported.

This was done to have possibility to work with common certificates for validation purposes.

Was this removed intentionally.

[bsriramprasad]

'public key usage' is not a requirement level but some kind of 'usage clarification' which makes it hard and inconsistent to read the document between usage vs requirement level.

[MariaYa0091]

So currently Device may reject certificates with such keys?

[bsriramprasad]

If this is needed, we should change the 'baseline' to 4096? Or keep the baseline as-is and add this requirement into Profile-v-security-add-on!

[MariaYa0091]

For rsassa-pss hashes to be defined as well. Previously them was at the table:

While there is one OID for scheme itself is not depends on hash, hash to be part of parameters and to be transferred as well.

[bsriramprasad]

We added a link to hashes table

The applicable hash algorithms are defined in Table 'Hash functions and algorithm OIDs'.

[MariaYa0091]

Previously it was no directly mandated, but by current clarification all devices shall support both RSA and ECC. Is my understanding valid? So if only one is supported (ECC for example) Device shall fail conformance.

[bsriramprasad]

from the table in doc before this PR, what tells us that ECC is not required while RSA is required?

What changes in the current PR did we (unintentionally?) include brought this question that did not arise before?

[MariaYa0091]

Probably it was the same. But my previous understanding was:
If ECC is supported by device, secp256r1/secp386r1 is required.
If RSA is supported by device, 3072/4096 is required.

But I in general already got the idea that my interpretation was wrong.

So the question is: shall all devices support both ECC/RSA? Is this intentional?

[bsriramprasad]

Profile-V add-on already mandates creation of RSA and ECC for devices while either one is expected from clients for configuration. So we have not changed anything from before.. but lets iron this once for all in Budapest! If we are talking about the sizes, then if we have anything beyond baseline, we can write those 'overriding' requirements into add-on.

If ECC is supported by device, secp256r1/secp386r1 is required.
If RSA is supported by device, 3072/4096 is required.

If this is really the case, the word 'baseline' should have been added to both and I would have translated the same into 'required' for both of them, keeping baseline on one and adding 'usage' on the other makes it really hard and we expect people to guess may be.. which is our whole attempt to fix..

[bsriramprasad]

Removed requirement baseline

[MariaYa0091]

DTT and CCTT currently implements a bit different requirements. So implementation to be adjusted and it is RC phase, so the plan to be discussed.

[bsriramprasad]

Attached is the semantic diff of the changes made, As you can see most of the changes are structural and/or meld of tables.

SecurityBaseline-semantic-diff.html