Internet-Draft M. Norton Intended status: Informational Independent Expires: January 24, 2027 July 24, 2026 SDLP Security Architecture (SDLP RFC 4) draft-norton-sdlp-sec-arch-04 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 The Secured Digital Lifecycle Protocol (SDLP) defines a physics-layer security model in which digital objects secure themselves throughout their entire lifecycle. Existing security measures—such as cryptographic signatures, watermarking, provenance metadata, and attestation—are integrated and enforced within a unified physics layer positioned between the Transport and Application layers. This document describes the SDLP security architecture, including the environment safety check, the composite PASS/FAIL trust verdict, and the mandatory BitDrop behavior applied when any trust condition fails. The SDLP security architecture ensures that digital objects operate only within verified, tamper-resistant environments and provides a complete, end-to-end defense against unauthorized access, copying, modification, and redistribution. Table of Contents 1. Introduction 2. Terminology 3. SDLP Security Architecture Overview 3.1. The Physics Layer 3.2. Placement Between Transport and Application Layers 3.3. Integration of Existing Security Measures 4. Environment Safety Check 4.1. Full-Spectrum Validation 4.2. Composite PASS/FAIL Trust Verdict 4.3. BitDrop Behavior on FAIL 4.4. Prohibition of Partial Trust States 5. Lifecycle Security Model 5.1. Object Self-Security 5.2. Tamper Detection and Response 5.3. Provenance and Lineage Continuity 5.4. Decay and Lifecycle Enforcement 6. Threat Model 6.1. Piracy Vectors 6.2. Unauthorized Redistribution 6.3. Tampering and Instrumentation 6.4. Environment Spoofing 7. Security Considerations 8. IANA Considerations 9. References 9.1. Normative References 9.2. Informative References Acknowledgments Author's Address 1. Introduction The Secured Digital Lifecycle Protocol (SDLP) provides a unified security architecture designed to protect digital objects throughout their entire lifecycle. Modern content-distribution ecosystems rely on multiple independent security mechanisms—such as cryptographic signatures, watermarking, provenance metadata, attestation, and environment verification—but these mechanisms operate in isolation and leave gaps that can be exploited for unauthorized access, copying, or redistribution. SDLP addresses these gaps by introducing a physics-layer security model positioned between the Transport and Application layers. In this model, each SDLP object secures itself, performing a full-spectrum environment safety check before any operation is permitted. The physics layer integrates existing security measures and enforces them consistently, ensuring that digital objects operate only within verified, trusted, and tamper-resistant environments. A composite PASS/FAIL trust verdict determines whether an SDLP object may proceed. Any failure in the environment safety check results in mandatory BitDrop, preventing partial trust states and eliminating exploit surfaces associated with degraded or permissive behavior. This architecture provides an end-to-end defense against piracy, tampering, instrumentation, environment spoofing, and unauthorized redistribution. This document describes the SDLP security architecture, the role of the physics layer, the environment safety check, the PASS/FAIL trust model, and the BitDrop enforcement mechanism. 2. Terminology The following terms are used throughout this document: SDLP Object A digital object that conforms to the Secured Digital Lifecycle Protocol and contains all required lineage, provenance, and physics-layer enforcement metadata. Physics Layer A security enforcement layer positioned between the Transport and Application layers. The physics layer performs environment safety checks, applies lifecycle rules, and enforces PASS/FAIL trust decisions. Environment Safety Check A full-spectrum validation performed by an SDLP object to assess the trustworthiness of its execution environment. The check includes identity verification, tamper detection, transport-path integrity, lineage consistency, provenance validation, and policy compatibility. PASS/FAIL Trust Verdict A composite trust decision produced by the environment safety check. PASS indicates that all trust conditions are satisfied. FAIL indicates that one or more trust conditions have failed. BitDrop The mandatory behavior applied when the trust verdict is FAIL. An SDLP object MUST cease operation and become unusable. Partial trust states are not permitted. Lineage The set of identifiers that uniquely describe an SDLP object's origin and individuality: DistributorID, CustomerID, ProductID, ProductName, DownloadID, Date, and Time. Provenance Cryptographic and metadata-based information that establishes the authenticity and origin of an SDLP object and its relationship to the distributor’s trust graph. Decay A lifecycle mechanism that governs the remaining operational energy, permitted actions, and lifecycle stage of an SDLP object. Tamper Detection The physics-layer capability to identify unauthorized debugging, instrumentation, virtualization, memory inspection, or other forms of environment manipulation. BitDrop-Protected Environment An execution environment that supports physics-layer enforcement, including the ability to apply BitDrop, validate lineage, enforce decay, and maintain provenance continuity. 3. SDLP Security Architecture Overview The SDLP security architecture defines how digital objects secure themselves through a physics-layer enforcement model. This model integrates existing security mechanisms and applies them consistently across the entire lifecycle of an SDLP object. The architecture ensures that objects operate only within trusted environments and that any violation of trust results in immediate termination through BitDrop. This section provides an overview of the physics layer, its placement within the protocol stack, and its role in unifying existing security measures. 3.1. The Physics Layer The physics layer is the core enforcement mechanism of SDLP. It governs object behavior, validates the execution environment, applies lifecycle rules, and enforces trust decisions. Unlike traditional application-level security models, the physics layer resides within the object itself, allowing each SDLP object to perform autonomous security operations. The physics layer performs the environment safety check, evaluates lineage and provenance continuity, detects tampering, enforces decay, and determines whether an object may proceed. All enforcement occurs before the application is permitted to interact with the object. 3.2. Placement Between Transport and Application Layers The physics layer is positioned between the Transport and Application layers. This placement ensures that SDLP objects validate their environment immediately upon arrival, before any application-level processing occurs. By operating at this layer, SDLP prevents exploit surfaces associated with application-level enforcement, such as unauthorized playback, instrumentation, or environment spoofing. The physics layer acts as a mandatory gatekeeper, allowing or denying access based solely on the PASS/FAIL trust verdict. 3.3. Integration of Existing Security Measures SDLP does not replace existing security mechanisms; it unifies and enforces them. The physics layer incorporates cryptographic signatures, watermarking, provenance metadata, attestation tokens, transport-path integrity checks, and environment verification into a single, cohesive enforcement model. Each SDLP object uses these mechanisms during the environment safety check. The physics layer ensures that all measures are applied consistently and that any failure in any measure results in a FAIL verdict and mandatory BitDrop. This integration eliminates gaps created by isolated or partial security systems and provides complete lifecycle protection. 4. Environment Safety Check The environment safety check is the primary security operation performed by the SDLP physics layer. Before any SDLP object may be accessed, interpreted, or executed by an application, the object MUST perform a full-spectrum validation of its execution environment. The environment safety check determines whether the environment is trustworthy, uncompromised, and capable of enforcing SDLP physics. The result of this validation is a composite PASS/FAIL trust verdict. A FAIL verdict triggers mandatory BitDrop, and no partial trust states are permitted. 4.1. Full-Spectrum Validation The environment safety check evaluates all relevant dimensions of trust. An SDLP object MUST validate: * Execution environment identity * Transport-path integrity * Tamper and instrumentation detection * Lineage consistency * Provenance continuity * Decay and lifecycle state * Policy compatibility with SDLP physics These checks are performed autonomously by the SDLP object. The physics layer MUST complete all checks before any application-level interaction is allowed. Failure in any dimension results in a FAIL verdict. 4.2. Composite PASS/FAIL Trust Verdict The environment safety check produces a single composite trust verdict. The verdict is binary: * PASS: All trust conditions are satisfied. * FAIL: One or more trust conditions have failed. SDLP objects MUST NOT expose individual trust-dimension results to the application. The composite verdict is the only output of the environment safety check. This design prevents applications from attempting to operate in degraded or partially trusted states. 4.3. BitDrop Behavior on FAIL If the composite trust verdict is FAIL, the SDLP object MUST perform BitDrop. BitDrop is the mandatory termination behavior in which the object ceases operation and becomes unusable. An object that has performed BitDrop MUST NOT be recoverable, replayable, or usable in any subsequent environment. BitDrop prevents exploit surfaces associated with permissive or degraded behavior. It ensures that no SDLP object can be coerced into operating within an unsafe, tampered, or unverifiable environment. 4.4. Prohibition of Partial Trust States SDLP objects MUST NOT operate in partial trust states. The physics layer does not support degraded modes, permissive fallback behavior, or conditional operation based on incomplete validation. Any failure in any trust dimension MUST result in a FAIL verdict and mandatory BitDrop. This prohibition eliminates attack vectors that rely on partial validation, weakened enforcement, or incomplete security checks. By enforcing a strict PASS/FAIL model, SDLP ensures that digital objects operate only within fully verified, tamper-resistant environments and that no exploitable intermediate states exist. 5. Lifecycle Security Model The SDLP lifecycle security model defines how digital objects secure themselves from creation through termination. Unlike traditional security systems that rely on external enforcement, SDLP objects contain all necessary mechanisms to validate their environment, enforce lifecycle rules, and respond to tampering. The lifecycle model ensures that objects remain trustworthy, verifiable, and resistant to unauthorized manipulation throughout their existence. 5.1. Object Self-Security SDLP objects are autonomous security entities. Each object contains the metadata, cryptographic material, lineage identifiers, provenance anchors, and physics-layer logic required to secure itself. No external application or runtime is responsible for enforcing SDLP security; enforcement is intrinsic to the object. Before any operation is permitted, the object MUST perform the environment safety check described in Section 4. If the composite trust verdict is PASS, the object may proceed. If the verdict is FAIL, the object MUST perform BitDrop and terminate. 5.2. Tamper Detection and Response The physics layer includes mechanisms to detect unauthorized debugging, instrumentation, virtualization, memory inspection, hooking, or other forms of tampering. Tamper detection is performed as part of the environment safety check and may also occur during object operation if supported by the environment. If tampering is detected, the object MUST produce a FAIL verdict and perform BitDrop. SDLP objects MUST NOT attempt to continue operation after tamper detection, nor may they enter a degraded or partially trusted state. 5.3. Provenance and Lineage Continuity SDLP objects maintain continuity of provenance and lineage throughout their lifecycle. Provenance anchors and lineage identifiers (DistributorID, CustomerID, ProductID, ProductName, DownloadID, Date, and Time) MUST remain intact and verifiable. The physics layer validates provenance and lineage during the environment safety check. Any inconsistency, corruption, or removal of lineage or provenance information MUST result in a FAIL verdict and mandatory BitDrop. Provenance continuity ensures that SDLP objects cannot be separated from their origin, redistributed without authorization, or injected into untrusted ecosystems. 5.4. Decay and Lifecycle Enforcement SDLP objects include a decay mechanism that governs their lifecycle state, remaining operational energy, and permitted actions. Decay rules are defined by the distributor and enforced by the physics layer. The physics layer MUST validate the object's decay state during the environment safety check. If the object has exceeded its permitted lifecycle or if decay rules cannot be enforced by the environment, the object MUST produce a FAIL verdict and perform BitDrop. Decay ensures that SDLP objects cannot be used indefinitely, replayed without restriction, or operated outside their intended lifecycle parameters. Lifecycle enforcement provides an additional layer of protection against unauthorized redistribution and long-term misuse. 6. Threat Model The SDLP threat model identifies the classes of attacks that digital objects may encounter throughout their lifecycle and describes how the physics layer mitigates these threats. Traditional content- protection systems rely on external enforcement, which leaves gaps exploitable by piracy, tampering, environment spoofing, and unauthorized redistribution. SDLP addresses these threats by embedding enforcement within the object itself and applying a strict PASS/FAIL trust model with mandatory BitDrop on failure. 6.1. Piracy Vectors Piracy includes unauthorized copying, redistribution, extraction, replay, or reproduction of digital objects. Attackers may attempt to bypass application-level controls, intercept transport paths, or manipulate runtime environments to obtain unrestricted access. SDLP mitigates piracy by requiring each object to validate its environment before any operation is permitted. Lineage and provenance continuity ensure that objects cannot be separated from their origin or redistributed without detection. Any attempt to operate an object outside a trusted environment results in a FAIL verdict and BitDrop. 6.2. Unauthorized Redistribution Unauthorized redistribution occurs when digital objects are copied, transferred, or shared outside their intended distribution channels. Attackers may attempt to replay objects in untrusted environments, strip identifying metadata, or inject objects into unauthorized ecosystems. SDLP objects contain immutable lineage identifiers and provenance anchors that MUST remain intact. The physics layer validates these identifiers during the environment safety check. If lineage or provenance information is missing, corrupted, or inconsistent, the object MUST produce a FAIL verdict and perform BitDrop. 6.3. Tampering and Instrumentation Tampering includes debugging, hooking, memory inspection, virtualization, instrumentation, or any attempt to alter object behavior or bypass enforcement. Attackers may attempt to modify object code, intercept physics-layer operations, or manipulate runtime conditions. The physics layer includes tamper detection mechanisms that identify unauthorized manipulation. If tampering is detected at any point, the object MUST produce a FAIL verdict and perform BitDrop. SDLP objects MUST NOT continue operation after tamper detection, nor may they enter degraded or partially trusted states. 6.4. Environment Spoofing Environment spoofing occurs when attackers attempt to deceive digital objects into believing they are operating within a trusted environment. Spoofing may involve falsifying attestation tokens, simulating trusted runtimes, or replaying environment metadata. The environment safety check performs full-spectrum validation, including identity verification, transport-path integrity, and attestation authenticity. The composite PASS/FAIL verdict ensures that spoofed environments cannot satisfy all trust conditions. Any inconsistency results in a FAIL verdict and mandatory BitDrop. By requiring complete trust across all dimensions, SDLP eliminates exploit surfaces associated with partial validation or permissive fallback behavior. 7. Security Considerations The SDLP security architecture is designed to provide complete, physics-layer enforcement of trust, provenance, lineage, and environment validation. Because SDLP objects secure themselves, the security of the system depends on correct implementation of the physics layer and strict adherence to the PASS/FAIL trust model. SDLP objects MUST perform the environment safety check before any operation is permitted. Failure in any trust dimension MUST result in a FAIL verdict and mandatory BitDrop. Implementations that attempt to bypass, weaken, or modify this behavior introduce exploitable vulnerabilities and are non-compliant with this specification. Distributors MUST ensure that lineage identifiers, provenance anchors, and decay rules are correctly generated and cryptographically protected. Environments that host SDLP objects MUST support physics- layer enforcement, including tamper detection, attestation verification, and BitDrop capability. Because SDLP objects do not operate in partial trust states, any environment incapable of full-spectrum validation will result in a FAIL verdict. Implementers MUST ensure that trusted environments provide complete support for SDLP physics to avoid unintended termination. The SDLP security model assumes that attackers may attempt piracy, tampering, environment spoofing, or unauthorized redistribution. These threats are mitigated only when the physics layer is fully implemented and all enforcement rules are applied consistently. 8. IANA Considerations This document has no IANA actions. No registries are created or modified by this specification, and no protocol parameters require assignment. SDLP operates entirely within the physics-layer enforcement model and does not introduce values that require coordination through IANA. 9. References 9.1. 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. 9.2. Informative References [C2PA] Coalition for Content Provenance and Authenticity, "C2PA Specification", Version 2.0, 2024. [MovieLabs] MovieLabs, "Enhanced Content Protection Specification", 2023. [W3C-VC] Sporny, M., Longley, D., Chadwick, D., et al., "Verifiable Credentials Data Model v2.0", W3C Recommendation, 2023. [W3C-PROV] Moreau, L., Groth, P., "PROV-DM: The PROV Data Model", W3C Recommendation, 2013. [TEE] Sabt, M., Achemlal, M., Bouabdallah, A., "Trusted Execution Environments: A Survey", IEEE Communications Surveys & Tutorials, 2015. [Attestation] Intel Corporation, "Intel SGX Remote Attestation Technical Overview", 2022. [Watermarking] Cox, I., Miller, M., Bloom, J., Fridrich, J., Kalker, T., "Digital Watermarking and Steganography", Morgan Kaufmann, 2007. [SDLP-ARCH] Norton, M., "SDLP Architecture (SDLP RFC 1)", draft-norton-sdlp-arch-xx, Work in Progress. [SDLP-ID] Norton, M., "SDLP Identity Model (SDLP RFC 2)", draft-norton-sdlp-identity-xx, Work in Progress. [SDLP-LINEAGE] Norton, M., "SDLP Lineage and Object Format (SDLP RFC 3)", draft-norton-sdlp-lineage-xx, Work in Progress. Author's Address M. Norton Independent Protocol Architect El Mirage, Arizona United States Email: mark433norton@gmail.com