Summary

  • A 23 October individual Internet-Draft proposes DNS records for checking the keys and revocation state of Originator Profiles used to identify publishers of digital content.
  • Its optional SVCB record lets a publisher name acceptable Core Profile issuers in its own DNS zone. A verifier rejects a credential from an issuer outside that signed list.

Imagine a newsroom door with a row of nameplates. The credential company brings a badge; the newsroom decides whether that company belongs on the door. Shigeya Suzuki's new Internet-Draft gives that second decision a DNS record. It is a proposal dated 23 October, intended as an experiment, and IETF's document record identifies it as an individual draft. Nobody has voted the door into universal use.

The system starts with an Originator Profile. A Core Profile, issued to a content publisher, carries the keys with which that publisher signs its material. Other issuers may attach verified attributes as Profile Annotations. A verifier can inspect those signatures, yet still needs a fresh answer to a difficult question: is the key or credential still valid? The draft proposes an OPKEY DNS record below _op for key digests and issuer-side evidence of whether a Core Profile has been withdrawn. A separate TXT record covers annotation revocation. Full profiles stay out of DNS.

The politically interesting record sits under the publisher's own domain. The publisher may place an SVCB record at _op.<originator> listing the Core Profile issuers it accepts. If a DNSSEC-validated list is present, a verifier checks the issuer named in the profile against it. A credential from an otherwise recognised issuer can then fail at the publisher's door. That is a narrow but real allocation of authority: accreditation may tell a verifier that an issuer is trusted within the framework; the publisher decides whether that issuer may speak for this publisher. The draft makes the list optional. Without a required, securely published pin, the publisher remains unpinned.

The DNS machinery is less photogenic than the door, but it decides whether the door works. OPKEY answers must validate as Secure under DNSSEC. The draft treats an unsigned answer, a bogus proof or a resolver failure as verification failure, not as permission to believe an absent record. Its optional issuer pin has different absence rules: where pinning is not required, a securely proven absence leaves the publisher unpinned, while a bogus answer or timeout fails. That distinction keeps a forged silence from masquerading as a deliberate empty guest list.

Revocation has a clock. The draft discusses one-hour record and negative-cache lifetimes as deployment assumptions, then notes that a cached old answer can continue to validate a removed key until its TTL expires. A captured signed answer may also be replayed until its signature expires, and stale-answer service can stretch visibility further. In one laboratory configuration using 60-second values, record additions and removals appeared through a validating resolver within 63 seconds. That is a laboratory observation, not a promise to the world's publishers.