Public Review Draft 1 for the Full DBMS Module Set Version 0.5

A Reader’s Guide that explains the division of responsibility among the Base cPP, Crypto Module, and the alternative Cloud and DBaaS deployment overlays; walks the selected PP-Configuration through the major security-architecture concerns; and provides an ADV_ARC.1 completeness checklist.

A Requirements Explorer that traces requirements, open operations, selection and dependency triggers, Supporting Document activities, and tests back to their owning artifacts.

Whether the DBMS Cryptographic Functions Module correctly owns the shared DBMS cryptographic requirements, including FDP_DIT_EXT.1.

Whether the Crypto Module clearly distinguishes Catalogue-derived SFRs, ECDs, dependencies, and Evaluation Activities from DBMS-iTC-originated integration requirements.

Whether the explicit Master Key protection selection in FCS_CKM_EXT.1.2 cleanly and testably separates TOE-enforced cryptographic protection, non-exportable hardware-backed storage, and transient-only handling from supporting operational-environment storage protection.

Whether the normative Crypto Module audit-event refinement captures the required key-lifecycle and protected-channel events without permitting secret key material or protected payloads in audit records.

Whether the Crypto SD’s transitional validation-evidence mechanism provides sufficient implementation, operating-environment, capability-coverage, residual-testing, and reporting controls without treating CAVP or CMVP as a substitute for DBMS integration activities.

Whether the optional Enterprise Enhanced use case appropriately constrains only the in-scope Catalogue selections needed for FIPS 140-3, NIAP, and CNSA 2.0 alignment.

Whether symmetric key encryption without an integrity mechanism (FCS_COP.1/SKC) should remain a permitted DEK-protection option in FCS_CKM_EXT.1.2 under the General-Purpose use case, or whether key wrapping or authenticated encryption should be required for all conforming TOEs. The Enterprise Enhanced use case already requires key wrapping or authenticated encryption for stored DEKs.

Whether the transitional use of CMVP (FIPS 140-3) module-validation evidence for the RBG self-test and failure-behavior iterations (FPT_TST.1/RBG, FPT_FLS.1/RBG), pending publication of the Catalogue Evaluation Methods, provides sufficient assurance under appropriate Certification Body control.

Whether the Crypto Module should offer ML-DSA signature verification (FCS_COP.1/SigVer) and role-specific ML-KEM KeyGen, encapsulation, and decapsulation (FCS_CKM.1/KEM and FCS_COP.1/KeyEncap) in anticipation of corresponding CCDB Cryptographic Catalogue collateral, relying on the transitional CAVP evidence mechanism for FIPS 203 and FIPS 204 algorithm correctness until the corresponding Catalogue entries and Evaluation Methods are available.

Whether the General-Purpose use case should retain the full FIPS 203/204 parameter-set families (ML-DSA-44/65/87, ML-KEM-512/768/1024), with the Enterprise Enhanced use case constraining selections to ML-DSA-87 and ML-KEM-1024, or whether only the CNSA 2.0 parameter sets should be offered, as in the AppSW cPP Version 2 approach.

Whether the DBMS in the Cloud Module contains only cloud-specific refinements, integration checks, and deployment-channel mapping.

Whether the Cloud SD’s stable activity-group identifiers and complete CEM mapping provide sufficient traceability for every FAU, FIA, FMT, FPT, FDP, and SAR Evaluation Activity.

Whether the DBaaS Module’s tenant-isolation, customer-controlled-key, provider-role-separation, trusted-update, service-event, and managed-service evidence models are complete and testable for publication alongside the Crypto + Cloud family.

Whether the PP-Configurations correctly compose the Base PP and required modules without creating contradictory conformance paths.