



Network Working Group                                            X. Zinn
Internet-Draft                                               Independent
Intended status: Informational                           18 January 2026
Expires: 22 July 2026


                       SoftHSM Enforcement Rules
                draft-xzinn-softhsm-enforcement-rules-00

Abstract

   This document defines enforcement and governance rules for the
   SoftHSM trust model.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at https://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on 22 July 2026.

Copyright Notice

   Copyright (c) 2026 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents (https://trustee.ietf.org/
   license-info) in effect on the date of publication of this document.
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.  Code Components
   extracted from this document must include Revised BSD License text as
   described in Section 4.e of the Trust Legal Provisions and are
   provided without warranty as described in the Revised BSD License.







Zinn                      Expires 22 July 2026                  [Page 1]

Internet-Draft          SoftHSM Enforcement Rules           January 2026


Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Scope and Goals . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  Threat Model  . . . . . . . . . . . . . . . . . . . . . . . .   4
   4.  Enforcement Principles  . . . . . . . . . . . . . . . . . . .   5
   5.  Capability Enforcement  . . . . . . . . . . . . . . . . . . .   6
   6.  Governance Enforcement  . . . . . . . . . . . . . . . . . . .   7
   7.  Operational Constraints . . . . . . . . . . . . . . . . . . .   9
   8.  Failure Modes . . . . . . . . . . . . . . . . . . . . . . . .  10
   9.  Security Considerations . . . . . . . . . . . . . . . . . . .  11

1.  Introduction

   # Abstract

   This document defines enforcement rules for software based hardware
   security modules used in identity based systems.  The rules specify
   what a SoftHSM MUST enforce, what it MUST ignore, and what it MUST
   never infer.  By constraining signing behavior to explicit,
   verifiable inputs, the model ensures deterministic authorization,
   prevents semantic confusion, and eliminates classes of attacks caused
   by implicit trust or contextual inference.

   # Status of This Memo

   This Internet Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet Drafts are working documents of the Internet Engineering
   Task Force.  They may be updated, replaced, or obsoleted by other
   documents at any time.  It is inappropriate to use Internet Drafts as
   reference material or to cite them other than as work in progress.

   # Introduction

   Cryptographic signing environments are frequently treated as passive
   tools that perform requested operations without evaluating intent,
   scope, or context.  This approach places responsibility for
   correctness entirely on calling applications and exposes signing keys
   to misuse, ambiguity, or unintended authorization.

   This document defines a SoftHSM enforcement model in which the
   signing environment actively enforces explicit rules before
   performing any cryptographic operation.  The SoftHSM does not
   interpret payloads, infer intent, or apply heuristics.  It evaluates
   only declared, verifiable inputs and enforces deterministic
   constraints.



Zinn                      Expires 22 July 2026                  [Page 2]

Internet-Draft          SoftHSM Enforcement Rules           January 2026


   The SoftHSM is positioned as the final authority prior to
   cryptographic signing.  It is the last opportunity to prevent misuse
   of keys, mis binding of semantics, or execution of unauthorized
   actions.

   This specification applies to software based HSM implementations
   operating on general purpose systems.  It does not define
   cryptographic algorithms, key storage formats, or physical security
   properties.  Instead, it defines behavioral constraints that any
   compliant SoftHSM MUST implement regardless of underlying
   cryptographic primitives.

   This document builds on the message envelope format, purpose
   semantics, consent model, and capability token mechanisms defined in
   earlier specifications.  It defines how those inputs are enforced at
   the point where signatures are created.

2.  Scope and Goals

   By making enforcement explicit and non inferential, the SoftHSM
   becomes a deterministic policy boundary rather than a passive
   cryptographic service.

   # Terminology

   The key words MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD,
   SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL in this document are to be
   interpreted as described in RFC 2119 and RFC 8174.

   SoftHSM A software based hardware security module that performs
   cryptographic operations while enforcing explicit policy and
   behavioral constraints.

   Signing Operation A cryptographic operation that produces a signature
   over defined input data using a private key managed by the SoftHSM.

   Signing Request A structured request presented to the SoftHSM that
   specifies the data to be signed and the context under which signing
   is requested.

   Required Inputs The explicit, verifiable inputs that MUST be present
   in a signing request for the SoftHSM to consider performing a signing
   operation.

   Enforcement The act of evaluating a signing request against defined
   rules and constraints prior to executing a cryptographic operation.





Zinn                      Expires 22 July 2026                  [Page 3]

Internet-Draft          SoftHSM Enforcement Rules           January 2026


   Deterministic Decision A signing decision that is fully determined by
   explicit inputs and configuration, producing the same outcome given
   the same inputs.

   Inference Any attempt to derive intent, authorization, or semantics
   from context, payload content, transport, or external state not
   explicitly provided in the signing request.

   Policy Local rules that constrain signing behavior, including which
   keys may be used, under what conditions, and for which purposes.

   Audit Record A verifiable record of a signing decision, including
   inputs evaluated and the resulting outcome.

   Key Material Cryptographic keys managed by the SoftHSM, including
   private keys and associated metadata.

   Signing Context The declared purpose, identity, and scope associated
   with a signing request.

3.  Threat Model

   Execution Any action taken as a result of a signing operation beyond
   the production of a cryptographic signature.  Execution semantics are
   explicitly outside the scope of the SoftHSM.

   # Enforcement Model

   The enforcement model defines how a SoftHSM evaluates signing
   requests and determines whether a cryptographic operation is
   permitted.

   The SoftHSM acts as a policy enforcement point.  It evaluates
   explicit inputs presented in a signing request against local policy
   and enforcement rules before performing any cryptographic operation.

   The SoftHSM MUST operate deterministically.  Given the same signing
   request, policy configuration, and key state, the SoftHSM MUST reach
   the same decision and produce the same outcome.

   The SoftHSM evaluates only explicit inputs.  It MUST NOT inspect
   payload contents, interpret application semantics, infer intent, or
   consult external context not explicitly provided in the signing
   request.

   The enforcement model follows a fixed evaluation order.





Zinn                      Expires 22 July 2026                  [Page 4]

Internet-Draft          SoftHSM Enforcement Rules           January 2026


   First, the SoftHSM MUST validate the structure and completeness of
   the signing request.  Second, the SoftHSM MUST verify the
   authenticity and integrity of the signing request inputs.  Third, the
   SoftHSM MUST evaluate required inputs against local policy.  Fourth,
   the SoftHSM MUST determine whether the requested signing operation is
   permitted.

   If any step fails, the signing operation MUST be denied.

   The SoftHSM MUST fail closed.  Absence of required inputs, ambiguity,
   or policy mismatch MUST result in denial rather than permissive
   behavior.

   The SoftHSM MUST treat signing requests as untrusted input.  Even
   requests originating from local applications or privileged processes
   MUST be evaluated identically.

   The enforcement model intentionally separates authorization from
   cryptographic execution.  Authorization is determined entirely before
   any cryptographic operation occurs.

   By constraining evaluation to explicit, verifiable inputs and
   enforcing a fixed decision order, the enforcement model prevents
   misuse of signing keys and eliminates classes of attacks based on
   implicit trust or contextual inference.

   The SoftHSM may support cryptographic operations other than signing,
   such as encryption or decryption.  However, this specification
   defines enforcement rules only for signing operations.  Requirements
   for encryption, key agreement, or confidentiality services are
   explicitly out of scope and may be defined by separate
   specifications.

4.  Enforcement Principles

   Any enforcement failure MUST result in deterministic failure and MUST
   NOT degrade into warnings, partial success, fallback behavior, or
   best effort execution.

   # Identity Bound Decryption Enforcement

   This section defines enforcement rules that bind decryption authority
   to a specific SoftHSM instance.

   A SoftHSM MUST possess a unique internal cryptographic identity for
   the purpose of enforcement.





Zinn                      Expires 22 July 2026                  [Page 5]

Internet-Draft          SoftHSM Enforcement Rules           January 2026


   When identity bound encryption is applied to an artifact, the SoftHSM
   MUST bind the encryption operation to its own SoftHSM identity.

   A SoftHSM MUST NOT permit decryption of an identity bound artifact
   unless the decryption operation is executed within the same
   authorized SoftHSM identity.

   Possession of valid cryptographic keys alone MUST NOT be sufficient
   to permit decryption.

   If an encrypted artifact is copied, exfiltrated, cloned, or otherwise
   removed from the authorized SoftHSM execution environment, decryption
   MUST fail deterministically.

   A SoftHSM MUST enforce this restriction regardless of key
   availability, key correctness, or external system state.

   Transfer of decryption authority to a different SoftHSM instance MUST
   require an explicit governance action as defined by the governance
   rules governing the SoftHSM environment.

   Silent key re wrapping, implicit trust inheritance, or undeclared
   SoftHSM substitution MUST NOT be permitted.

   A SoftHSM MUST record its identity as part of the audit record for
   any encryption or decryption operation involving identity bound
   artifacts.

   # Required Inputs

   A SoftHSM MUST require a complete and explicit set of inputs for
   every signing request.  Absence, ambiguity, or partial specification
   of required inputs MUST result in denial.

5.  Capability Enforcement

   The SoftHSM MUST NOT assume defaults, infer missing values, or derive
   intent from context.  Only explicitly provided inputs are
   authoritative.

   At a minimum, a signing request MUST include the following required
   inputs.

   Signing Key Identifier An explicit identifier for the private key
   requested for use.  The SoftHSM MUST NOT select keys implicitly or
   automatically.





Zinn                      Expires 22 July 2026                  [Page 6]

Internet-Draft          SoftHSM Enforcement Rules           January 2026


   Data to be Signed The exact data or cryptographic digest to be
   signed.  The SoftHSM MUST treat this data as opaque and MUST NOT
   inspect or interpret its contents.

   Declared Purpose The purpose associated with the signing request.
   The purpose MUST be explicit and MUST correspond to a supported
   purpose value.  Signing requests without a declared purpose are
   invalid.

   Requesting Identity The identity on whose behalf the signing request
   is made.  The SoftHSM MUST verify that this identity is authorized to
   request use of the specified key.

   Scope and Context Explicit scope information required to evaluate
   authorization, such as direction, resource class, or capability
   reference, when applicable.

   Authorization Evidence Verifiable evidence required by local policy
   to authorize signing, such as consent state, capability token
   reference, or policy identifier.  The SoftHSM MUST NOT attempt to
   retrieve or infer such evidence implicitly.

   Request Integrity A mechanism to ensure the integrity and
   authenticity of the signing request itself.  The SoftHSM MUST reject
   requests that cannot be verified as intact and authentic.

   All required inputs MUST be bound together as part of the signing
   request.  Modification of any required input after request submission
   MUST invalidate the request.

   The SoftHSM MUST validate required inputs prior to any policy
   evaluation or cryptographic operation.  Requests that fail validation
   MUST be denied without side effects.

   By requiring explicit and complete inputs, the SoftHSM ensures that
   signing decisions are intentional, reviewable, and immune to
   contextual ambiguity.

   # Prohibited Inference

   The SoftHSM MUST NOT infer intent, authorization, or semantics beyond
   what is explicitly provided in a signing request.

6.  Governance Enforcement

   Inference is prohibited because it introduces ambiguity, non
   determinism, and hidden policy decisions that undermine the security
   guarantees of the signing environment.



Zinn                      Expires 22 July 2026                  [Page 7]

Internet-Draft          SoftHSM Enforcement Rules           January 2026


   The SoftHSM MUST NOT infer or derive meaning from any of the
   following.

   Payload content Transport protocol or source Application identity or
   process context Historical behavior or prior requests User interface
   state or presentation Time of day or execution environment Absence of
   required inputs

   The SoftHSM MUST NOT attempt to classify, interpret, or inspect the
   data being signed.  The data to be signed is treated as opaque input.

   The SoftHSM MUST NOT broaden scope, escalate privilege, or relax
   constraints based on perceived legitimacy, repetition, or
   convenience.

   The SoftHSM MUST NOT attempt to compensate for incomplete requests.
   Missing or ambiguous inputs MUST result in denial rather than
   fallback behavior.

   The SoftHSM MUST NOT infer authorization from identity recognition
   alone.  Possession of a key or identity association does not imply
   permission to sign.

   Any behavior that results in different signing decisions for
   equivalent explicit inputs is prohibited.

   By explicitly forbidding inference, the SoftHSM enforces a strict
   separation between policy, authorization, and cryptographic
   execution.  This ensures that signing decisions remain deterministic,
   auditable, and resistant to misuse.

   # Signing Decision Rules

   Signing decision rules define how the SoftHSM determines whether to
   perform a signing operation once required inputs have been validated.

   A signing operation MUST be permitted only if all of the following
   conditions are satisfied.

   ' All required inputs are present, well formed, and authenticated '
   The requested signing key exists and is available for use ' The
   requesting identity is authorized to use the specified key ' The
   declared purpose is supported and permitted for the key ' Scope and
   context constraints are satisfied ' Required authorization evidence
   is present and valid ' No revocation or policy restriction applies

   If any condition fails, the signing operation MUST be denied.




Zinn                      Expires 22 July 2026                  [Page 8]

Internet-Draft          SoftHSM Enforcement Rules           January 2026


7.  Operational Constraints

   The SoftHSM MUST evaluate signing requests using a fixed and
   documented decision order.  Evaluation order MUST NOT vary based on
   request content or origin.

   The SoftHSM MUST NOT perform partial signing or conditional signing.
   Signing is an atomic operation that either succeeds completely or
   fails without side effects.

   The SoftHSM MUST NOT modify, normalize, or reinterpret the data being
   signed.  The signature MUST apply exactly to the data presented in
   the request.

   The SoftHSM MUST NOT expose private key material or intermediate
   cryptographic state as part of a signing decision.

   The SoftHSM MUST return a clear and deterministic outcome for each
   signing request, indicating approval or denial.  Error reporting MUST
   NOT leak sensitive policy or key information.

   By enforcing explicit and ordered decision rules, the SoftHSM ensures
   that cryptographic operations occur only when authorization is
   unambiguous and complete.

   # Audit and Determinism

   Audit and determinism requirements ensure that SoftHSM behavior is
   observable, reproducible, and resistant to silent policy drift.

   The SoftHSM MUST produce deterministic outcomes.  Given the same
   signing request, policy configuration, and key state, the SoftHSM
   MUST reach the same decision and produce identical results.

   The SoftHSM SHOULD record an audit record for each signing request.
   Audit records SHOULD include sufficient information to reconstruct
   the decision without exposing sensitive key material or payload
   contents.

   At a minimum, audit records SHOULD capture:

   ' Timestamp of the request ' Signing key identifier ' Requesting
   identity ' Declared purpose ' Decision outcome ' Policy reference
   applied

   Audit records MUST NOT include private key material or raw payload
   data.  Where payload digests are recorded, they MUST be treated as
   sensitive metadata.



Zinn                      Expires 22 July 2026                  [Page 9]

Internet-Draft          SoftHSM Enforcement Rules           January 2026


   Audit mechanisms MUST NOT influence signing decisions.  Failure to
   record an audit event MUST NOT cause a signing operation to succeed
   or fail differently.

8.  Failure Modes

   Audit records SHOULD be protected against modification and
   unauthorized access.  Integrity of audit records is essential for
   post hoc verification and dispute resolution.

   The SoftHSM MUST NOT rely on audit state to make authorization
   decisions.  Audit is observational, not operational.

   By enforcing determinism and producing verifiable audit trails, the
   SoftHSM enables accountability without introducing inference or
   coupling between authorization and observation.

   # Security Considerations

   The SoftHSM represents the final authorization boundary prior to
   cryptographic signing and therefore must be treated as a high value
   security component.

   The primary security objective of the SoftHSM enforcement model is to
   prevent unauthorized or unintended use of signing keys.  By requiring
   explicit inputs and prohibiting inference, the model reduces the risk
   of confused deputy attacks, privilege escalation, and semantic
   misbinding.

   Key misuse is a central threat.  The SoftHSM MUST ensure that keys
   are used only for explicitly authorized purposes and scopes.  Failure
   to enforce purpose or scope constraints may result in signatures that
   assert unintended meaning or authority.

   Signing request forgery is another risk.  The SoftHSM MUST verify the
   integrity and authenticity of signing requests and MUST reject
   requests that cannot be validated.

   Policy misconfiguration may lead to overly permissive behavior.
   Implementations SHOULD provide mechanisms to validate policy
   consistency and SHOULD favor fail closed behavior in the presence of
   ambiguity.

   Side channel leakage, such as timing differences or error messages,
   may reveal information about policy or key availability.
   Implementations SHOULD minimize observable differences between denial
   reasons and SHOULD avoid exposing detailed failure modes to untrusted
   callers.



Zinn                      Expires 22 July 2026                 [Page 10]

Internet-Draft          SoftHSM Enforcement Rules           January 2026


   Compromise of the host system threatens the SoftHSM.  While this
   document does not define host hardening requirements, implementations
   SHOULD consider isolation mechanisms, access controls, and monitoring
   appropriate to their threat model.

   By enforcing deterministic authorization and strict separation of
   concerns, the SoftHSM reduces reliance on application correctness and
   provides a robust defense against classes of attacks caused by
   implicit trust or contextual interpretation.

   # Security Considerations

   The SoftHSM represents the final authorization boundary prior to
   cryptographic signing and therefore must be treated as a high value
   security component.

9.  Security Considerations

   The primary security objective of the SoftHSM enforcement model is to
   prevent unauthorized or unintended use of signing keys.  By requiring
   explicit inputs and prohibiting inference, the model reduces the risk
   of confused deputy attacks, privilege escalation, and semantic
   misbinding.

   Key misuse is a central threat.  The SoftHSM MUST ensure that keys
   are used only for explicitly authorized purposes and scopes.  Failure
   to enforce purpose or scope constraints may result in signatures that
   assert unintended meaning or authority.

   Signing request forgery is another risk.  The SoftHSM MUST verify the
   integrity and authenticity of signing requests and MUST reject
   requests that cannot be validated.

   Policy misconfiguration may lead to overly permissive behavior.
   Implementations SHOULD provide mechanisms to validate policy
   consistency and SHOULD favor fail closed behavior in the presence of
   ambiguity.

   Side channel leakage, such as timing differences or error messages,
   may reveal information about policy or key availability.
   Implementations SHOULD minimize observable differences between denial
   reasons and SHOULD avoid exposing detailed failure modes to untrusted
   callers.

   Compromise of the host system threatens the SoftHSM.  While this
   document does not define host hardening requirements, implementations
   SHOULD consider isolation mechanisms, access controls, and monitoring
   appropriate to their threat model.



Zinn                      Expires 22 July 2026                 [Page 11]

Internet-Draft          SoftHSM Enforcement Rules           January 2026


   By enforcing deterministic authorization and strict separation of
   concerns, the SoftHSM reduces reliance on application correctness and
   provides a robust defense against classes of attacks caused by
   implicit trust or contextual interpretation.

   # IANA Considerations

   This document does not define any new namespaces, registries,
   protocol numbers, or parameters requiring action by IANA.

   If future specifications define registries related to SoftHSM policy
   identifiers or standardized signing contexts, those documents will
   specify their own IANA considerations.

   # References

   ## Normative References

   <<RFC2119>> Bradner, S., "Key words for use in RFCs to Indicate
   Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March
   1997.

   <<RFC8174>> Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
   2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017.

   ## Informative References

   <<FIPS140-3>> National Institute of Standards and Technology,
   "Security Requirements for Cryptographic Modules", FIPS PUB 140-3,
   March 2019.





















Zinn                      Expires 22 July 2026                 [Page 12]
