Digital Signing of Physical Items Protocol (DSPIP)

Digital Signing of Physical Items Protocol (DSPIP) Midwest Cyber LLC

1022 Brickyard Dr Hooper NE 68031 United States of America contact@dspip.io https://dspip.io

Security Internet Engineering Task Force digital-signature shipping qr-code cryptography dns pki 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.

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.

Requirements Language 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 when, and only when, they appear in all capitals, as shown here.

Relationship to Existing Standards DSPIP builds upon established standards while introducing novel shipping-specific features: Standards This Document Builds Upon:

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

Related Shipping Standards:

: DSPIP adds cryptographic authentication to event- based visibility
(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

Protocol Overview

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

Protocol Workflow

Data Formats

Payload Structure The payload contains shipping information encoded as JSON. Country codes use alpha-2 format:

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

Privacy Modes DSPIP supports three privacy modes for shipping:

Standard Mode (Legacy) Traditional shipping with full recipient information visible.

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.

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

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

Serialization Format QR data MUST be serialized using pipe (|) delimiters: ||||[|] ]]> 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.

DNS Key Distribution DSPIP uses DNS TXT records for public key distribution, following the model established by DKIM .

Key Locator Format Key locators MUST follow this pattern: ._dspip. ]]> Where selector is a unique identifier for the specific key, _dspip is the fixed protocol subdomain (underscore prefix per ), and domain is the organization's domain name.

DNS TXT Record Format The DNS TXT record MUST contain a semicolon-separated list of tag=value pairs: ; [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.

Address Field Format The address field specifies the physical location of signing facilities, primarily for last mile providers. This enables verifiers to display facility location on shipping labels for encrypted privacy mode, where the recipient address is hidden. The address field uses a scheme prefix to indicate the encoding:

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

If no scheme prefix is present, implementations MUST interpret the value as a Plus Code (plus: scheme).

Plus Code Scheme (Default) Plus Codes (Open Location Codes) are the RECOMMENDED addressing scheme due to their compact representation, open standard licensing, and global coverage. Format: address=plus:<plus_code> Short form: address=<plus_code> Examples: Plus Codes are 10-11 characters for full precision or 6-7 characters when combined with a locality reference. See for the Open Location Code specification.

Street Address Scheme Traditional street addresses encoded using percent-encoding per . Format: address=street:<percent_encoded_address> Examples: Street addresses SHOULD include city and postal code for clarity.

Geographic Coordinate Scheme Decimal latitude and longitude coordinates. Format: address=geo:<latitude>,<longitude> Examples: Coordinates MUST use decimal degrees with negative values for South and West. Precision SHOULD be at least 4 decimal places (~11 meter accuracy).

Facility Reference Scheme Named facility reference for organizations with published facility directories. Format: address=facility:<facility_id> Examples: Facility references require external directory lookup. Organizations using this scheme SHOULD publish facility directories at a well-known location or via the discovery record.

Address Field Requirements

The address field is OPTIONAL for key records
Last mile providers SHOULD include address for encrypted mode label display
Implementations SHOULD prefer Plus Codes for new deployments
Verifiers MUST support all four schemes
When displaying addresses, verifiers MAY render Plus Codes as clickable links to mapping services

Selector Discovery To enable discovery of available selectors for a domain, organizations MAY publish a discovery record at the base _dspip subdomain.

Discovery Record Format Discovery record tags:

v: Protocol version (MUST be "DSPIP1")
type: Record type (MUST be "discovery" for discovery records)
selectors: Comma-separated list of available selectors
delegation: Delegation scheme for selector organization

Delegation Schemes The delegation tag indicates how selectors are organized:

list: Explicit enumeration in selectors field
geo: Geographic prefixes (e.g., us-west, eu-central)
postal: Postal code prefixes (e.g., 68_, 90_)
region: Regional identifiers (e.g., midwest, northeast)
service: Service-based selectors (e.g., express, ground)

Examples: -" Postal code delegation: _dspip.usps.example. IN TXT "v=DSPIP1; type=discovery; delegation=postal; pattern=; coverage=00000-99999" ]]>

Discovery Requirements

Discovery records are OPTIONAL
Verifiers SHOULD NOT require discovery records for verification
Discovery records SHOULD be cached according to DNS TTL
Implementations MAY use discovery for user interfaces and directory services

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

Key Record Fields The DNS TXT record supports the following lifecycle fields: Required fields:

v: Protocol version (MUST be "DSPIP1")
k: Key type (MUST be "ec")
c: Curve identifier (MUST be "secp256k1")
p: Public key in Base64 encoding

SHOULD include:

t: Key creation timestamp (Unix time). If omitted, verifiers SHOULD treat the key as valid from an indefinite past.
exp: Signing expiration timestamp (Unix time). After this time, the key MUST NOT be used to sign new items. If omitted, the key has no signing expiration.

MAY include:

exp-v: Verification expiration timestamp (Unix time). After this time, the key MUST NOT be used to verify any signatures. If omitted, defaults to exp value (if present) or no expiration.
s: Key status. Values: "active" (default if omitted), "verify-only" (can verify but not sign), "revoked" (completely invalid).
seq: Sequence number for key updates. Higher values supersede lower values for the same selector.
n: Human-readable notes (percent-encoded)

Key Lifecycle States Keys transition through the following states:

Active: Key can sign new items and verify existing signatures. Status: s=active (or omitted), current time < exp
Verify-Only: Key cannot sign new items but can verify existing signatures. Status: s=verify-only, or exp < current time < exp-v
Expired: Key is completely invalid and MUST NOT be used. Status: s=revoked, or current time > exp-v

Recommended Key Lifetime For shipping applications, the following key lifetime is RECOMMENDED:

Active signing period: 365 days (1 year)
Verify-only period: 365 additional days (1 year)
Total key lifetime: 730 days (2 years)

This provides sufficient time for packages to complete transit (typically 1-30 days) while limiting exposure from compromised keys. Example DNS record with lifecycle fields:

Key Rotation Organizations SHOULD implement key rotation:

Generate new key before current key's exp timestamp
Publish new key with incremented seq value
Transition signing to new key
Maintain old key for verification until exp-v
Remove old key after exp-v passes

Field Omission Semantics When lifecycle fields are omitted, verifiers MUST apply these rules:

t omitted: Key has no creation date constraint
exp omitted: Key has no signing expiration (signs indefinitely)
exp-v omitted: Defaults to exp value; if exp also omitted, key verifies indefinitely
s omitted: Key is "active"
seq omitted: Treated as seq=0; cannot supersede keys with seq > 0

Note: While omitting fields is permitted for backwards compatibility, implementations SHOULD include t, exp, and exp-v for production keys to enable proper lifecycle management.

Record Signature (rsig) The rsig field provides cryptographic authentication of lifecycle metadata within the DNS record itself. This protects against unauthorized modification of lifecycle fields (t, exp, exp-v, s, seq) by intermediate DNS resolvers or caches.

Threat Model Without rsig, an attacker with access to an intermediate DNS resolver or cache could modify lifecycle fields without invalidating QR code signatures. For example:

Extending exp to hide that a key has expired
Changing s=revoked to s=active to hide key compromise
Modifying seq to prevent key rotation from taking effect

The rsig field allows verifiers to detect such modifications by checking a signature over the lifecycle metadata.

Signable Content The rsig signature covers a canonical string of lifecycle fields: Where:

selector: The selector portion of the key locator (e.g., "warehouse")
t: Creation timestamp as decimal string, or empty if omitted
exp: Signing expiration as decimal string, or empty if omitted
exp-v: Verification expiration as decimal string, or empty if omitted
s: Status value, or empty if omitted (defaults to "active")
seq: Sequence number as decimal string, or empty if omitted

Example signable content: "warehouse|1703548800|1735084800|1766620800|active|1"

Signature Generation The rsig value is generated as follows:

Construct the signable content string as defined above
Compute SHA-256 hash of the UTF-8 encoded signable content
Sign the hash using ECDSA with the same private key that corresponds to the public key in the p= field
Encode the signature in Base64

The same key signs both QR codes and the rsig, providing proof that the key owner authorized the lifecycle metadata.

Verification Process When rsig is present, verifiers SHOULD:

Extract the rsig value from the DNS record
Reconstruct the signable content from the record's lifecycle fields
Compute SHA-256 hash of the signable content
Verify the rsig signature using the public key from the p= field
If verification fails, treat the record as untrusted

Requirements

rsig is OPTIONAL for DNS records
When rsig is present, verifiers SHOULD verify it
If rsig verification fails, verifiers SHOULD reject the record or flag it with a LIFECYCLE_UNVERIFIED warning
Implementations MAY operate in "rsig-required" mode for high-security deployments
rsig provides defense-in-depth; DNSSEC provides stronger guarantees when available

Relationship to DNSSEC DNSSEC and rsig serve complementary purposes:

DNSSEC: Zone owner signs all records; proves record came from authoritative zone
rsig: Key owner signs lifecycle metadata; proves the signing key holder authorized the lifecycle values

For maximum security, deployments SHOULD use both DNSSEC and rsig. DNSSEC alone is sufficient if the organization controls their DNS infrastructure end-to-end.

Key Revocation When a signing key is compromised or must be retired, organizations MUST have a mechanism to inform verifiers that the key should no longer be trusted. While the s=revoked status in the key record provides this capability, DNS caching can delay propagation. The key revocation record provides a dedicated, frequently-checked endpoint for key status that operates independently of key record caching.

Key Revocation Record Format Fields:

v: Protocol version (MUST be "DSPIP1")
type: Record type (MUST be "key-revocation")
selector: The selector of the revoked key (REQUIRED)
revoked: Unix timestamp when the key was revoked (REQUIRED)
reason: Reason for revocation (REQUIRED). Values: compromised (private key was exposed or stolen), retired (key reached end of lifecycle), superseded (key replaced by newer key), suspended (temporarily disabled, may be reactivated)
replacement: Selector of the replacement key (OPTIONAL)

Multiple Key Revocations Organizations with multiple revoked keys MAY use multiple TXT records or a bulk format:

Verifier Requirements for Key Revocation Verifiers MUST check key revocation status before trusting signatures:

Query _revoked-key._dspip.<domain> with minimal or no caching
If the key's selector appears in the revocation record(s), REJECT the signature immediately
Key revocation takes precedence over s=active in the key record
Verifiers SHOULD use short TTLs (60-300 seconds) when caching key revocation records
For high-security deployments, verifiers MAY query key revocation on every verification without caching

Relationship to Key Record Status The s (status) field in key records and _revoked-key records serve complementary purposes:

s=revoked in key record: Authoritative status, but subject to DNS caching delays
_revoked-key record: Dedicated revocation channel with shorter cache lifetime for faster propagation

Organizations SHOULD update both when revoking a key:

Publish _revoked-key record (immediate propagation)
Update key record with s=revoked (authoritative status)

Verifiers MUST treat a key as revoked if EITHER indicates revocation.

Package Revocation Individual packages may need to be revoked due to loss, theft, or fraud without revoking the signing key. DSPIP provides two mechanisms for package revocation.

Individual Package Revocation Record For low-volume revocations, organizations MAY publish individual revocation records directly in DNS: Fields:

v: Protocol version (MUST be "DSPIP1")
type: Record type (MUST be "item-revocation")
itemId: The revoked package identifier (REQUIRED)
revoked: Unix timestamp when the package was revoked (REQUIRED)
reason: Reason for revocation (REQUIRED). Values: lost (package lost in transit), stolen (package was stolen), damaged (package damaged and reshipped), recalled (package recalled by sender), fraud (fraudulent QR code detected)
replacementId: New itemId for reshipped package (OPTIONAL)

Bulk Package Revocation For scalability, senders MAY publish bulk revocation lists:

Revocation Pointer Record

Revocation List Format Bloom filter format (for privacy):

Revocation Requirements

Lists MUST be served over HTTPS
Lists SHOULD auto-prune entries older than 180 days
Lists MAY use filters for privacy
Verifiers SHOULD cache lists based on TTL

Revocation Freshness To ensure timely revocation detection, revocation records MUST NOT be cached indefinitely. The revocation list format includes freshness fields: Freshness field semantics:

ts: Unix timestamp when the revocation list was generated. MUST be present. Verifiers MUST reject lists where current_time - ts exceeds max-age.
max-age: Maximum age in seconds before the list must be refreshed. MUST be present. Recommended values: 300-900 seconds (5-15 min) for active verification, up to 3600 seconds (1 hour) for background checks.

Verifier requirements:

Verifiers MUST check ts + max-age > current_time before using a cached revocation list
Verifiers MUST refresh revocation lists when max-age expires
Verifiers SHOULD NOT serve stale revocation data to end users
Verifiers MAY implement background refresh to maintain fresh data

Note: These freshness requirements apply to revocation lists only. Key records follow standard DNS TTL caching semantics.

Delivery Confirmation Distribution Last mile providers MAY publish delivery confirmations:

Delivery Confirmation Pointer

Delivery Confirmation Format

Callback Mechanism Senders MAY specify callback URLs for real-time confirmation: Callback payload:

Cryptographic Operations

Key Generation DSPIP uses the secp256k1 elliptic curve as specified in :

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

For split-key labels, is used with 256-bit keys.

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

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.

Verification Process

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

Privacy-Preserving Delivery Protocol The privacy-preserving delivery protocol protects recipient information during transit.

Protocol Overview

Recipient Selection: At checkout, recipient selects their preferred last mile provider (post office, corporate mailroom, residential carrier)
Key Retrieval: System retrieves the last mile provider's public key from DNS or directory service
Encryption: Recipient's address and delivery instructions are encrypted with the last mile provider's public key
Label Creation: Shipping label shows only the last mile provider destination in cleartext
Transit: Package routes to last mile provider with encrypted recipient data
Decryption: Last mile provider decrypts recipient information using their private key
Final Delivery: Provider completes delivery to actual recipient
Confirmation: Cryptographic proof of delivery recorded

Last Mile Provider Registration Organizations register as last mile providers by publishing keys: Post office: Corporate mailroom:

Encryption Specification Recipients are encrypted using ECIES over secp256k1 per :

Generate ephemeral key pair (r, R = rG)
Compute shared secret: S = r * LastMilePublicKey
Derive encryption key: K = KDF(S || R) using
Encrypt: C = AES-256-GCM(K, recipient_data) per
Output: R || C || tag (R: ephemeral public key 33 bytes, C: ciphertext variable length, tag: authentication tag 16 bytes)

Organizational Hierarchies Large organizations MAY implement tiered decryption: Organization Master: mailroom._dspip.acmecorp.example

Decrypts all packages to organization
Routes internally based on decrypted data

Department Level: engineering._dspip.acmecorp.example

Department-specific packages only

Individual Level: john.doe._dspip.acmecorp.example

Personal packages only

Directory Services Vendors MAY use directory services to map addresses to providers: Request: Response:

Fallback Mechanism If decryption fails:

Provider attempts decryption -> Fails
Provider looks up sender from issuer field
Provider contacts sender with parcelId
Sender provides recipient information via secure channel
Delivery proceeds normally
Incident logged for audit

Customs Compliance For international shipping:

Physical Authentication via Split-Key Labels Split-key labels prevent QR code cloning through physical cryptographic binding.

Manufacturing Requirements Label producers MUST:

Generate unique key pairs using HSM
Use cryptographically secure random generation
Print using secure facilities
Use tamper-evident scratch-off material
Destroy all digital copies after printing
Never retain private keys
Maintain audit log of serial numbers

Split-Key Protocol MANUFACTURING:

Generate keypair (sk, pk) using
Print sk under Zone A (32 bytes hex)
Print pk under Zone B (32 bytes hex)
Destroy digital copies
Package in tamper-evident packaging

SENDER:

Purchase authenticated label
Verify label authenticity
Scratch Zone A -> reveal sk
Create payload with privacyMode = "split-key", authenticationProfile = "PHYSICAL-SPLIT-KEY", labelSerial = "LABEL-2025-ABC123"
Sign: signature = Sign_Ed25519(sk, payload)
Generate QR code
Apply to label
Destroy revealed sk

RECEIVER:

Receive package with intact Zone B
Scan QR -> extract payload + signature
Scratch Zone B -> reveal pk
Verify: Verify_Ed25519(pk, payload, signature)
If valid: Package authentic
If invalid: Package cloned/tampered

Security Properties This mechanism provides:

Clone Detection: Cloned QRs lack matching public keys
Tamper Evidence: Scratch-offs show if revealed
Non-transferable: Cannot move QR to different label
Offline Verification: No network required
Forward Secrecy: Private key destroyed after use

Anti-Cloning Analysis Attack: Copy QR to new package

-> No matching public key on new label
-> Verification fails

Attack: Copy entire label

-> Cannot manufacture same key pair
-> Different keys = verification fails

Attack: Intercept and re-sign

-> Private key already destroyed
-> Cannot create valid signature

Attack: Photograph public key area

-> Still need private key for forgery
-> Cannot create fake packages

Delivery Confirmation Protocol DSPIP supports cryptographic proof of delivery.

Challenge-Response Proof At delivery:

Carrier generates: challenge = nonce || parcelId || timestamp || location
Carrier presents challenge to recipient
Recipient signs: proof = Sign(recipient_key, challenge)
Carrier verifies proof
Carrier records the confirmation

Confirmation record format:

Single-Use Delivery Keys Recipients MAY generate ephemeral keys: At checkout: At delivery:

Proof Storage Delivery proofs are published:

Multi-Party Confirmation For high-value shipments:

Security Considerations

Threat Model 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

Key Management Private Key Protection:

Shipping keys SHOULD use hardware security modules
Last mile providers MUST secure decryption keys
Split-key labels provide one-time-use keys

Key Rotation:

Organizations SHOULD rotate keys annually
Old keys remain in DNS for verification
Emergency rotation procedures required

Key Revocation:

Compromised keys removed from DNS immediately
Affected packages reissued
Revocation lists updated

Privacy Considerations Data Minimization:

Use encrypted mode for consumer deliveries
Limit address fields to necessary information
Comply with where applicable

Privacy Modes:

Standard: Business shipments with transparency
Encrypted: Consumer privacy protection
Split-key: Maximum security for valuable items

Correlation Prevention:

Random tracking IDs
Limited timestamp precision
Different encryption per package

Revocation Mechanisms Package revocation for lost/stolen items: Individual records: Bulk lists: Auto-pruning:

SHIP entries expire after 180 days

Privacy option:

filters hide specific revoked items

Operational Security Label Manufacturing:

Secure facilities required
Audit trails for serial numbers
No retention of private keys
Tamper-evident packaging

Directory Services:

HTTPS required
Authentication for updates
Rate limiting
Cache poisoning prevention

Delivery Confirmation:

Time-bounded challenges
Location verification
Multi-party attestation for high value

IANA Considerations This document requests IANA to register the following:

Registration of "_dspip" in the "Underscored and Globally Scoped DNS Node Names" registry per
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

Normative References SEC 2: Recommended Elliptic Curve Domain Parameters Standards for Efficient Cryptography Group Version 2.0 A Survey of the Elliptic Curve Integrated Encryption Scheme Journal of Computer Science and Engineering, Volume 2, Issue 2 High-speed high-security signatures Journal of Cryptographic Engineering, Volume 2, pp 77-89 Informative References Information technology - Automatic identification and data capture techniques - QR Code bar code symbology specification ISO/IEC ISO/IEC 18004:2015 Codes for the representation of names of countries and their subdivisions ISO ISO 3166-1:2020 EPCIS (Electronic Product Code Information Services) Standard GS1 Version 2.0 Ship Notice/Manifest Transaction Set X12 ASC X12 Standard EDI 856 Bitcoin: A Peer-to-Peer Electronic Cash System Ethereum: A Next-Generation Smart Contract and Decentralized Application Platform Regulation (EU) 2016/679 (General Data Protection Regulation) European Parliament and Council Advanced Encryption Standard (AES) National Institute of Standards and Technology FIPS PUB 197 Secure Hash Standard (SHS) National Institute of Standards and Technology FIPS PUB 180-4 Open Location Code (Plus Codes) Google An open-source system for encoding geographic coordinates into a compact, URL-safe string. Space/Time Trade-offs in Hash Coding with Allowable Errors Communications of the ACM, Volume 13, Issue 7, pp 422-426

Test Vectors

Test Key Pair Private Key (hex): Public Key Compressed (hex): Public Key Base64 (for DNS):

Standard Mode Shipping Payload: Signature (DER-encoded ECDSA/secp256k1, hex):

Privacy Mode Shipping Recipient data (to be encrypted):

Split-Key Mode Label Serial: LABEL-2025-ABC123 Zone A Private Key (Ed25519, hex): Zone B Public Key (Ed25519, hex): Signature (Ed25519, hex):

DNS TXT Records Warehouse:

Revocation List

Implementation Guidelines

QR Code Generation Recommended settings:

Error correction level M (15%) for standard labels
Error correction level Q (25%) for split-key labels
Error correction level H (30%) for outdoor use
Automatic version selection
Binary encoding mode

Performance Benchmarks Expected operation times:

Key generation: 5-10 ms
Signature creation: 2-5 ms
DNS lookup: 20-100 ms (cacheable)
Signature verification: 3-8 ms
ECIES encryption: 10-20 ms
ECIES decryption: 10-20 ms

Caching Strategy

DNS Key Record Caching Key records follow standard DNS caching semantics:

Cache based on DNS TTL (recommended: 3600-86400 seconds)
Minimum recommended TTL: 300 seconds (5 minutes)
Maximum recommended TTL: 86400 seconds (24 hours)
Implement negative caching for failed lookups
Honor emergency flush requests via TTL=0

Revocation List Caching Revocation lists require stricter freshness controls:

Respect max-age field in revocation records
Recommended refresh interval: 5-15 minutes for active verification
MUST NOT serve revocation data older than max-age
Use bloom filters for privacy when appropriate

Organizational Caching Architecture Large-scale logistics operations (thousands of daily verifications) SHOULD implement centralized caching infrastructure: Recommended architecture: (Regional Cache) --> (Central Cache) --> (DNS) | v (Revocation Service) ]]> Tier 1 - Device Level:

Hot cache for current shift's frequent senders
TTL: 5-15 minutes
Capacity: 100-500 most recent key locators

Tier 2 - Regional/Facility Level:

Serves all devices in a geographic area
TTL: 1-4 hours
Maintains revocation list copies

Tier 3 - Central/Organization Level:

Single point of external DNS queries
TTL: Full DNS TTL
Authoritative cache for the organization

Benefits:

Dramatic reduction in external DNS queries (95%+ reduction)
Predictable DNS load on signing domains
Offline resilience when network connectivity is interrupted
Centralized revocation monitoring and push updates

Offline Operation Devices MAY operate offline with cached data:

Cache Age	Verification Behavior
< TTL	Normal verification, full trust
TTL to 4 hours	Verify with CACHE_STALE warning flag
4-24 hours	Verify with OFFLINE_MODE warning flag
> 24 hours	Fail verification, queue for re-check

Organizations SHOULD define acceptable staleness thresholds based on their security requirements and operational constraints. Note: Revocation checks MUST use fresh data when network is available. Offline verification without revocation checks SHOULD be flagged.

Directory Services Caching Directory service responses (provider lists, coverage data):

Cache provider lists by region
Update daily or on configuration change
Implement failover mechanisms for service outages

Use Case Examples

E-commerce Order with Privacy Customer checkout flow with privacy-preserving delivery:

Customer enters address, selects preferred carrier
System retrieves carrier's public key, encrypts recipient
Label shows only carrier destination
Carrier decrypts at delivery, completes with proof

High-Value Package with Anti-Cloning Split-key label flow for valuable items:

Sender scratches Zone A, signs package, destroys private key
Package transits with unverifiable signature (cloning prevented)
Recipient scratches Zone B, reveals public key, verifies

Corporate Mailroom Delivery Internal routing with organizational keys:

Employee selects corporate mailroom as destination
System encrypts internal routing (dept, room number)
Mailroom decrypts and routes internally

International Shipping Cross-border delivery with customs compliance:

Customs info public, recipient encrypted
Customs verifies declarations, cannot see recipient
Local provider decrypts and completes delivery