English 
Tiếng ViệtStable discovery contract
C_GetSlotList, token-presence behavior, slot labels, serial numbers, event handling and HA/failover rules are recorded per release.
TRUSTED PQC PROVIDER SUITE
PKCS#11 Provider
A published Cryptoki contract—not a generic middleware claim.
A release-specific native library that exposes governed slots, sessions, objects, key operations and signature/KEM mechanisms to enterprise applications while keeping private-key execution within an approved token, HSM, QSCD or remote-signing boundary.
CRYPTOKI MODEL
Slots, sessions, objects and mechanisms have explicit behavior.
The provider contract identifies the library filename, ABI, supported Cryptoki version, threading rules, slot stability, login scope, object attributes, mechanism identifiers and return-code behavior. Vendor-defined PQC or hybrid mechanisms are never implied to be portable across providers.
Defined login semantics
RO/RW sessions, User/SO roles, context-specific authentication, session pooling, timeout and PIN lockout are documented.
Versioned attribute profile
CKO_PRIVATE_KEY, CKO_PUBLIC_KEY and CKO_CERTIFICATE templates define CKA_ID, CKA_LABEL, sensitivity, extractability and permitted operations.
Published operation mapping
Classical mechanisms and controlled ML-DSA/ML-KEM or hybrid vendor profiles are tied to exact headers, parameter structures and evidence.
FUNCTION MATRIX
Core Cryptoki functions are documented before integration.
| Function group | Representative functions | Release evidence |
|---|---|---|
| Initialization | C_GetFunctionList, C_Initialize, C_Finalize | ABI/threading and lifecycle test |
| Slot/token | C_GetSlotList, C_GetTokenInfo, C_WaitForSlotEvent | Stable slot and token-removal behavior |
| Sessions/authentication | C_OpenSession, C_Login, C_Logout, C_CloseSession | Role, pooling, expiry and lockout tests |
| Object discovery | C_FindObjectsInit, C_FindObjects, C_GetAttributeValue | Visibility and attribute profile |
| Key lifecycle | C_GenerateKeyPair, C_DestroyObject, C_DeriveKey | Mechanism, policy and zeroization result |
| Signature | C_SignInit, C_Sign, C_VerifyInit, C_Verify | Mechanism, encoding and test vectors |
REFERENCE FLOW
Release-specific integration sequence.
Load approved library
Match platform, ABI, header version and library checksum.
Discover slot and token
Resolve stable slot identity, token presence and HA behavior.
Open session and authenticate
Apply RO/RW, User/SO or context-specific login policy.
Resolve protected object
Find key/certificate by approved attributes and visibility rules.
Execute mechanism
Run sign, verify or controlled KEM operation with exact parameters.
Close and evidence
Finalize sessions, capture return codes, object state and backend audit.
DEVELOPER PACKAGE
Reference material is separated into the questions implementers actually ask.
Function support
Publishes the exact Cryptoki ABI, shared-library filename, header version, initialization flags and function-table behavior required to load the provider safely.
Open function matrix →Mechanism registry
Defines standard and vendor-profile mechanism identifiers, key types, parameter structures, encodings and operation maturity for classical, PQC and hybrid operations.
Open mechanism matrix →Objects & attributes
Specifies private-key, public-key and certificate templates including CKA_ID association, sensitivity, extractability, mutability, persistence and visibility rules.
Open attribute profile →Sessions & authentication
Documents RO/RW sessions, User/SO/context-specific login, pooling, timeout, multi-threading, multi-process behavior and handle invalidation during removal or failover.
Open auth model →Return codes
Maps CKR return codes to root cause, retryability, remediation, protected-backend correlation and audit behavior without exposing PINs or sensitive key material.
Open error catalogue →Compilable C samples
Includes illustrative C and CMake sources for initialization, slot discovery, login, object lookup, signing, verification, cleanup and negative-path testing.
View samples →KNOWN BOUNDARIES
Known limitations and release boundaries
These constraints prevent a pilot profile from becoming an unsupported general claim.
CONTROLLED PILOT
Freeze library, header, mechanism list, backend and application before acceptance.
The acceptance report must include multi-process/session behavior, token removal, error paths, object persistence and exact mechanism identifiers.