Network Working Group S. Suzuki Internet-Draft Keio University / OP-CIP / WIDE Project Intended status: Experimental 23 October 2026 Expires: 26 April 2027 Using Secure DNS for Originator Profile draft-shigeya-dns-opkey-00 Abstract The Originator Profile Framework (OPF) provides information about the origin of content, together with a verifiable binding of the content to that origin, in digital media, advertising, and email ecosystems. In the framework, an originator holds an Originator Profile (OP): a Core Profile (CP) issued by a CP issuer, and Profile Annotations (PA) issued by PA issuers. The CP carries the public keys with which the originator signs the data it originates; a PA annotates the CP with validated attributes about the originator. Verifiers need an authenticated way to confirm that the public keys used by an originator and by the issuers of these documents are currently valid, that the originator's CP has not been revoked by its CP issuer, and that a PA has not been revoked by its PA issuer. This document defines the OPKEY DNS resource record, which associates a public key with a DNS name under the _op label. Its wire and presentation formats are those of the TLSA record. The DNS does not carry the CP or the PAs themselves; it carries records that identify their keys by digest, and it signals, through the presence or absence of OPKEY records, whether a CP has been revoked. The document specifies where OPKEY records are located, how a verifier uses them, and how DNSSEC is used to authenticate them. It also specifies two further records under _op, of existing types: an SVCB record by which an originator names the CP issuers it accepts, and a TXT record whose presence signals that a PA issuer has revoked a PA. Operational aspects of the framework, such as registration, key rollover procedures, and revocation timing, are outside the scope of this document. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Suzuki Expires 26 April 2027 [Page 1] Internet-Draft DNS for Originator Profile October 2026 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 26 April 2027. Copyright Notice 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. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 5 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 2. The OPKEY Resource Record . . . . . . . . . . . . . . . . . . 7 2.1. Field Values . . . . . . . . . . . . . . . . . . . . . . 8 2.2. Key Representation . . . . . . . . . . . . . . . . . . . 9 2.3. Presentation Format . . . . . . . . . . . . . . . . . . . 9 3. Location of OPKEY Records . . . . . . . . . . . . . . . . . . 10 3.1. Records for the Keys of CP Issuers and PA Issuers . . . . 10 3.2. Originator Key Records . . . . . . . . . . . . . . . . . 11 3.3. Semantics of Presence and Absence . . . . . . . . . . . . 12 3.4. No Aliases or Wildcards . . . . . . . . . . . . . . . . . 13 4. Transitional Publication . . . . . . . . . . . . . . . . . . 14 4.1. Before the Type Value Is Allocated . . . . . . . . . . . 14 4.2. After the Type Value Is Allocated . . . . . . . . . . . . 14 4.3. Verifier Behavior . . . . . . . . . . . . . . . . . . . . 15 5. Mandatory-to-Implement Features . . . . . . . . . . . . . . . 15 6. Application Use of OPKEY Records . . . . . . . . . . . . . . 16 6.1. DNSSEC Requirements . . . . . . . . . . . . . . . . . . . 16 6.2. Matching a Key against an OPKEY RRset . . . . . . . . . . 17 Suzuki Expires 26 April 2027 [Page 2] Internet-Draft DNS for Originator Profile October 2026 6.3. Verifying a Content Signature . . . . . . . . . . . . . . 18 6.4. Verifying a CP or PA Signature . . . . . . . . . . . . . 18 6.5. Caching . . . . . . . . . . . . . . . . . . . . . . . . . 19 7. Key Size and DNS . . . . . . . . . . . . . . . . . . . . . . 19 8. Other Records under _op . . . . . . . . . . . . . . . . . . . 19 8.1. SVCB Mapping for _op . . . . . . . . . . . . . . . . . . 20 8.2. CP Issuer Pinning at the Originator (SVCB) . . . . . . . 20 8.3. Revocation Records (TXT) . . . . . . . . . . . . . . . . 21 8.4. Permitted Host Records (TXT) . . . . . . . . . . . . . . 22 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 9.1. OPKEY RRTYPE . . . . . . . . . . . . . . . . . . . . . . 23 9.2. Underscored Name _op . . . . . . . . . . . . . . . . . . 23 9.3. URI Scheme op . . . . . . . . . . . . . . . . . . . . . . 23 10. Operational Considerations . . . . . . . . . . . . . . . . . 24 10.1. Queries per Verification . . . . . . . . . . . . . . . . 24 10.2. What Reaches the Authoritative Servers . . . . . . . . . 25 10.3. Response Sizes . . . . . . . . . . . . . . . . . . . . . 26 10.4. Time to Live and Negative Caching . . . . . . . . . . . 28 10.5. Zone Size and Signing Load . . . . . . . . . . . . . . . 29 10.6. Basis of the Figures . . . . . . . . . . . . . . . . . . 30 11. Security Considerations . . . . . . . . . . . . . . . . . . . 31 11.1. Dependence on DNSSEC . . . . . . . . . . . . . . . . . . 32 11.2. Pinning and Resolution Failures . . . . . . . . . . . . 32 11.3. Response Size . . . . . . . . . . . . . . . . . . . . . 33 11.4. Digest Agility . . . . . . . . . . . . . . . . . . . . . 33 11.5. Availability . . . . . . . . . . . . . . . . . . . . . . 34 11.6. Removed Keys and Caching . . . . . . . . . . . . . . . . 34 11.7. Information Exposure . . . . . . . . . . . . . . . . . . 35 11.8. Transitional TLSA Records . . . . . . . . . . . . . . . 36 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 36 12.1. Normative References . . . . . . . . . . . . . . . . . . 36 12.2. Informative References . . . . . . . . . . . . . . . . . 38 Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 41 Appendix B. Experiment Goal . . . . . . . . . . . . . . . . . . 43 Appendix C. RRTYPE Allocation Template . . . . . . . . . . . . . 43 Appendix D. Implementation Status . . . . . . . . . . . . . . . 44 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 45 1. Introduction The Originator Profile Framework (OPF) [OPF-AOV], developed by the Originator Profile Collaborative Innovation Partnership (OP-CIP), is a framework in which an organization that publishes content (the originator) holds an Originator Profile (OP): a Core Profile (CP) together with one or more Profile Annotations (PA). The CP is issued to the originator by one of the framework's CP issuers; the PAs are issued by PA issuers and provide validated attributes about the originator. The CP carries one or more public keys of the Suzuki Expires 26 April 2027 [Page 3] Internet-Draft DNS for Originator Profile October 2026 originator, and the originator signs its content with one of them. The keys of a CP are fixed when it is issued: to change its keys, the originator obtains a new CP, and the old and the new CP can both be valid for a time, for instance during a key rollover. A verifier that receives the content together with the CP and PAs can check the signatures, but it also needs to know four things: that the keys in the CP are still valid; that the CP itself has not been revoked by its CP issuer; that none of the PAs has been revoked by its PA issuer; and that the keys with which the CP issuer and the PA issuers signed these documents are keys those issuers currently use. This document puts the information a verifier needs in the DNS, protected by DNSSEC [RFC4033] [RFC4034] [RFC4035]. It defines the OPKEY resource record (RR), which associates a public key with a DNS name, and uses it to identify the signing keys of originators, CP issuers, and PA issuers, and to record whether a CP has been revoked; for the revocation of a PA (TXT), and for an originator's choice of CP issuer (SVCB), it uses existing record types. Every record defined here is placed below the name of the party that publishes it, under _op, a global underscored node name in the sense of [RFC8552] that this document registers (Section 9.2). The OPKEY RDATA has the same wire and presentation format as the TLSA record [RFC6698]. A separate RR type is used rather than TLSA itself so that the semantics of the two records stay distinct, as [RFC8162] does for S/ MIME with a type that also shares the TLSA format, and as [RFC7929] does for OpenPGP keys with a type of its own. Until the type value is allocated, OPKEY records (but not the SVCB and TXT records of Section 8) are published in the TLSA form of Section 4.1. The records defined here are independent of the CP and the PAs themselves. What this document places in the DNS are not those documents but signals about them: records identifying the keys against which a verifier matches, by digest rather than by the key itself; and, through the presence or absence of records, an indication of whether a CP has been revoked by its CP issuer and whether a PA is still in force. The records thus let a verifier confirm, from a source under the CP issuer's control, that a CP it holds has not been revoked and which of its keys are current. The records do not define a distribution channel for CPs and PAs. Whether those documents travel with the content or are obtained by some other means is determined by the use case specification of the Originator Profile Framework that governs the verification. The use case specifications current at the time of writing, for web media [OPF-WEB-MEDIA] and for email [OPF-EMAIL], do not use the DNS to distribute the CP and PAs: the web media specification carries them in the page or makes them available at a well-known location of the page's origin, and the email specification carries them within the signed message. Suzuki Expires 26 April 2027 [Page 4] Internet-Draft DNS for Originator Profile October 2026 The rest of this document is organized as follows. Section 2 defines the OPKEY RR. Section 3 defines the two places where it is published: under a CP issuer's or PA issuer's own name, for its own signing keys, and in the Originator Key Records, by which a CP issuer identifies the keys of each CP it has issued. Section 4 covers publication before the DNS software in use recognizes the new type, and Section 5 lists what record publishers and verifiers are required to support. Section 6 specifies how a verifier uses the records, Section 7 discusses their size in the DNS, and Section 8 describes two further records under _op: an SVCB record by which an originator names the CP issuers it accepts, and a TXT record by which a PA issuer revokes a PA. Section 10 estimates what the records ask of the DNS: the queries a verification makes, the size of the responses, and the load of signing an issuer's zone. The procedure by which a verifier verifies an Originator Profile as a whole is specified by the Core Specification [OPF-CORE]; this document specifies only the DNS part of it. This document does not specify how CP issuers register originators, how keys are rolled over, or how long records are retained. Those are operational matters of the Originator Profile Framework, described in the Core Specification [OPF-CORE] and in the operational documents that accompany it. The status of this document, and the questions its deployment is intended to answer, are discussed in Appendix B. 1.1. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 1.2. Terminology The DNS terminology of [RFC1034] and [RFC1035] is used, including "owner name" for the name to which an RR belongs, "RRset" for all RRs of one type at one owner name, and the DNSSEC validation states "Secure", "Insecure", "Bogus", and "Indeterminate" of [RFC4033] and [RFC4035]. Originator: An organization that publishes content and holds a Core Profile. An originator is identified by a fully qualified domain name (FQDN). Every CP issuer and PA issuer is also an originator, the subject of its own CP. CP issuer: An entity that issues Core Profiles to originators and Suzuki Expires 26 April 2027 [Page 5] Internet-Draft DNS for Originator Profile October 2026 publishes an Originator Key Record for each CP it issues. The framework has more than one CP issuer; a CP names the CP issuer that issued it. A CP issuer is identified by an FQDN, and publishes, at _issuer-key._op., an OPKEY RRset identifying its own signing keys. Core Profile (CP): A signed document, issued by a CP issuer to an originator, that carries, among other things, one or more public keys of the originator and its Originator Key Record Name, at which a verifier checks that the CP has not been revoked and which of those keys are valid. A Root Core Profile carries no Originator Key Record Name. Profile Annotation (PA): A signed document, issued by a PA issuer, that binds validated attributes about an originator to its CP and carries its own Revocation Record Name, at which a verifier checks whether the PA issuer has revoked the PA ahead of the end of its Signature Validity Period. PA issuer: An entity that issues Profile Annotations. A PA issuer is identified by an FQDN, and publishes, at _issuer-key._op., an OPKEY RRset identifying its own signing keys. CP issuer and PA issuer are roles, not kinds of entity: one entity may hold both, in which case it publishes one OPKEY RRset at its _issuer-key._op name for the keys it uses in either role, while its Originator Key Records and its Revocation Records remain at their separate names (Section 3, Section 8.3). Which roles an entity holds is stated by the Originator Profile Framework [OPF-CORE], not by this document. A Root Issuer or Accreditation Body of the Core Specification issues Issuer Accreditations as a PA issuer; a Root Issuer also issues CPs as a CP issuer. Signature Validity Period: The period for which the signature of a CP or a PA is to be relied on, as the Core Specification [OPF-CORE] defines it. Content Validity Period: A period that a PA can state for what it states, which contains the PA's Signature Validity Period [OPF-CORE]. Issuer Key Record: The OPKEY RRset at _issuer-key._op. or _issuer-key._op. (Section 3.1). It identifies, by the digests of their SubjectPublicKeyInfo (Section 2.2), the keys whose signatures on the documents of that issuer are to be accepted: the key the issuer signs with, a key it is about to sign with, and a key whose signatures may still be verified. Originator Key Record: The OPKEY RRset at one Originator Key Record Suzuki Expires 26 April 2027 [Page 6] Internet-Draft DNS for Originator Profile October 2026 Name. It identifies, by the digests of their SubjectPublicKeyInfo (Section 2.2), the public keys of one CP that remain valid. Its presence means that the CP has not been revoked; its absence means that it has. Originator Key Record Name: The FQDN of an Originator Key Record, below _originator-key._op.. It is assigned by the CP issuer when the CP is issued and carried in the CP. Revocation Record: The TXT RRset at one Revocation Record Name (Section 8.3). Its presence means that the PA has been revoked; its absence means that it has not. Revocation Record Name: The FQDN of a Revocation Record, below _revocation._op.. It is assigned by the PA issuer when the PA is issued and carried in the PA. Record label: The leftmost label of an Originator Key Record Name or of a Revocation Record Name. It is assigned by the CP issuer or the PA issuer, respectively, and is opaque (Section 3.2). Record publisher: A CP issuer or PA issuer in its role of publishing OPKEY RRs (and, before the type value is allocated, the TLSA RRs of Section 4.1) under _op. OPKEY RR, OPKEY RRset: One OPKEY RR corresponds to one public key, which it identifies by the digest of its SubjectPublicKeyInfo. The OPKEY RRset at a name corresponds to the set of keys valid at that name. 2. The OPKEY Resource Record The OPKEY DNS resource record (RR) is used to associate a public key with a DNS name. The keys so associated are the signing keys of originators, CP issuers, and PA issuers in the Originator Profile Framework. The type value for the OPKEY RR type is allocated by IANA (Section 9). The OPKEY resource record is class independent. The OPKEY wire format and presentation format are the same as those of the TLSA record, described in Section 2.1 of [RFC6698]. The Certificate Usage field, the Selector field, and the Matching Type field have the same format. Their semantics are also the same, with two differences: where [RFC6698] refers to a certificate offered in a TLS handshake, this document refers to the public key used to sign an Originator Profile document or content; and the set of permitted values is restricted as described below. The three fields are kept, Suzuki Expires 26 April 2027 [Page 7] Internet-Draft DNS for Originator Profile October 2026 although this document fixes the values of two of them, so that the RDATA has the wire format of TLSA: the TLSA form of Section 4.1 then carries the same RDATA, and existing tools for TLSA records can produce and read it. 2.1. Field Values This document restricts the fields of the OPKEY RDATA as follows. Certificate Usage: MUST be 3 (DANE-EE). The association is to the end-entity key itself; no PKIX chain is involved. Other values are reserved for future use and MUST NOT be published under this specification. Selector: MUST be 1 (SPKI). The association is to the SubjectPublicKeyInfo structure [RFC5280] of the key, not to a certificate. Other values MUST NOT be published under this specification. Matching Type: MUST be 1 (SHA-256) or 2 (SHA-512). The format of [RFC6698] also defines 0 (no hash; the full SubjectPublicKeyInfo). The Originator Profile Framework does not use Matching Type 0 [OPF-CORE]. Matching Type 0 and other values MUST NOT be published under this specification. With either Matching Type, the verifier obtains the key itself from the document it verifies, not from the DNS (Section 6). Certificate Association Data: The SHA-256 or SHA-512 digest of the DER-encoded SubjectPublicKeyInfo of the key, according to the Matching Type. The field keeps the name it has in Section 2.1.4 of [RFC6698], although under this specification it never holds a certificate. A verifier MUST ignore any OPKEY RR whose Certificate Usage is not 3, whose Selector is not 1, or whose Matching Type is 0, any RR whose Matching Type it does not support, and any RR whose Certificate Association Data does not have the length that its Matching Type requires (32 octets for Matching Type 1, 64 octets for Matching Type 2). Such RRs are unusable, in the sense in which [RFC7671] calls TLSA records with unsupported parameters unusable. The remaining RRs of the RRset are used for matching as described in Section 6. An OPKEY RRset that is present but contains no usable RR is nevertheless present: no key is valid at the name, and the verifier does not query for TLSA (Section 4.3). Suzuki Expires 26 April 2027 [Page 8] Internet-Draft DNS for Originator Profile October 2026 2.2. Key Representation The Certificate Association Data is computed over the DER encoding of the SubjectPublicKeyInfo (SPKI) structure defined in [RFC5280], regardless of the format in which the key appears in an Originator Profile document. In the current OP data model, keys in a CP are represented as JSON Web Keys [RFC7517]. A JWK MUST be converted to its SPKI form before the Certificate Association Data is computed or compared, whatever the Matching Type. The SPKI form of a key is the one standardized for its key type. For an elliptic curve key it is the id-ecPublicKey AlgorithmIdentifier with a namedCurve parameter and the uncompressed point encoding, as specified in [RFC5480]; for an RSA key it is the rsaEncryption AlgorithmIdentifier with the RSAPublicKey structure of [RFC8017], as specified in [RFC3279]. The JWK parameters of these two key types are defined in [RFC7518]. For other key types it is the SPKI encoding defined for that key type in PKIX certificates. This document does not restrict the key types; which signature algorithms may be used with an Originator Profile document is determined by the framework. The SPKI identifies the key only. It does not carry the signature algorithm with which the key is used, and it is distinct from the JWK Thumbprint of [RFC7638], which MUST NOT be used as Certificate Association Data. 2.3. Presentation Format The presentation format of the OPKEY RDATA is the same as that of the TLSA RDATA (Section 2.2 of [RFC6698]). The mnemonics for the Certificate Usage, Selector, and Matching Type fields defined in [RFC7218] MAY be used in zone files and diagnostic output; for OPKEY these are "DANE-EE" for Certificate Usage 3, "SPKI" for Selector 1, and "SHA2-256" and "SHA2-512" for Matching Types 1 (SHA-256) and 2 (SHA-512). For example, an OPKEY RR associating the SHA-256 digest of a key's SPKI with a name is written as: _issuer-key._op.cip.op-example.org. IN OPKEY 3 1 1 ( c9d1a2f0e3b45c67d8e9f0a1b2c3d4e5f60718293a4b5c6d7e8f90a1b2c3d4e5 ) Suzuki Expires 26 April 2027 [Page 9] Internet-Draft DNS for Originator Profile October 2026 3. Location of OPKEY Records All DNS records defined for the Originator Profile Framework are placed under the _op label. _op is the one label they all share; the sub-labels below it identify the kind of record. The names of a CP issuer or PA issuer (_issuer-key._op., and the names below _originator-key._op. or _revocation._op., respectively) do not collide with the records a party publishes about itself as an originator (Section 8), which are at _op. (the Issuer Pinning Record) and below _site._op.. A party that is both an originator and a CP issuer or PA issuer publishes all of them under its one _op.. This document defines two locations for OPKEY records, and then states what a record publisher does not place at these names (Section 3.4). The zone that holds the _issuer-key._op name of a CP issuer or PA issuer, and every zone that holds the _originator-key._op node of a CP issuer or a name below it, MUST be signed, with NSEC or with NSEC3 [RFC5155] without the Opt-Out flag, and securely delegated, so that a chain of trust leads to it from the root zone [RFC4033] and the absence of a name in it is a Secure proof (Section 6.1). An OPKEY RRset in an unsigned zone yields an Insecure response, which is a verification failure (Section 6.1); a CP issuer or PA issuer therefore needs a name under which DS records can be published at each zone cut (Section 11.1). 3.1. Records for the Keys of CP Issuers and PA Issuers A CP issuer publishes the OPKEY RRset identifying its own signing keys at _issuer-key._op. and a PA issuer publishes the OPKEY RRset identifying its own signing keys at _issuer-key._op. where and are the FQDNs by which the CP issuer and the PA issuer, respectively, are identified in the documents they sign. Either RRset is the Issuer Key Record of that issuer. Each OPKEY RR at _issuer-key._op. or _issuer- key._op. corresponds to one signing key of that CP issuer or PA issuer. Verifiers match the key that signed a CP or a PA against this RRset (Section 6); the key itself is carried in the document and is not obtained from the DNS. Suzuki Expires 26 April 2027 [Page 10] Internet-Draft DNS for Originator Profile October 2026 3.2. Originator Key Records A CP issuer publishes one OPKEY RRset, the Originator Key Record, for each CP it has issued, under _originator-key._op. The owner name of an Originator Key Record, the Originator Key Record Name, is ._originator-key._op. where stands for the record label, the opaque label that the CP issuer assigns to the CP (a UUID, as described below; Appendix A shows such names), optionally with additional labels between the record label and _originator-key (see below). Each OPKEY RR at this name corresponds to one public key contained in the CP. The record label is opaque. It is assigned by the CP issuer and is not derived from the originator's name. A UUID [RFC9562] of version 4, whose bits are drawn from a random source so that the label cannot be guessed, is a suitable label. The steps by which a CP issuer allocates a label, and keeps it from being reused, are an operational matter of the framework and are not specified here. An Originator Key Record Name identifies one CP. A CP issuer MUST assign a new one each time it issues a CP, whether the originator's keys change or only the Signature Validity Period is renewed, so that revoking an earlier CP does not reach a later one. A name that has been assigned to one CP MUST NOT be assigned to another. A CP issuer publishes the Originator Key Record of a CP, and lets the negative caching period of the zone (Section 10.4) pass, before it issues the CP that carries its name, as the Core Specification [OPF-CORE] requires. A resolver may already hold a proof that the name does not exist, or have synthesized one from the NSEC or NSEC3 records of neighbouring names [RFC8198]; a CP issued before that proof expires would be treated as revoked. The Originator Key Record Name is not derived by the verifier. It is carried, as a complete FQDN, in the CP itself. A verifier MUST use the carried Originator Key Record Name as is, and MUST check that it lies below _originator-key._op., where is the FQDN of the CP issuer that issued the CP. Any number of labels MAY appear between the record label and _originator-key; the verifier does not interpret them. This allows a CP issuer to divide its Originator Key Records among several zones without changing the verification procedure. Each such zone is signed and securely Suzuki Expires 26 April 2027 [Page 11] Internet-Draft DNS for Originator Profile October 2026 delegated, as Section 3 requires; an Originator Key Record in an unsigned zone yields an Insecure response, which is a verification failure (Section 6.1). A CP issuer that derives such a dividing label from the record label is advised to take it from the random bits of the label (those of a UUID of version 4). The check that the carried name lies below _originator-key._op. is made on the names as sequences of labels, after both have been put in the form the Core Specification [OPF-CORE] defines for domain names (lower-case A-labels, no trailing dot): the carried name lies below the node if its trailing labels are exactly those of _originator-key._op. and at least one label precedes them. A carried name that does not lie below the node is a verification failure. Without the check that the carried name lies below the CP issuer's _originator-key._op node, a CP issuer could place the Originator Key Record of a CP in a zone outside its own name space, and so hand the authority over that CP to that zone; the check keeps that authority within the CP issuer's own name space (another party can operate part of the Originator Key Record zone through delegation with NS records, Section 3.4). 3.3. Semantics of Presence and Absence An OPKEY RRset is published either as an Originator Key Record (Section 3.2) or as the Issuer Key Record of a CP issuer or PA issuer (Section 3.1). An Originator Key Record stands for one CP, so its presence and absence are the state of that CP. An Issuer Key Record stands for the signing keys of one CP issuer or PA issuer, so its presence and absence say which of those keys are valid. At an Originator Key Record Name: * The presence of an OPKEY RRset means that the CP has not been revoked by the CP issuer. Each OPKEY RR names one valid key of that CP. * The removal of the OPKEY RRs for one key (one per Matching Type in use, Section 5) means that the corresponding key is no longer valid; the CP has not been revoked, and the other keys remain valid. * The absence of the name, or of any OPKEY RRset at it (NXDOMAIN or NODATA), means that the CP has been revoked, and none of its keys is valid. Suzuki Expires 26 April 2027 [Page 12] Internet-Draft DNS for Originator Profile October 2026 A new key of an originator is carried by a new CP, whose Originator Key Record is at a new name (Section 3.2). At _issuer-key._op. or _issuer-key._op.: * The presence of an OPKEY RRset means that the CP issuer or PA issuer has signing keys that are valid. Each OPKEY RR names one key that is valid for that CP issuer or PA issuer. * The removal of the OPKEY RRs for one key (one per Matching Type in use, Section 5) means that the corresponding key is no longer valid; the other keys remain valid. * The absence of the name, or of any OPKEY RRset at it (NXDOMAIN or NODATA), means that none of the keys of that CP issuer or PA issuer is valid. During a rollover of the keys of a CP issuer or PA issuer, the OPKEY RRs for the old and the new key are published in parallel at its _issuer-key._op name. How long they overlap, and when the RRs for a key that is no longer in use may be removed, are operational parameters and are not specified here. 3.4. No Aliases or Wildcards A CP issuer or PA issuer MUST NOT publish a CNAME or DNAME record that redirects its _issuer-key._op name, or any of its Originator Key Record Names, to another name: the records are published at the names this document states, and a verifier uses an OPKEY RRset only at the name it queried (Section 6.1). A CP issuer or PA issuer that wishes another party to operate part of its name space delegates a subtree of it with NS records, which keeps the names where this document places them. A CP issuer or PA issuer MUST NOT publish a wildcard record [RFC4592] whose owner name lies at or below _originator-key._op., or from which an answer at its own _issuer-key._op name could be synthesized. A wildcard at _originator-key._op. would make an Originator Key Record appear at every Originator Key Record Name and would leave the CP issuer no way to revoke one CP by removing its Originator Key Record. Verifiers do not treat an answer synthesized from a wildcard for the queried name differently from any other answer. DNSSEC lets a validator recognize such an answer (Section 5.3.4 of [RFC4035]), but this document does not ask verifiers to distinguish it, since the harm of a wildcard falls on the record publisher that placed it. Suzuki Expires 26 April 2027 [Page 13] Internet-Draft DNS for Originator Profile October 2026 4. Transitional Publication Deploying a new RR type takes time. Two periods are distinguished, separated by the allocation of the OPKEY type value (Section 9). 4.1. Before the Type Value Is Allocated Until the type value is allocated, an OPKEY RR cannot be expressed in a form that other parties would recognize: the generic representation of [RFC3597] requires the value, and DNS software has no mnemonic to recognize. A value from the private-use range of [RFC6895] is not used instead, because the records of a public experiment would then be indistinguishable from any other private use of the same value. A record publisher that takes part in the experiment before the allocation MAY publish the RDATA defined by this document as a TLSA RRset [RFC6698] at the owner name at which the OPKEY RRset will be published. The TLSA RRset carries no meaning under [RFC6698]. It is placed under _op, not at an owner name of the form _port._proto.host at which TLSA records for TLS are placed, so the two uses do not collide. If the allocation requested in Section 9 is made before any record publisher deploys, this period is empty and the TLSA form is never used. 4.2. After the Type Value Is Allocated Once the type value is allocated, OPKEY is handled as an unknown type, as specified in [RFC3597], by authoritative servers, resolvers, and DNSSEC signers that do not recognize the mnemonic, and its generic representation is accepted by provisioning interfaces that follow that RFC. From then on record publishers MUST publish their OPKEY RRs as OPKEY, using the generic representation of Section 5 of [RFC3597] where the mnemonic is not accepted. The record of Section 2.3 is then written as _issuer-key._op.cip.op-example.org. IN TYPE \# 35 ( 030101 c9d1a2f0e3b45c67d8e9f0a1b2c3d4e5f60718293a4b5c6d7e8f90a1b2c3d4e5 ) where is the allocated type value. The record is the OPKEY record itself, with the same wire format and the same DNSSEC signature; only its presentation differs, and a zone moves from this form to the mnemonic form without any change visible to verifiers. No transition away from the generic representation is therefore needed. A record publisher that published a TLSA RRset before the allocation publishes the OPKEY RRset, as required above, and SHOULD remove the TLSA RRset once it judges that no verifier still relies on the TLSA form. One basis for that judgment is the point at which verifiers Suzuki Expires 26 April 2027 [Page 14] Internet-Draft DNS for Originator Profile October 2026 discontinue the fallback, as declared by each Root Issuer of the framework [OPF-CORE] (Section 4.3). The TLSA form MUST NOT be used for new publication after the allocation. It is a transitional form only, since it uses TLSA outside the semantics of [RFC6698]. While a record publisher keeps a TLSA RRset at a name at which it also publishes OPKEY, the TLSA RRset MUST carry exactly the same RDATA as the OPKEY RRset, and a change to one MUST be made to the other at the same time; otherwise a verifier that still uses the TLSA form would continue to accept a key that has been removed from the OPKEY RRset. 4.3. Verifier Behavior Before the type value is allocated, no query for OPKEY can be formed. During that period a verifier MUST query for the TLSA RRset at the name and MUST use it in place of the OPKEY RRset. This is the only form in which the records exist, and a verifier that did not use it would verify nothing during that period. Once the value is allocated, a verifier MUST query for OPKEY first. If a Secure OPKEY RRset is present, the verifier MUST use it and MUST ignore any TLSA RRset at the same name. If, and only if, there is a Secure proof that no OPKEY RRset exists at the name, the verifier MUST query for a TLSA RRset at the same name; if one is present, the verifier MUST use it. A Bogus or Insecure answer to the OPKEY query, an Indeterminate result, or a failure to resolve it, is a verification failure and MUST NOT lead to a TLSA query (Section 6.1). In either period, a verifier that uses a TLSA RRset MUST apply to it every rule this document states for an OPKEY RRset, including the DNSSEC requirements of Section 6.1, interpreting its RDATA exactly as it would OPKEY RDATA. Each Root Issuer of the framework declares, under the framework's governance, the point at which verifiers discontinue the fallback. A verifier that accepts the Root Core Profiles of more than one Root Issuer discontinues it only once all of them have declared that point. What binds a verifier until then is stated by this document and the Core Specification [OPF-CORE]. 5. Mandatory-to-Implement Features A record publisher MUST be able to publish OPKEY RRs with Certificate Usage 3, Selector 1, and Matching Type 1 (SHA-256), and SHOULD be able to publish Matching Type 2 (SHA-512). In every OPKEY RRset it publishes, every key MUST be identified by an RR of Matching Type 1, and a key MUST be identified by Matching Type 2 only if every key in the RRset is; otherwise a verifier that supports SHA-512 would select Matching Type 2 (step 3 of Section 6.2) and reject a key that the Suzuki Expires 26 April 2027 [Page 15] Internet-Draft DNS for Originator Profile October 2026 RRset identifies by its SHA-256 digest only. The same applies to a TLSA RRset that carries OPKEY RDATA before the type value is allocated (Section 4.1). A verifier MUST be able to compare a public key with OPKEY RRs of Certificate Usage 3, Selector 1, and Matching Type 1, and SHOULD be able to do so with Matching Type 2. 6. Application Use of OPKEY Records This section describes how a verifier uses OPKEY records when verifying Originator Profile documents and content. It covers only the DNS part of verification; the structure and validation of the documents themselves are defined by the Originator Profile Framework. A verifier queries a name carried in a CP or a PA only after it has verified the signature on that document with a key obtained from the documents of the chain of trust that the Core Specification [OPF-CORE] defines; the DNS checks on that key (Section 6.4) come after that verification, not before it. Until the signature is verified, the record names and issuer names in the document are, for all the verifier knows, chosen by an arbitrary party, and a query for them would reveal to the zone they point at that the document reached a verifier (Section 11.7). A verifier builds the names it queries from the FQDNs that the documents carry, in the form the Core Specification [OPF-CORE] defines for domain names (Section 3.2); under the Core Specification, an FQDN that cannot be put in that form is a verification failure. 6.1. DNSSEC Requirements OPKEY records are only meaningful when they are validated with DNSSEC. A verifier MUST either perform DNSSEC validation itself or obtain the validation state from a validating resolver over a secure channel. A secure channel is one that authenticates the resolver and protects its answers, and the AD bit in them, between the resolver and the verifier (Section 4.9.3 of [RFC4035]): for example DNS over TLS [RFC7858] under the Strict Privacy profile of [RFC8310], DNS over HTTPS [RFC8484], or the local path to a validating resolver on the verifier's own host. A verifier that obtains the validation state from a resolver MUST have assurance, by configuration or by test, that the resolver validates. An answer from a resolver that does not validate carries no validation state, and MUST NOT be read as Insecure. * An OPKEY RRset MUST be used only if its validation state is Secure. Suzuki Expires 26 April 2027 [Page 16] Internet-Draft DNS for Originator Profile October 2026 * A Bogus response, or a resolution failure (for example SERVFAIL), MUST be treated as a verification failure. The verifier MUST NOT proceed as if the RRset were absent. * An Insecure response (the name is in an unsigned part of the DNS tree), whether it contains an OPKEY RRset or denies its existence, provides no assurance and MUST be treated as a verification failure, as a Bogus response is; it is neither a presence nor an absence, and does not lead to a TLSA query (Section 4.3). * An Indeterminate result, one for which the verifier could not determine the validation state (Section 5 of [RFC4033]), MUST be treated as a verification failure, as a Bogus response is. It is neither a presence nor an absence. * An answer reached through an alias, that is, one in which the RRset returned belongs to an owner name other than the one queried because a CNAME or DNAME record redirected the query, MUST be treated as a verification failure, whatever its validation state. A verifier uses an OPKEY RRset only at the name it queried (Section 3.4). * A Secure denial of existence (NXDOMAIN or NODATA) means that the RRset is absent. Verifiers MUST treat NXDOMAIN and NODATA alike. 6.2. Matching a Key against an OPKEY RRset To check whether a public key K is valid at a name N: 1. Obtain the OPKEY RRset at N with DNSSEC validation, as above. If the RRset is absent, K is not valid at N. 2. Discard unusable RRs (Section 2.1). 3. Among the Matching Types that the verifier supports and that at least one usable RR carries, select the strongest, where 2 (SHA- 512) is stronger than 1 (SHA-256). 4. Compute the DER-encoded SPKI of K (Section 2.2), and its digest according to the selected Matching Type. K is valid at N if and only if a usable RR of the selected Matching Type carries that value. In the Originator Profile Framework, a signed document indicates its signing key by a digest of the same SPKI, which the framework calls the Key Identifier; which digest algorithm it uses, and which property of the document carries it, are defined by the Core Specification [OPF-CORE]. That value, and any value that a CP Suzuki Expires 26 April 2027 [Page 17] Internet-Draft DNS for Originator Profile October 2026 associates with one of its keys, serve the verifier only to select the key K among those that the documents carry (Section 6.3). The procedure above starts from K: as the Core Specification requires, the value that the verifier looks for in the DNS is the digest that it computes in step 4 from K, the key with which it verifies the signature, and a value that a document carries is never compared with the Certificate Association Data. The Core Specification also requires every record publisher to publish, for each key it lists, the form that every conforming verifier supports (Section 5); this document defines only the Matching Types in which a digest can appear in the DNS. 6.3. Verifying a Content Signature When content signed by an originator is accompanied by the originator's CP, issued by CP issuer O and already verified by the verifier (Section 6.4), the verifier first selects, among the keys that the CP carries, the key K that the content signature indicates, and verifies the content signature with K, before making any query. How a signature indicates its key, and how it is verified, are defined by the Core Specification [OPF-CORE] and by the use case specification that governs the verification. The verifier then MUST perform the following checks: 1. The verifier reads the Originator Key Record Name N from the CP and checks that N lies below _originator-key._op., by the rule of Section 3.2. A name that does not lie below that node is a verification failure. 2. The verifier checks that K is valid at N as above. 3. The verifier checks that K is among the keys contained in the CP. The verifier accepts K only if K is both contained in the CP and valid at N. The other RRs at N and the other keys in the CP are not compared with each other: during a key rollover the DNS may identify a key that an older CP does not yet contain, and a CP may contain a key whose RRs have been removed. 6.4. Verifying a CP or PA Signature When a CP is signed by CP issuer I, or a PA by PA issuer I, with key K, the verifier checks, as the Core Specification [OPF-CORE] requires, that K is valid at _issuer-key._op., where I is the FQDN by which the CP issuer or PA issuer identifies itself in the document. The Originator Profile Framework defines the remaining checks on the document. They cover its Signature Validity Period, its subject, the chain of Issuer Accreditations by which the CP issuer or PA issuer is trusted, and, for a PA, whether it has been Suzuki Expires 26 April 2027 [Page 18] Internet-Draft DNS for Originator Profile October 2026 revoked (Section 8.3); for a CP, that check is part of Section 6.3. A Root Issuer has no chain, and the verifier holds its Root Core Profile rather than checking it in the DNS. An Issuer Accreditation is a Profile Annotation on the CP of a CP issuer or PA issuer that states its standing in the framework [OPF-CORE]. The only further OPKEY lookups these checks involve are applications of the same rule at each CP issuer and PA issuer in the chain. 6.5. Caching A verifier MAY cache an OPKEY RRset, or a Secure denial of its existence, but MUST NOT use either beyond the TTL with which the answer arrived (for a denial, the TTL of [RFC2308]). The consequences of caching for the detection of removed keys are discussed in Section 11; the choice of TTL values is an operational matter. 7. Key Size and DNS Matching Types 1 and 2 keep OPKEY RDATA small (32 or 64 octets of Certificate Association Data) regardless of the key type, including post-quantum key types, whose SPKI encodings are large. The full key is available to the verifier from the CP or from the documents of the CP issuer or PA issuer, so the DNS does not carry it; Matching Type 0 is not used (Section 2.1). What a post-quantum DNSSEC signature algorithm would do to the size of the responses is computed in Section 10.3. 8. Other Records under _op This section is informative, except for Section 8.1, which is normative. Two further records are published under _op. They are not OPKEY records, but they share the _op label and are used by the same verifiers. Their names and their contents are described here because this document registers _op (Section 9.2) and the enumeration of the names below it has to be complete; what a verifier is required to do with them is normative in the Core Specification [OPF-CORE]. A third record under _op, defined by the Core Specification rather than by this document, is noted in Section 8.4. At the originator's names of this section (Section 8.2, Section 8.4), a verifier under the Core Specification [OPF-CORE] reads an answer reached through an alias, including an alias synthesized from a wildcard CNAME elsewhere in the originator's zone, as it reads an Insecure answer: the originator is unpinned, and a Permitted Host Record is absent. This holds unless the validation state of that answer is Bogus or Indeterminate, which remain failures (Section 6.1). The records at the alias target are never used. Suzuki Expires 26 April 2027 [Page 19] Internet-Draft DNS for Originator Profile October 2026 8.1. SVCB Mapping for _op This subsection is normative. This document is the protocol mapping document required by Section 2.4.3 of [RFC9460] for SVCB records under the _op label (Section 2.3 of [RFC9460]); the underscored name _op is registered for SVCB in Section 9.2, and the entry for op in the URI Schemes registry that Section 11 of [RFC9460] requires of a protocol using SVCB is addressed in Section 9.3. Under this mapping the SvcPriority of a ServiceMode RR carries no meaning beyond distinguishing ServiceMode from AliasMode: the ServiceMode RRs of an RRset are a set of names, and this mapping defines no SvcParams. In one respect the mapping departs from the client behavior of Section 3 of [RFC9460]: the TargetName of an SVCB RR under _op names no service to connect to, so an AliasMode RR is not followed but read as a declaration, and the indication of Section 2.5.1 of [RFC9460], advisory there, is binding under the rules of the Core Specification. What a verifier does with the set, and with an AliasMode RR, including that it does not follow the TargetName of one, is normative in the Core Specification [OPF-CORE] and is described in Section 8.2. 8.2. CP Issuer Pinning at the Originator (SVCB) An originator can publish an SVCB RRset [RFC9460], the Issuer Pinning Record of the Core Specification [OPF-CORE], at _op. under the mapping of Section 8.1. SVCB is used rather than a new RR type because it is an existing type, so that an originator does not wait for its DNS provider to support another allocation, and rather than TXT because SVCB already states, as the meaning of the type, which names provide a service for an owner name, including the declaration that none does (an AliasMode RR with a TargetName of ".", Section 2.5 of [RFC9460]). In ServiceMode, the TargetName of each RR is the FQDN by which a CP issuer that is permitted to issue a CP for this originator is identified (the of Section 3.1), not a name under _op such as _issuer-key._op.; a verifier checks that the CP issuer that issued the CP is one of the CP issuers so named. A ServiceMode RR whose TargetName is "." names no CP issuer (under [RFC9460] it denotes the owner name, _op., which is not the FQDN of a CP issuer), so an RRset consisting only of such RRs pins the originator to an empty set of CP issuers, so every CP fails the check. In AliasMode with a TargetName of "." the originator declares that it has no Originator Profile, and a verifier rejects any CP for it. A verifier does not follow an AliasMode TargetName: Suzuki Expires 26 April 2027 [Page 20] Internet-Draft DNS for Originator Profile October 2026 an RRset that holds an AliasMode RR with any other TargetName, or that holds AliasMode and ServiceMode RRs together, is read as that declaration, and verification fails. A verifier ignores the SvcParams present, except that an RR carrying the mandatory key (Section 8 of [RFC9460]) is unusable, since this mapping defines no key a verifier could recognize; a Secure RRset with no usable RR is a verification failure, not an unpinned originator. Verifiers do not resolve the TargetName to addresses; it is compared, after both have been put in the form the Core Specification defines for domain names, with the CP issuer's FQDN only. Neither this document nor the Core Specification [OPF-CORE] requires the record; a use case specification can require it. The record has effect only where the answer is Secure. Where it is not required, under the Core Specification its absence, when proven Secure, and an Insecure response both leave the originator unpinned: the verifier proceeds without the check and can report that the originator was unpinned. A Bogus response, an Indeterminate result, a resolution failure such as SERVFAIL, and a timeout are verification failures, and none of them leaves the originator unpinned (see Section 11.2). Whether and how the verifier retries is a matter of local policy. 8.3. Revocation Records (TXT) A PA issuer publishes, for each PA it has revoked before the end of the PA's Signature Validity Period, a TXT RRset, the Revocation Record, at ._revocation._op. where stands for the record label, as in Section 3.2. The owner name, the Revocation Record Name, is assigned by the PA issuer when the PA is issued and is carried, as a complete FQDN, in the PA. The record label is opaque, as for Originator Key Records. A verifier checks that the carried name lies below _revocation._op., by the rule of Section 3.2, and then queries it. The presence of a Secure TXT RRset at the name means that the PA has been revoked. A Secure denial of existence (NXDOMAIN or NODATA, treated alike) means that it has not. A Bogus or Insecure response, an Indeterminate result, a resolution failure, or an answer reached through an alias is handled as for OPKEY (Section 6.1): it is a verification failure. The decision otherwise rests on presence alone: the PA is treated as revoked even if the verifier cannot parse the RDATA, so that a malformed record does not silently un-revoke a PA. Suzuki Expires 26 April 2027 [Page 21] Internet-Draft DNS for Originator Profile October 2026 The Core Specification [OPF-CORE] requires every zone that holds a name below _revocation._op. to be signed so that the absence of a name is a Secure proof (with NSEC, or with NSEC3 without the Opt-Out flag): in such a zone an Insecure denial of existence would be a verification failure for every PA whose Revocation Record Name lies in it. It also forbids wildcard records at or below _revocation._op.: a wildcard there would mark every PA revoked. The RDATA consists of a single character-string of the form "v=op1; revoked=