Digital Signing of Physical Items Protocol (DSPIP)

Internet-Draft	DSPIP	January 2026
Boell	Expires 17 July 2026	[Page]

Abstract

This document specifies the Digital Signing of Physical Items Protocol (DSPIP), a cryptographic protocol for authenticating physical items using digitally signed QR codes. This specification focuses on the SHIP type for shipping and logistics applications, providing cryptographic authentication of packages with chain of custody tracking.¶

The protocol introduces privacy-preserving delivery mechanisms including encrypted recipient information, last mile provider selection, physical anti-cloning protections through split-key labels, and scalable revocation and delivery confirmation systems. DSPIP uses DNS-based public key distribution similar to DKIM and supports optional blockchain integration for immutable record keeping. While this specification focuses on shipping applications, the protocol includes a type field to enable future expansion to other use cases.¶

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 17 July 2026.¶

1. Introduction

Supply chain logistics require verifiable proof of package authenticity, chain of custody, and delivery confirmation. Current shipping systems rely on proprietary tracking databases with varying security models and no cryptographic verification of package authenticity or delivery. QR codes on shipping labels can be easily copied, leading to fraud and misdirection of packages.¶

DSPIP provides a cryptographic protocol specifically designed for shipping and logistics, enabling verification of package origin, custody chain, and delivery while protecting recipient privacy. The protocol addresses the fundamental challenge of QR code cloning through physical binding mechanisms and provides privacy-preserving delivery that reveals recipient information only to authorized last mile providers.¶

By using the secp256k1 elliptic curve, DSPIP keys are compatible with major blockchain networks, allowing optional integration for immutable custody records while not requiring blockchain for basic operation. The protocol includes a type field set to "SHIP" for this specification, enabling future expansion to other applications.¶

The design goals for DSPIP shipping protocol are:¶

Cryptographic Authentication: Verify package origin and integrity through digital signatures¶
Privacy Preservation: Protect recipient information during transit through encryption¶
Anti-Cloning: Prevent QR code duplication through physical binding mechanisms¶
Decentralized Verification: No central authority required for package validation¶
Offline Capable: Verification possible without network connectivity¶
Delivery Confirmation: Cryptographic proof of successful delivery¶
Scalable Operations: Support high-volume shipping with efficient revocation and confirmation systems¶
Standards Compliant: Integrate with existing logistics systems and standards¶
Cost Effective: Near-zero marginal cost per package authenticated¶
Blockchain Optional: Can integrate with blockchain but operates independently¶

DSPIP follows a "digital envelope" paradigm for shipping labels:¶

Envelope exterior (publicly readable): Sender identity, last mile provider destination, tracking number, and timestamp are encoded but not encrypted. This functions like the address on a physical envelope.¶
Signature (authenticity seal): A cryptographic signature proves the label was created by the claimed sender and has not been tampered with, similar to a shipping seal.¶
Private contents (encrypted): The actual recipient address and delivery instructions are encrypted for the last mile provider, like the contents of a sealed package that only the authorized recipient can access.¶

This model protects recipient privacy while maintaining package routability and authenticity verification.¶

3. Relationship to Existing Standards

DSPIP builds upon established standards while introducing novel shipping-specific features:¶

Standards This Document Builds Upon:¶

[RFC6376] (DKIM): DSPIP adopts DKIM's DNS-based public key distribution model for shipping providers¶
[RFC8017] (PKCS #1): Uses established cryptographic specifications¶
[ISO18004]: Utilizes QR code standards for label encoding¶
[SEC2]: Employs secp256k1 curve specifications (same curve as used by Bitcoin [Bitcoin] and Ethereum [Ethereum])¶
[ECIES]: Elliptic Curve Integrated Encryption Scheme for recipient privacy¶
[Ed25519]: For split-key label authentication¶

Related Shipping Standards:¶

[GS1-EPCIS]: DSPIP adds cryptographic authentication to event- based visibility¶
[EDI856] (ASN): DSPIP enables verification without central database¶
Last Mile Standards: DSPIP adds encrypted routing for privacy¶

Novel Contributions:¶

Privacy-Preserving Delivery: Encrypted recipient information with last mile provider routing¶
Physical Anti-Cloning: Split-key labels with destructive reveal prevent QR code duplication¶
Cryptographic Proof of Delivery: Challenge-response confirmation without key exposure¶
Scalable Confirmation Systems: Bulk revocation and delivery lists for high-volume operations¶

4. Protocol Overview

4.1. Data Flow

The DSPIP shipping protocol flow consists of the following steps:¶

Payload Creation: Sender creates a JSON payload containing sender information, last mile provider or recipient, tracking number, and timestamp¶
Privacy Selection: Choose privacy mode (standard, encrypted, or split-key) based on security requirements¶
Recipient Encryption: For privacy modes, encrypt recipient information with last mile provider's public key¶
Encoding: Payload is Base64 encoded to ensure consistent handling¶
Signing: Sender signs the data using their private key (or label's private key for split-key mode)¶
QR Generation: Complete data structure is serialized and encoded as a QR code¶
Label Application: QR code is printed on shipping label and attached to package¶
Transit Scanning: Carriers scan QR code at each custody transfer point¶
DNS Lookup: Scanner queries DNS TXT record to retrieve public key¶
Verification: Scanner verifies signature (or requests Zone B reveal for split-key)¶
Privacy Decryption: Last mile provider decrypts recipient information using their private key¶
Delivery: Package delivered to actual recipient address¶
Confirmation: Cryptographic proof of delivery recorded¶
Optional Blockchain: Custody chain recorded for audit trail¶

4.2. Protocol Workflow

+--------+                    +----------+              +---------+
| Sender |                    | Carrier  |              |Recipient|
+--------+                    +----------+              +---------+
    |                              |                        |
    | 1. Create Shipping Payload   |                        |
    |    {sender, provider,        |                        |
    |     trackingId, timestamp}   |                        |
    |                              |                        |
    | 2. Select Privacy Mode       |                        |
    | 3. Encrypt Recipient         |                        |
    | 4. Base64 Encode             |                        |
    | 5. Sign with Private Key     |                        |
    | 6. Generate QR Code          |                        |
    | 7. Attach Label to Package   |                        |
    |==============================|========================|
    |                    8. Scan QR Code                    |
    |                    9. Parse Data                      |
    |                   10. DNS Lookup                      |
    |                   11. Verify Signature                |
    |                   12. Check Revocation                |
    |                   13. Decrypt Recipient               |
    |                   14. Deliver Package                 |
    |                         |=========================>   |
    |                   15. Delivery Confirmation           |
    |                         |<========================    |
    |                   16. Record Proof                    |

Figure 1: DSPIP Shipping Flow

5. Data Formats

5.1. Payload Structure

The payload contains shipping information encoded as JSON. Country codes use [ISO3166] alpha-2 format:¶

{
  "type": "SHIP",               // REQUIRED: Fixed for shipping
  "issuer": {                   // REQUIRED: Sender information
    "name": "string",
    "organization": "string",
    "address": {
      "street1": "string",
      "city": "string",
      "state": "string",
      "postalCode": "string",
      "country": "string"       // REQUIRED: per ISO3166 alpha-2
    }
  },
  "subject": {                  // REQUIRED: Recipient/Provider
    "name": "string",
    "lastMileProvider": "string",
    "address": { ... }
  },
  "itemId": "string",           // REQUIRED: Tracking number
  "timestamp": number,          // REQUIRED: Unix timestamp (ms)
  "typeData": {}                // SHIP-specific fields
}

5.2. SHIP Type Payload Fields

The typeData object contains shipping-specific information including privacy mode, carrier details, customs information, and delivery confirmation settings.¶

5.3. Privacy Modes

DSPIP supports three privacy modes for shipping:¶

5.3.1. Standard Mode (Legacy)

Traditional shipping with full recipient information visible.¶

5.3.2. Encrypted Mode

Privacy-preserving with encrypted recipient data. The recipient's address and delivery instructions are encrypted with the last mile provider's public key.¶

5.3.3. Split-Key Mode

Maximum security with physical anti-cloning. Uses Ed25519 keys printed in separate scratch-off zones on the physical label.¶

5.4. QR Data Structure

The complete QR code data structure contains:¶

protocol: Fixed string "DSPIP"¶
version: Semantic version string ("1.0")¶
type: Fixed to "SHIP" for this specification¶
keyLocator: DNS path for public key lookup¶
encodedPayload: Base64-encoded JSON payload¶
signature: Hex-encoded ECDSA signature¶
privateMessage: Optional Base64-encoded encrypted message¶

5.5. Serialization Format

QR data MUST be serialized using pipe (|) delimiters:¶

DSPIP|<version>|<type>|<keyLocator>|<payload>|<sig>[|<msg>]

The pipe delimiter was chosen for its low frequency in Base64 and domain names. Implementations MUST validate that exactly 6 or 7 pipe-delimited fields are present.¶

6. DNS Key Distribution

DSPIP uses DNS TXT records for public key distribution, following the model established by DKIM [RFC6376].¶

6.1. Key Locator Format

Key locators MUST follow this pattern:¶

<selector>._dspip.<domain>

Where selector is a unique identifier for the specific key, _dspip is the fixed protocol subdomain (underscore prefix per [RFC8552]), and domain is the organization's domain name.¶

6.2. DNS TXT Record Format

The DNS TXT record MUST contain a semicolon-separated list of tag=value pairs:¶

v=DSPIP1; k=ec; c=secp256k1; p=<base64_public_key>; [optional]

Required tags: v (protocol version), k (key type), c (curve identifier), p (public key in Base64).¶

Optional tags: t (creation timestamp), x (expiration), n (notes), types, auth, address, coverage.¶

6.2.1. Address Field Format

The address field specifies the physical location of signing facilities using scheme prefixes:¶

plus: (DEFAULT) Open Location Code / Plus Code¶
street: Percent-encoded street address per [RFC3986]¶
geo: Geographic coordinates (latitude,longitude)¶
facility: Named facility reference¶

If no scheme prefix is present, implementations MUST interpret the value as a Plus Code. See [PLUSCODE] for the Open Location Code specification.¶

6.3. Selector Discovery

Organizations MAY publish a discovery record at the base _dspip subdomain to enable discovery of available selectors.¶

6.4. Key Lifecycle Management

DSPIP keys have a defined lifecycle to ensure security while maintaining verification capability for in-transit packages.¶

Keys transition through states: Active (can sign and verify), Verify-Only (can only verify), and Expired (invalid).¶

For shipping applications, the RECOMMENDED key lifetime is: Active signing period of 365 days, verify-only period of 365 additional days, for a total key lifetime of 730 days (2 years).¶

6.4.1. Record Signature (rsig)

The rsig field provides cryptographic authentication of lifecycle metadata within the DNS record itself, protecting against unauthorized modification by intermediate DNS resolvers.¶

6.5. Key Revocation

When a signing key is compromised or must be retired, organizations MUST have a mechanism to inform verifiers. The key revocation record provides a dedicated endpoint for key status.¶

6.6. Package Revocation

Individual packages may need to be revoked due to loss, theft, or fraud. DSPIP provides individual revocation records and bulk revocation lists for scalability.¶

Lists MUST be served over HTTPS and SHOULD auto-prune entries older than 180 days. Lists MAY use [BLOOM] filters for privacy.¶

6.7. Delivery Confirmation Distribution

Last mile providers MAY publish delivery confirmations via DNS TXT records pointing to confirmation endpoints.¶

7. Cryptographic Operations

7.1. Key Generation

DSPIP uses the secp256k1 elliptic curve as specified in [SEC2]:¶

Curve: secp256k1¶
Private key: 256 bits (32 bytes)¶
Public key: 264 bits (33 bytes compressed)¶

For split-key labels, [Ed25519] is used with 256-bit keys.¶

7.2. Signature Creation

Standard signature using ECDSA:¶

Construct signable content: signable = protocol | version | type | keyLocator | payload¶
Calculate SHA-256 hash of signable content¶
Sign hash using ECDSA with private key¶
Encode signature in DER format¶
Convert to hexadecimal string¶

7.3. Signature Verification

Standard verification reconstructs signable content, calculates SHA-256 hash, retrieves public key from DNS, and verifies ECDSA signature.¶

Split-key verification requires Zone B reveal and uses Ed25519 verification without DNS lookup.¶

8. Verification Process

8.1. Verification Algorithm

Input: QR code data string. Output: Verification result with validity status.¶

PARSE: Split QR data by pipe delimiter, validate 6 or 7 fields present¶
VALIDATE PROTOCOL: Protocol MUST equal "DSPIP", Version MUST be compatible, Type MUST equal "SHIP"¶
DECODE PAYLOAD: Base64 decode and parse JSON¶
DNS LOOKUP: Query DNS TXT record for keyLocator¶
VERIFY SIGNATURE: Verify with public key¶
PRIVACY DECRYPTION: Decrypt encryptedRecipient if last mile provider¶
REVOCATION CHECK: Query revocation list¶
OPTIONAL BLOCKCHAIN: Record custody transfer¶

8.2. Privacy-Preserving Delivery Protocol

The privacy-preserving delivery protocol protects recipient information during transit through ECIES encryption with the last mile provider's public key.¶

Recipients are encrypted using ECIES over secp256k1 per [ECIES]:¶

Generate ephemeral key pair (r, R = rG)¶
Compute shared secret: S = r * LastMilePublicKey¶
Derive encryption key: K = KDF(S || R) using [SHA256]¶
Encrypt: C = AES-256-GCM(K, recipient_data) per [AES]¶
Output: R || C || tag¶

8.3. Physical Authentication via Split-Key Labels

Split-key labels provide physical anti-cloning through two scratch-off zones containing Ed25519 key material. Zone A contains the private key (revealed at label creation), Zone B contains the public key (revealed at delivery verification).¶

8.4. Delivery Confirmation Protocol

Cryptographic delivery confirmation uses challenge-response protocol where the recipient proves possession of their verification key.¶

9. Security Considerations

DSPIP addresses the following shipping-specific threats:¶

Package Forgery: Mitigated through cryptographic signatures¶
QR Code Cloning: Prevented through split-key labels¶
Recipient Privacy Breach: Protected through encryption¶
Delivery Fraud: Cryptographic proof prevents false claims¶
Package Tampering: Signatures detect modifications¶
Replay Attacks: Unique tracking IDs prevent reuse¶
Man-in-the-Middle: DNSSEC protects key lookups¶
Tracking Attacks: Privacy modes prevent correlation¶

Shipping keys SHOULD use hardware security modules. Last mile providers MUST secure decryption keys. Organizations SHOULD rotate keys annually.¶

Use encrypted mode for consumer deliveries. Limit address fields to necessary information. Comply with [GDPR] where applicable.¶

Package revocation for lost/stolen items through individual records or bulk lists. SHIP entries expire after 180 days.¶

Label manufacturing requires secure facilities, audit trails, no retention of private keys, and tamper-evident packaging.¶

10. IANA Considerations

This document requests IANA to register the following:¶

Registration of "_dspip" in the "Underscored and Globally Scoped DNS Node Names" registry per [RFC8552]¶
Reservation of "DSPIP" as a protocol identifier¶
Registration of DSPIP-specific DNS TXT record tags¶
Creation of DSPIP Type Registry with initial value SHIP¶
Creation of DSPIP Privacy Mode Registry (standard, encrypted, split-key)¶
Creation of DSPIP Authentication Profile Registry¶
Creation of DSPIP Key Revocation Reason Registry¶
Creation of DSPIP Item Revocation Reason Registry¶
Creation of DSPIP Delivery Confirmation Type Registry¶
Creation of DSPIP Key Status Registry¶
Creation of DSPIP Delegation Scheme Registry¶
Creation of DSPIP Address Scheme Registry¶

11. Normative References

[ECIES]: Gayoso Martinez, V., Hernandez Encinas, L., and C. Sanchez Avila, "A Survey of the Elliptic Curve Integrated Encryption Scheme", Journal of Computer Science and Engineering, Volume 2, Issue 2, August 2010.
[Ed25519]: Bernstein, D., "High-speed high-security signatures", Journal of Cryptographic Engineering, Volume 2, pp 77-89, DOI 10.1007/s13389-012-0027-1, September 2012, <https://doi.org/10.1007/s13389-012-0027-1>.
[RFC2119]: Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.
[RFC3986]: Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, DOI 10.17487/RFC3986, January 2005, <https://www.rfc-editor.org/info/rfc3986>.
[RFC6376]: Crocker, D., Ed., Hansen, T., Ed., and M. Kucherawy, Ed., "DomainKeys Identified Mail (DKIM) Signatures", STD 76, RFC 6376, DOI 10.17487/RFC6376, September 2011, <https://www.rfc-editor.org/info/rfc6376>.
[RFC8174]: Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8552]: Crocker, D., "Scoped Interpretation of DNS Resource Records through "Underscored" Naming of Attribute Leaves", BCP 222, RFC 8552, DOI 10.17487/RFC8552, March 2019, <https://www.rfc-editor.org/info/rfc8552>.
[SEC2]: Standards for Efficient Cryptography Group, "SEC 2: Recommended Elliptic Curve Domain Parameters", Version 2.0, January 2010, <https://www.secg.org/sec2-v2.pdf>.

12. Informative References

[AES]: National Institute of Standards and Technology, "Advanced Encryption Standard (AES)", FIPS PUB 197, November 2001.
[Bitcoin]: Nakamoto, S., "Bitcoin: A Peer-to-Peer Electronic Cash System", 2008, <https://bitcoin.org/bitcoin.pdf>.
[BLOOM]: Bloom, B., "Space/Time Trade-offs in Hash Coding with Allowable Errors", Communications of the ACM, Volume 13, Issue 7, pp 422-426, July 1970.
[EDI856]: X12, "Ship Notice/Manifest Transaction Set", ASC X12 Standard EDI 856, 2020.
[Ethereum]: Buterin, V., "Ethereum: A Next-Generation Smart Contract and Decentralized Application Platform", 2014, <https://ethereum.org/whitepaper/>.
[GDPR]: European Parliament and Council, "Regulation (EU) 2016/679 (General Data Protection Regulation)", April 2016.
[GS1-EPCIS]: GS1, "EPCIS (Electronic Product Code Information Services) Standard", Version 2.0, 2022, <https://www.gs1.org/standards/epcis>.
[ISO18004]: ISO/IEC, "Information technology - Automatic identification and data capture techniques - QR Code bar code symbology specification", ISO/IEC 18004:2015, 2015.
[ISO3166]: ISO, "Codes for the representation of names of countries and their subdivisions", ISO 3166-1:2020, 2020.
[PLUSCODE]: Google, "Open Location Code (Plus Codes)", <https://github.com/google/open-location-code>. An open-source system for encoding geographic coordinates into a compact, URL-safe string.
[RFC8017]: Moriarty, K., Ed., Kaliski, B., Jonsson, J., and A. Rusch, "PKCS #1: RSA Cryptography Specifications Version 2.2", RFC 8017, DOI 10.17487/RFC8017, November 2016, <https://www.rfc-editor.org/info/rfc8017>.
[SHA256]: National Institute of Standards and Technology, "Secure Hash Standard (SHS)", FIPS PUB 180-4, August 2015.

Appendix A. Test Vectors

A.1. Test Key Pair

Private Key (hex):¶

e8f32e723decf4051aefac8e2c93c9c5b214313817cdb01a1494b917c8436b35

Public Key Compressed (hex):¶

0339a36013301597daef41fbe593a02cc513d0b55527ec2df1050e2e8ff49c85c2

Public Key Base64 (for DNS):¶

AzmjYBMwFZfa70H75ZOgLMUT0LVVJ+wt8QUOLo/0nIXC

A.2. Standard Mode Shipping

Payload:¶

{
  "type": "SHIP",
  "issuer": {
    "organization": "ACME Logistics",
    "address": {"city": "Omaha", "state": "NE", "country": "US"}
  },
  "subject": {
    "name": "Bob Jones",
    "address": {
      "street1": "456 Main Street",
      "city": "Lincoln",
      "state": "NE",
      "postalCode": "68501",
      "country": "US"
    }
  },
  "itemId": "TRACK-2025-000123",
  "timestamp": 1703548800000,
  "typeData": {
    "privacyMode": "standard",
    "parcelId": "TRACK-2025-000123",
    "carrier": "ACME",
    "service": "Ground"
  }
}

Signature (DER-encoded ECDSA/secp256k1, hex):¶

30440220250f55bf60f3f82031677d17e6202fbf12e31b9ce8d1541e287e1fdd8
ce40a41022056ef5cd183a674c4f5fdc5e0cac1dcfd386de2e7d505681f83104e
2b1f53a315

A.3. Privacy Mode Shipping

Recipient data (to be encrypted):¶

{
  "recipientName": "Bob Jones",
  "address": {
    "street1": "456 Main Street",
    "apartment": "4B",
    "city": "Lincoln",
    "state": "NE",
    "postalCode": "68501"
  },
  "deliveryInstructions": "Use back door, code 4321"
}

A.4. Split-Key Mode

Label Serial: LABEL-2025-ABC123¶

Zone A Private Key (Ed25519, hex):¶

9d61b19deffd5a60ba844af492ec2cc44449c5697b326919703bac031cae7f60

Zone B Public Key (Ed25519, hex):¶

d75a980182b10ab7d54bfed3c964073a0ee172f3daa62325af021a68f707511a

Signature (Ed25519, hex):¶

1fb94d499a504e201433d0e783906a013e26c21daca3ab8c5ad1e9fcf73a1c58
c9ed3abd60802f3abaac01d35bada76ab1bf571ca1641b8d3ea62f7468fbef0f

A.5. DNS TXT Records

Warehouse:¶

warehouse._dspip.example.com. IN TXT "v=DSPIP1; k=ec; c=secp256k1;
  p=AzmjYBMwFZfa70H75ZOgLMUT0LVVJ+wt8QUOLo/0nIXC; types=SHIP"

A.6. Revocation List

{
  "version": "1.0",
  "issuer": "warehouse._dspip.example.com",
  "updated": 1703548800,
  "revoked": [
    {
      "itemId": "TRACK-2025-000123",
      "revoked": 1703548900,
      "reason": "lost"
    }
  ],
  "signature": "base64_signature"
}