SDLP Security Architecture (SDLP RFC 4)
draft-norton-sdlp-sec-arch-02

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