Internet-Draft M. Norton Intended status: Informational Independent Expires: January 2, 2027 July 2, 2026 SDLP Security Architecture (SDLP RFC 4) draft-norton-sdlp-sec-arch-02 M. Norton Independent El Mirage, Arizona, USA Email: mark433norton@gmail.com July 2026 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. 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." Abstract This document defines the security architecture for the Secured Digital Lifecycle Protocol (SDLP). It specifies the security model, threat surfaces, authentication requirements, authorization boundaries, integrity guarantees, cryptographic requirements, and environment validation rules that apply to all SDLP-governed objects. 1. Introduction The Secured Digital Lifecycle Protocol (SDLP) defines a unified security model for digital objects that require authenticated actors, authorized lifecycle transitions, and verifiable lineage. SDLP provides a consistent foundation for object-level security by binding identity, lifecycle state, and lineage integrity into a single, enforceable architecture. This document specifies the SDLP security architecture. It defines the security model, threat surfaces, authentication requirements, authorization boundaries, and integrity guarantees that apply to all SDLP-governed objects. The architecture ensures that every lifecycle event—creation, activation, transformation, transfer, verification, retention, and retirement—is cryptographically attributable and verifiable. The SDLP security architecture operates in conjunction with three companion specifications: * SDLP Identity Model (SDLP RFC 1): Defines actor identities, object identities, and cryptographic bindings. * SDLP Lifecycle Model (SDLP RFC 2): Defines the deterministic state machine governing object transitions. * SDLP Lineage Model (SDLP RFC 3): Defines the canonical structure, sequencing, and verification of lineage entries. Together, these documents establish a complete security foundation for SDLP-governed digital objects. This document focuses exclusively on the security properties and requirements that ensure authenticated transitions, authorized operations, and tamper-evident lifecycle behavior across all compliant implementations. 2. Security Model The SDLP security model is based on authenticated actors, deterministic lifecycle transitions, and verifiable lineage. All lifecycle events MUST be cryptographically attributable to the entity that performed them, and all state changes MUST be validated against the SDLP Identity, Lifecycle, and Lineage specifications. SDLP-governed objects operate under three foundational security principles: * Identity Integrity: All actors and objects MUST possess stable, verifiable identities bound to approved cryptographic keys. Identity bindings MUST be authenticated before any lifecycle operation is permitted. * Transition Integrity: All lifecycle transitions MUST follow the deterministic state machine defined in the SDLP Lifecycle Model. Unauthorized, unverifiable, or out-of-order transitions MUST be rejected. * Lineage Integrity: All lifecycle events MUST produce canonical, signed lineage entries. Lineage MUST form a continuous, tamper-evident chain that reflects the complete history of the object. The SDLP security model ensures that every transformation, transfer, validation, and retirement event is authenticated, authorized, and cryptographically verifiable. This model provides a unified security foundation across all SDLP-compliant implementations. 3. Threat Surfaces SDLP identifies several primary threat surfaces that may compromise identity integrity, transition integrity, or lineage integrity. Implementations MUST address these threat surfaces to ensure secure lifecycle behavior across all SDLP-governed objects. Identity Spoofing: Attempts to impersonate distributors, customers, or objects by forging credentials, substituting keys, or falsifying identity bindings. Unauthorized Transformations: Attempts to perform lifecycle operations without proper authentication or authorization, including unauthorized creation, activation, transfer, or retirement. Lineage Tampering: Attempts to modify, remove, reorder, or falsify lineage entries, including manipulation of hashes, signatures, timestamps, or event sequencing. State Machine Bypass: Attempts to force an object into a state not permitted by the SDLP Lifecycle Model, including unauthorized transitions or attempts to skip required validation steps. Unauthorized Distribution: Attempts to duplicate, redistribute, or propagate objects outside authorized SDLP mechanisms, including attempts to create parallel or forked object instances. Resurrection and Unauthorized Reuse: Attempts to revive, reinstantiate, or reuse objects that have been retired, invalidated, or destroyed, including attempts to bypass termination or rebind identity. These threat surfaces define the adversarial conditions that SDLP implementations MUST defend against. The remaining sections of this document specify the authentication, authorization, and integrity requirements necessary to mitigate these threats. 4. Authentication Requirements All SDLP lifecycle operations MUST be authenticated. Actors and objects MUST present verifiable credentials bound to identities defined in the SDLP Identity Model before any lifecycle transition is permitted. Authentication ensures that every operation is attributable to a legitimate and authorized entity. Actor Authentication: Distributors, customers, and verification services MUST authenticate using approved cryptographic keys. Actor identities MUST be validated before performing creation, activation, transformation, transfer, verification, retention, or retirement operations. Object Authentication: SDLP-governed objects MUST authenticate themselves using their ObjectKey. Objects MUST verify their own identity bindings, lineage continuity, and current lifecycle state before accepting any operation. Signature Requirements: All authenticated operations MUST be signed using approved signature algorithms. Signatures MUST be computed over canonical data and MUST include identity fields, event type, previous hash, new state, and timestamp. Signature verification failure MUST result in rejection of the operation. Credential Binding: Credentials used for authentication MUST be bound to stable, non-repudiable identities. Credentials MUST NOT be shared, substituted, or reused across actors or objects. Credential binding MUST be validated before accepting any lifecycle event. Authentication Failure Handling: If authentication fails, the operation MUST be rejected. Objects MUST NOT perform lifecycle transitions, accept lineage entries, or modify internal state when authentication cannot be verified. These authentication requirements ensure that all SDLP lifecycle operations are performed only by authenticated entities and that every transition is cryptographically attributable and verifiable. 5. Authorization Boundaries SDLP defines strict authorization boundaries for all lifecycle operations. Each operation MUST be performed only by actors whose identities and roles have been authenticated according to the SDLP Identity Model. Implementations MUST enforce these boundaries before permitting any lifecycle transition. Creation: Only authorized distributors MAY create new SDLP-governed objects. Creation events MUST be signed with a valid DistributorKey and MUST establish the initial identity and lineage context for the object. Activation: Activation binds an object to a customer identity. Only the legitimate customer, or an authorized activation service acting on behalf of the customer, MAY perform activation. Activation MUST be authenticated and MUST produce a canonical lineage entry. Distribution: Distribution MAY occur only through authorized SDLP mechanisms. Unauthorized redistribution, duplication, or propagation MUST be rejected. Distribution events MUST preserve identity and lineage integrity. Transformation: Transformations, including state transitions defined in the SDLP Lifecycle Model, MAY occur only when the actor performing the operation is authorized to do so. Unauthorized transformations MUST be rejected and MUST NOT produce lineage entries. Verification: Verification operations MAY be performed by any authorized SDLP participant. Verification MUST validate identity bindings, lineage continuity, and transition integrity before accepting the object's current state. Retention: Retention of objects, including archival or long-term storage, MUST occur only under authorized conditions. Retention MUST NOT alter identity, lineage, or lifecycle state. Retirement: Retirement transitions, including termination or destruction, MUST be performed only by authorized actors and MUST follow the rules defined in the SDLP Lifecycle Model. Retirement events MUST be authenticated and MUST produce a final lineage entry. These authorization boundaries ensure that all SDLP lifecycle operations are performed only by authenticated and authorized actors, preserving the security and integrity of SDLP-governed objects across all compliant implementations. 6. Integrity Guarantees SDLP requires that all lifecycle operations preserve identity, state, and lineage integrity. Implementations MUST ensure that every transition, transformation, and verification event maintains a consistent and tamper-evident security posture across the entire lifecycle of the object. Identity Integrity: Identity bindings MUST remain stable and non-repudiable. Objects, distributors, and customers MUST use approved cryptographic keys, and identity fields MUST NOT be altered, substituted, or regenerated outside SDLP-defined processes. State Integrity: All lifecycle transitions MUST conform to the deterministic state machine defined in the SDLP Lifecycle Model. Objects MUST reject transitions that violate state rules, occur out of order, or originate from unauthorized actors. Lineage Integrity: Lineage entries MUST be canonical, complete, and signed using the ObjectKey. Each entry MUST reference the previous entry through a validated hash, forming a continuous and tamper-evident chain. Missing, reordered, or falsified entries MUST result in rejection of the operation. Transition Integrity: All lifecycle events MUST be authenticated and MUST produce verifiable lineage entries. Objects MUST validate signatures, timestamps, event types, and state transitions before accepting any operation. Data Integrity: All data used in lifecycle operations, including identity fields, lineage structures, and state information, MUST be encoded using canonical formats defined in SDLP companion specifications. Non-canonical or ambiguous encodings MUST be rejected. Integrity Failure Handling: If any integrity check fails, the operation MUST be rejected. Objects MUST NOT modify internal state, accept lineage entries, or perform lifecycle transitions when integrity cannot be verified. These integrity guarantees ensure that SDLP-governed objects remain verifiable, tamper-evident, and consistent across all compliant implementations, providing a stable foundation for secure lifecycle behavior. 7. Cryptographic Requirements SDLP relies on deterministic, verifiable, and tamper-evident cryptographic operations to ensure identity integrity, transition integrity, and lineage integrity. All cryptographic mechanisms used in SDLP-governed objects MUST conform to the requirements defined in this section. Hashing Requirements: SDLP objects MUST use approved cryptographic hash functions with at least 256-bit output. Hashes MUST be computed over canonical byte-encoded data and MUST be validated before accepting any lineage entry or lifecycle transition. Signature Requirements: All lifecycle operations MUST be authenticated using asymmetric signature algorithms providing at least 128-bit security strength. Signatures MUST be computed over canonical payloads and MUST include identity fields, event type, previous hash, new state, and timestamp. Signature verification failure MUST result in rejection of the operation. Key Roles: SDLP defines distinct cryptographic keys for specific roles: * DistributorKey: Used to authenticate creation and product metadata. * CustomerKey: Used to authenticate ownership-binding and transfer events. * ObjectKey: Used by the object to sign lineage entries and validate internal state. * PolicyAuthorityKey: Used to authenticate policy versions. Key Protection: Keys MUST be stored only in secure, non-exportable environments. Keys MUST NOT be written to disk in plaintext, included in backups, or exposed to external processes. Any attempt to access, modify, or replace key material MUST result in rejection of the operation. Key Stability: Keys MUST remain stable for the lifetime of their associated roles. ObjectKeys MUST NOT be regenerated, rotated, or replaced after instantiation. DistributorKeys and CustomerKeys MUST remain bound to their respective identities. Zeroization Requirements: When an object is retired or destroyed, its ObjectKey MUST be irreversibly zeroized. Zeroization MUST remove all key material from memory, secure storage, caches, and hardware-backed enclaves. Zeroized keys MUST NOT be recoverable or reissued. Cryptographic Validation: Objects MUST validate all hashes, signatures, and key bindings before performing lifecycle operations. Validation MUST occur at startup, before accepting lineage entries, and before executing any state transition. These cryptographic requirements ensure that SDLP-governed objects maintain stable identity, verifiable lineage, and tamper-evident lifecycle behavior across all compliant implementations. 8. Environment Validation SDLP-governed objects MUST execute only in environments that provide sufficient guarantees to preserve identity integrity, transition integrity, and lineage integrity. Before performing any lifecycle operation, an object MUST validate that its execution environment meets the minimum security requirements defined in this section. Trusted Execution Signals: The environment MUST provide stable and verifiable signals that allow the object to confirm that it is executing on a legitimate platform. These signals MAY include hardware-backed identity, secure enclaves, or equivalent mechanisms defined in companion specifications. Integrity Protection: The environment MUST prevent unauthorized modification of the object's code, data, and lineage. Protection mechanisms MUST ensure that memory tampering, binary patching, and unauthorized instrumentation cannot alter lifecycle behavior or compromise cryptographic material. Key Protection: The environment MUST provide secure storage for cryptographic keys, including the ObjectKey and any associated identity or policy keys. Secure storage MUST prevent extraction, rollback, duplication, or unauthorized access to key material. Debugging and Interception Controls: The environment MUST restrict or disable unauthorized debugging tools, interception frameworks, and runtime manipulation mechanisms. If such tools are detected, the object MUST reject the operation and MUST NOT perform lifecycle transitions. Time Source Requirements: The environment MUST provide a reliable and tamper-evident time source for validating timestamps associated with lineage entries and lifecycle transitions. Time inconsistencies MUST result in rejection of the operation. Validation Failure Handling: If environment validation fails, the object MUST reject the operation. Objects MUST NOT perform lifecycle transitions, accept lineage entries, or modify internal state when the environment cannot be verified. These environment validation requirements ensure that SDLP-governed objects execute only under conditions that preserve identity, transition, and lineage integrity across all compliant implementations 9. Security Considerations This document defines the security architecture for the Secured Digital Lifecycle Protocol and therefore consists entirely of security considerations. The requirements described in this document establish the security properties necessary to preserve identity integrity, transition integrity, and lineage integrity across all SDLP-governed objects. Implementations MUST ensure that authentication, authorization, cryptographic validation, and environment validation are performed consistently and correctly. Failure to enforce any requirement in this document may allow unauthorized lifecycle transitions, compromised lineage, or invalid identity bindings. SDLP security depends on correct implementation of companion specifications, including the SDLP Identity Model, SDLP Lifecycle Model, and SDLP Lineage Model. Implementations MUST ensure that these specifications are followed precisely and that all canonical formats, state rules, and lineage structures are validated before accepting lifecycle operations. Residual risks include incorrect key handling, improper environment validation, incomplete lineage verification, and failure to reject unauthorized transitions. Implementations MUST treat these risks as critical and MUST ensure that all validation mechanisms operate reliably under all supported conditions. No additional security considerations are identified beyond those described throughout this document. 10. IANA Considerations This document has no actions for IANA. No registries are created, modified, or deprecated by this specification. 11. References 11.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 11.2. Informative References None. Author's Address M. Norton Independent El Mirage, Arizona, USA Email: mark433norton@gmail.com