Frequently Asked Questions

DSPIP (Digital Signing of Physical Items Protocol) is an open cryptographic protocol for authenticating physical shipments using digitally signed QR codes. It provides:

• Sender authentication - Cryptographic proof of who sent the package
• Tamper detection - Any changes to the label are detected
• Privacy protection - Recipient addresses can be encrypted
• Chain of custody - Every scan is verifiable

The protocol is designed to work with existing shipping infrastructure and is currently an Internet-Draft submitted to the IETF.

Traditional tracking systems tell you where a package is, but not who actually sent it or if the label is legitimate. DSPIP adds cryptographic authentication:

• Traditional: "Package scanned in Memphis" - but was the label real?
• DSPIP: "Package cryptographically verified as originating from ACME Corp's warehouse"

DSPIP doesn't replace tracking - it adds an authentication layer that works alongside existing carrier systems. Think of it as adding a tamper-proof seal that also proves who applied it.

DSPIP is currently an Internet-Draft (draft-midwestcyber-dspip-01) submitted to the Internet Engineering Task Force (IETF). The specification is stable and suitable for implementation.

The protocol is designed to be compatible with existing standards:

• Uses DKIM-style DNS key distribution (RFC 6376)
• Interoperates with GS1 and EDI systems
• Compatible with ISO 18004 QR codes
• Uses industry-standard secp256k1 cryptography

SHIP is the type identifier for shipping applications in the DSPIP protocol. The QR code format includes a type field that is set to "SHIP" for all shipping use cases.

The protocol is designed to be extensible - future type identifiers could support other physical item authentication scenarios beyond shipping. Currently, SHIP is the only defined type.

DSPIP uses industry-standard cryptographic algorithms:

• Signatures (standard/encrypted): ECDSA with secp256k1 curve + SHA-256
• Signatures (split-key): Ed25519
• Encryption: ECIES with AES-256-GCM and HKDF-SHA256
• Key format: 33-byte compressed public keys (secp256k1) or 32-byte (Ed25519)

These algorithms are the same ones used by Bitcoin, Ethereum, and other cryptographic systems, providing battle-tested security.

DSPIP uses DNS TXT records for public key distribution, following the proven model established by DKIM for email authentication. Keys are published at:

<selector>._dspip.<domain>

For example: warehouse._dspip.example.com

Benefits of DNS-based distribution:

• No central authority required
• Organizations manage their own keys
• Uses existing global DNS infrastructure
• Records can be cached for offline verification
• Proven at scale (DKIM secures billions of emails)

DSPIP QR codes contain 6 or 7 pipe-delimited fields:

DSPIP|version|type|keyLocator|payload|signature[|privateMessage]

• DSPIP - Protocol identifier
• version - "1.0" for current version
• type - "SHIP" for shipping
• keyLocator - DNS path to public key
• payload - Base64-encoded JSON with shipping info
• signature - Hex-encoded ECDSA or Ed25519 signature
• privateMessage - Optional encrypted message

Yes, DSPIP supports offline verification in two ways:

• DNS cache bundles: Pre-download and sign bundles of DNS records for known senders. Update weekly.
• Split-key mode: Physical labels contain Ed25519 keys under scratch-off zones. No DNS lookup required - the public key is revealed by scratching Zone B.

Split-key mode is specifically designed for environments without reliable network connectivity, such as remote delivery locations or military field operations.

DSPIP supports three privacy modes for different security requirements:

• Standard: Full recipient address visible in the payload. Best for B2B shipments where transparency is required.
• Encrypted: Recipient address encrypted with the last mile provider's public key using ECIES. Only the designated delivery service can see the actual address.
• Split-Key: Maximum security with physical anti-cloning labels. Ed25519 keys are printed under scratch-off zones. Private key (Zone A) is revealed by sender to sign; public key (Zone B) is revealed by recipient to verify.

A last mile provider is the entity that decrypts the final delivery address in privacy-preserving modes. This could be:

• Post office: e.g., omaha-main._dspip.usps.gov
• Corporate mailroom: e.g., mailroom._dspip.acmecorp.com
• Residential carrier: e.g., omaha._dspip.fedex.com

Recipients select their preferred last mile provider at checkout. The sender encrypts the delivery address with that provider's public key. Carriers transiting the package see only "deliver to USPS Omaha Main" - not the actual recipient's home address.

In encrypted and split-key modes, no. Intermediate carriers only see:

• Sender information
• Last mile provider destination (e.g., "USPS Omaha Main")
• Tracking number

Your actual home address is encrypted and can only be decrypted by the last mile provider you selected. This follows the "digital envelope" model - just like a physical letter inside a sealed envelope.

Yes. DSPIP only stores hashed parcel IDs on blockchain:

• Tracking numbers are SHA-256 hashed before storage
• No personal information is recorded on-chain
• Location data uses geohashes or facility IDs, not addresses

The blockchain provides an immutable audit trail for custody events without exposing sensitive shipment details. Only parties with the original tracking number can correlate blockchain records.

DSPIP provides official SDKs for popular languages:

• JavaScript/Node.js: npm install @dspip/core
• Python: pip install dspip
• Go: go get github.com/dspip/dspip-go

All SDKs provide key generation, signing, verification, and DNS lookup functionality. See the developer documentation for complete API references.

Add a TXT record to your DNS with this format:

warehouse._dspip.example.com. IN TXT "v=DSPIP1; k=ec; c=secp256k1; p=YOUR_PUBLIC_KEY_BASE64; types=SHIP"

Required tags:

• v=DSPIP1 - Protocol version
• k=ec - Key type (elliptic curve)
• c=secp256k1 - Curve identifier
• p=... - Your Base64-encoded public key
• types=SHIP - Supported types

Key lifecycle tags (recommended): t (creation), exp (signing expiration), exp-v (verification expiration), s (status), seq (sequence number).

DSPIP supports smooth key rotation using lifecycle fields:

• Create a new key pair with a new selector (e.g., warehouse-2025)
• Publish the new key with incremented seq value
• Start using the new key for new shipments
• Set old key status to s=verify-only or let exp expire
• Keep old keys published until exp-v passes (recommended: 365 days after exp)
• Remove old key after exp-v timestamp

Verifiers MUST accept signatures from verify-only keys for packages created before the signing expiration (exp). The payload timestamp is compared against key expiration.

Yes! DSPIP provides a live test DNS record:

dig TXT test._dspip.dspip.io

You can use this record to verify your implementation against known test vectors. The test private key is published in the documentation for development purposes only.

For production, you'll need to set up your own DNS records.

Yes, DSPIP is an open protocol with no licensing fees. The specification is published as an Internet-Draft, and reference implementations are open source.

Costs to consider:

• DNS hosting: You need DNS records for your public keys (usually included in existing hosting)
• QR printing: Standard QR codes on shipping labels
• Split-key labels: Physical labels with scratch-off zones cost more than standard labels
• Blockchain (optional): Transaction fees if you enable on-chain custody recording

Yes, DSPIP is designed to complement, not replace, existing shipping infrastructure:

• Additive: The DSPIP QR code can be printed alongside existing carrier barcodes
• Compatible: EDI and GS1 identifiers can be included in the payload
• Optional: Carriers can implement DSPIP scanning incrementally
• Fallback: Packages work normally even if scanning systems don't verify DSPIP

Organizations can adopt DSPIP without requiring all carriers in the chain to support it immediately.

DSPIP can help with various regulatory requirements:

• DSCSA: Drug Supply Chain Security Act compliance for pharmaceutical serialization
• FSMA: Food Safety Modernization Act traceability requirements
• HIPAA: Encrypted mode protects patient information in specimen transport
• GDPR: Privacy modes protect personal address data
• ITAR: Chain of custody for controlled defense items

The protocol provides the cryptographic infrastructure; specific compliance implementations depend on your use case.

DSPIP allows senders to revoke packages that are lost, stolen, or recalled:

• Senders publish revocation lists via DNS or HTTP
• Verifiers check the list during signature verification
• Revoked packages are rejected even if the signature is valid
• Lists auto-prune entries older than 180 days

This prevents misuse of copied QR codes from packages that should no longer be in transit.