Using Secure DNS for Originator Profile

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 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.<cp-issuer>, 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.<pa-issuer>, 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.<cp-issuer> or _issuer-key._op.<pa-issuer> (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 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.<cp-issuer>. 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.<pa-issuer>. 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.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).¶

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 )

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.<cp-issuer>

and a PA issuer publishes the OPKEY RRset identifying its own signing keys at¶

_issuer-key._op.<pa-issuer>

where <cp-issuer> and <pa-issuer> 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.<cp-issuer> or _issuer-key._op.<pa-issuer> 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.¶

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.<cp-issuer>

The owner name of an Originator Key Record, the Originator Key Record Name, is¶

<record-label>._originator-key._op.<cp-issuer>

where <record-label> 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.<cp-issuer>, where <cp-issuer> 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 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.<cp-issuer> 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.<cp-issuer> 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.¶

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.<cp-issuer> or _issuer-key._op.<pa-issuer>:¶

• 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.<cp-issuer>, or from which an answer at its own _issuer-key._op name could be synthesized. A wildcard at _originator-key._op.<cp-issuer> 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.¶

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<n> \# 35 ( 030101
    c9d1a2f0e3b45c67d8e9f0a1b2c3d4e5f60718293a4b5c6d7e8f90a1b2c3d4e5 )

where <n> 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 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].¶

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.¶

• 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 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.<O>, 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.<I>, 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 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.¶

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.<originator>

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 <cp-issuer> of Section 3.1), not a name under _op such as _issuer-key._op.<cp-issuer>; 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.<originator>, 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: 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¶

<record-label>._revocation._op.<pa-issuer>

where <record-label> 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.<pa-issuer>, 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.¶

The Core Specification [OPF-CORE] requires every zone that holds a name below _revocation._op.<pa-issuer> 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.<pa-issuer>: a wildcard there would mark every PA revoked.¶

The RDATA consists of a single character-string of the form¶

"v=op1; revoked=<time>"

where v=op1 identifies this version of the format and <time> is the time of revocation in the format of [RFC3339]. A verifier can record the time for logging or display but, as above, does not depend on it.¶

A PA issuer keeps a Revocation Record in place until the Signature Validity Period of the revoked PA ends, and then for the clock tolerance that the Core Specification [OPF-CORE] lets a verifier allow. Once that period has ended and that tolerance has passed, the Revocation Record can be removed. A Content Validity Period that the PA states does not change this: the Core Specification requires it to contain the Signature Validity Period, so it ends no earlier. A verifier that finds no Revocation Record for a PA whose Signature Validity Period has ended therefore learns nothing from the absence; such a PA is rejected on its signature alone.¶

8.4. Permitted Host Records (TXT)

The Core Specification [OPF-CORE] defines the Permitted Host Record, a record that binds the presentation of content on a web host to the originator's OP. Where the host is not the originator's FQDN or a name below it, the originator publishes a TXT RRset at¶

<host>._site._op.<originator>

with the RDATA "v=op1"; the Secure presence of a record with that RDATA means that the host is permitted to present content under that OP. The record is mentioned here only to complete the enumeration of names under _op. Its definition, including how a verifier treats it, is given by the Core Specification; whether a verifier queries it at all, and when, is decided by a use case specification, such as those for web media [OPF-WEB-MEDIA] and for email [OPF-EMAIL]. Its use of the TXT type is covered by the registration in Section 9.¶

9.1. OPKEY RRTYPE

This document requests that IANA allocate a value for the OPKEY RRTYPE from the "Resource Record (RR) TYPEs" subregistry of the "Domain Name System (DNS) Parameters" registry, following the procedure of [RFC6895]. The allocation template of Appendix A of [RFC6895], completed for OPKEY except for the date of its posting, is given in Appendix C. Under the Expert Review procedure of [RFC6895], an allocation does not wait for the publication of a document; this document requests that the allocation be made in advance of its publication, so that the period of Section 4.1 is short.¶

9.2. Underscored Name _op

This document requests that IANA add the following entry to the "Underscored and Globally Scoped DNS Node Names" registry [RFC8552]:¶

The sub-labels _issuer-key, _originator-key, _revocation, and _site are used below _op, the first three as defined by this document and _site as defined by the Core Specification [OPF-CORE] (Section 8.4). They do not require registration.¶

9.3. URI Scheme op

Section 11 of [RFC9460] requires that a protocol using SVCB have an entry for its scheme in the "Uniform Resource Identifier (URI) Schemes" registry [RFC7595], besides the entry in the "Underscored and Globally Scoped DNS Node Names" registry that Section 9.2 requests. The name op has no entry in the URI Schemes registry. Its provisional registration under Section 7.2 of [RFC7595] is to be requested separately, with this document as its reference, once this version has been submitted; a later version of this document will record the result. The framework forms no URIs with the scheme; the entry is requested so that the use of SVCB under _op meets the requirements of [RFC9460] in full.¶

10.1. Queries per Verification

The Core Specification [OPF-CORE] has a verifier issue no query until it has verified, locally, the signatures of the documents it holds; the queries that follow do not depend on one another and can be issued in parallel. A verifier with nothing cached then queries:¶

• one Issuer Pinning Record;¶

• the Issuer Key Record of the CP issuer and the Originator Key Record of the CP;¶

• one Issuer Key Record per PA issuer;¶

• one Revocation Record per PA; and¶

• for each step of each accreditation chain, the Issuer Key Record of the accrediting issuer, the Issuer Key Record of the issuer that issued the accredited issuer's CP, and the Revocation Record of the accreditation.¶

In the arrangement in use at the time of writing, one body accredits issuers directly, so that a chain is one step long. A verification of an Originator Profile with one CP and three PAs from three PA issuers, the form expected in the first deployments, then makes 21 queries. It makes 9 once the verifier holds the chains in its cache, which the Core Specification lets it keep per issuer (Section 7.5 of [OPF-CORE]). Each further PA from a PA issuer already present adds one query; each further PA issuer adds five, three of them for its chain.¶

Where accreditation bodies stand between the root and the issuers, as a deployment across countries or regions may arrange, each further step of a chain adds three queries. Two of the three name records that every chain through that body shares. With one such body, the verification above makes 33 queries and names 16 distinct owner names. The bounds the Core Specification places on an Originator Profile, a chain of at most four steps, at most eight PA issuers and thirty-two PAs (Section 7.3 of [OPF-CORE]), give an upper limit of 151 queries, or 43 with the chains cached.¶

The queries name fewer distinct owner names than their number. The Issuer Key Record of the accrediting body is the same name in every chain, and the two Issuer Key Record checks of a chain step name the same record where the same issuer accredits an issuer and issues its CP. In the arrangement in use, the verification with three PAs names 14 distinct owner names. These counts are those of a verifier that relies on its resolver to validate. One that validates DNSSEC itself also queries the DNSKEY RRset of each zone and the DS record of each delegation; in the laboratory of Section 10.6 it issued about two and a half times as many queries to its resolver in the verification with three PAs, and somewhat fewer than twice as many with one accreditation body between the root and the issuers, all of which the resolver answered from its cache after the first verification.¶

A use case specification can add queries of its own: the email use case [OPF-EMAIL] adds the DKIM key and the DMARC policy record of the sending domain, two names; the web media use case [OPF-WEB-MEDIA] adds at most one, the Permitted Host Record. Before the OPKEY type value is allocated, a verifier that finds a Secure proof that no OPKEY RRset exists at a name queries the same name for TLSA (Section 4.3), which adds one query per OPKEY name while a zone publishes the TLSA form only.¶

10.2. What Reaches the Authoritative Servers

The queries reach the authoritative servers through the verifiers' resolvers, which cache each answer for its time to live. From one resolver, each distinct name therefore reaches the authoritative server once per time to live, however many verifications the resolver serves in that period. The Issuer Key Record of an issuer is one name for every originator and every document of that issuer, and the Issuer Key Record of the accrediting body is one name for every chain; what grows with the number of originators is the set of Originator Key Record names, one for each CP verified through that resolver in the period. The load on a CP issuer's servers is thus bounded by the number of resolvers times the number of its originators verified per time to live, not by the number of verifications.¶

At the Revocation Record names, absence is the common answer. A zone signed with NSEC records lets a resolver that performs aggressive negative caching [RFC8198] answer a query for a name in a gap it has already seen without asking the authoritative server again, so that most queries for Revocation Records are answered from the resolver's cache; and while an issuer has published no Revocation Record at all, so that the name under which they would lie does not exist, a resolver that implements [RFC8020] and has seen that name's denial answers for every name below it without a query. In the laboratory of Section 10.6, with one hundred absent Revocation Record names each queried three times, the authoritative server received 27 queries in all with NSEC and aggressive negative caching, counting the resolver's own probes of the intermediate names (the zone apex, _op and _revocation._op) under query name minimisation [RFC9156]. It received about 1,050 with NSEC3, and as many with NSEC when the resolver did not cache negative answers aggressively; most of those were such probes, which a resolver that does not minimise query names, or minimises them with a different query type, did not send: on the first pass over the one hundred names, such resolvers in the same laboratory reached the server about once per name with NSEC3 and 3 to 5 times in all with NSEC, and not at all while the denials were cached. The queries a resolver issues on its own account, for the DNSKEY RRset of each zone, for the DS record of each delegation and for the intermediate names of query name minimisation, add a fixed number per zone, cached for their own time to live. In the same laboratory, the verification of Section 10.1 with three PAs from three PA issuers, which makes 21 queries, caused 59 queries to reach the authoritative servers from an empty resolver cache with zones signed with NSEC, 75 with NSEC3, and none from a warm one; each PA issuer's zone accounts for eight of the 59, and an accreditation body between the root and the issuers for eight more.¶

10.3. Response Sizes

The records of this document are small: the RDATA of an OPKEY RR is 35 octets with Matching Type 1 and 67 with Matching Type 2, whatever the key type, since the record carries a digest and the key itself is in the CP (Section 7); the SVCB and TXT records of Section 8 are of similar size. The size of a response is therefore that of its DNSSEC signatures.¶

With ECDSA P-256 and Ed25519, two of the algorithms recommended for signing ([RFC9904]), all but one of the responses measured among those a verifier receives under this document fit in 1232 octets, the UDP payload size that the resolvers and authoritative servers in common use set by default (Appendix C of [RFC9715]); the exception is noted below. Measured through a validating resolver over test zones signed with ECDSA P-256, a positive answer for one OPKEY RR is 214 octets at an Issuer Key Record name and 255 at the longer name of an Originator Key Record; a denial of existence is 702 octets with NSEC and 821 with NSEC3; and the DNSKEY RRset of a zone with one key is 231 octets. Ed25519 signatures are also 64 octets, so every answer but the DNSKEY RRset has the same size; that RRset is 199 octets, the public key being 32 octets shorter. With ECDSA P-256 the same holds for a zone signed with a KSK and a ZSK, where the DNSKEY RRset is 313 octets (249 with Ed25519), and during a rollover in which a second KSK signs the DNSKEY RRset and a new ZSK is published before it signs, where it is at most 583 octets (455); an OPKEY RRset of six RRs, three keys in both Matching Types, is 549 octets at an Issuer Key Record name and 586 at an Originator Key Record name with one key, and two octets more with a KSK and a ZSK. The one exception measured is a zone signed with NSEC3 while every RRset carries two signatures, as in a ZSK rollover by double signature: a denial of existence that needs three NSEC3 RRs is then 1,259 to 1,274 octets and is fetched again over TCP, while with NSEC it stays at or below 1,055 octets, and a rollover by pre-publication, in which the new key is published before it signs, does not have this effect. With RSA-2048, the third recommended algorithm and the one the root zone signs with, a positive answer still fits, but a denial of existence does not: 1,272 octets with NSEC and 1,584 with NSEC3, so that the common answer of a Revocation Record zone is truncated over UDP and fetched again over TCP.¶

If DNSSEC came to use a post-quantum signature algorithm, the sizes would change for every signed zone, and not for these records in particular. The following is a calculation from the measurements above, not a measurement (Section 10.6). ML-DSA-44, allocated the DNSSEC algorithm number 18 [IANA-DNSSEC-ALG], has a signature of 2420 octets [FIPS204]: a response carrying one RRSIG would exceed 1232 octets, and a denial of existence, which carries three or four, would exceed 4096. A verifier, and the resolver it uses, would then retry over TCP, which [RFC7766] and [RFC9210] already require of every DNS implementation. Two choices of this design would lessen the effect. Keys are identified by digest, so the size of a post-quantum public key never enters an OPKEY response. And at the Revocation Record names, where absence is the common answer, a zone signed with NSEC yields a denial one record and one signature smaller than one signed with NSEC3, and aggressive negative caching keeps most of those denials from reaching the authoritative server at all (Section 10.2); NSEC is the form recommended for such a zone in the deployment of the framework (Section 10.4).¶

10.4. Time to Live and Negative Caching

Nothing in this document requires a time to live shorter than is usual in the DNS. The removal of an OPKEY RR, of an Originator Key Record or of an Issuer Key Record is seen by a verifier within the time to live of the record it replaces or removes, plus the time the issuer takes to make the change. A Revocation Record, and any record published at a name that had none, is seen within the negative caching period of the zone, the lesser of the MINIMUM field of the SOA record and the TTL of the SOA record ([RFC2308], [RFC9077]). That period also bounds, in a zone whose NSEC or NSEC3 records carry the TTL [RFC9077] requires, what a resolver synthesizes from them ([RFC8198]), and it is the period a CP issuer lets pass before it issues a CP that carries a new Originator Key Record Name (Section 3.2). An answer that was true when signed can be replayed until its signatures expire (Section 11.6).¶

The values of these parameters assumed in this section are those recommended for the deployment of the framework: a time to live of one hour and a negative caching period of one hour, and of no more than one day, for the OPKEY, SVCB and TXT records of this document, and a RRSIG validity period of one to two weeks. The deployment also assumes that a CP is issued or renewed about once a year, that a zone holding Revocation Records is signed with NSEC, and that the zone that holds Originator Key Records is signed incrementally. These values and practices belong to the operational requirements that accompany the Core Specification [OPF-OPS], which had not been published when this document was written; they are stated here for that reason, and a later version of this document is expected to refer to them there. In the laboratory of Section 10.6, with a time to live and a negative caching period of 60 seconds, a record added at a name that had none, and the removal of a record, each became visible through a validating resolver within 63 seconds. The resolver was polled every five seconds; NSEC and NSEC3 behaved alike.¶

10.5. Zone Size and Signing Load

A CP issuer's zone holds one Originator Key Record for each CP it has issued and has not revoked (Section 3.2): one OPKEY RRset, with one RR per key and per Matching Type, and the NSEC or NSEC3 record of the name, each with its RRSIG. For an issuer with N originators that holds one CP per originator, the zone holds about 2N RRsets and 2N signatures; while a CP is renewed, the earlier CP and the later one stand side by side, each with its own name, until the earlier record is removed at the end of its retention period, so that the zone is somewhat larger than N names. Measured over a zone of 100,000 such names signed with ECDSA P-256 and NSEC, the signed zone was 67 MB in binary form (87 MB as a zone file), 674 octets per name. Signing it took 55 seconds of elapsed time and 93 seconds of processor time on the server of Section 10.6. The size grows in proportion to the number of names, to 6.7 GB in binary form at ten million names; with a post-quantum algorithm it would grow in proportion to the signature size as well, to about eight times as much with ML-DSA-44.¶

On the same server, signing a zone of one million such names took ten minutes of elapsed time, ten times as long as one hundred thousand, and the signer used 2.3 GB of memory. At ten million names the memory still grew in proportion, to 22 GB, but the time did not: signing took 2 hours and 45 minutes, seventeen times as long as at one million. Loaded into an authoritative server, the zone of one million names occupied between 0.8 and 3 GB of memory, depending on the software and on the form of denial, and the zone of ten million names, signed with NSEC, between 8 and 15 GB; loading the latter took between one and a half and nine minutes. For a name that exists, NSD and Knot DNS each answered between 270,000 and 310,000 queries per second over UDP, and BIND between 180,000 and 200,000; for a name that does not exist, NSD and Knot DNS answered at the same rates or higher, and BIND at about half its rate. The rates for a name that exists did not change between one hundred thousand and ten million names.¶

In the deployment of the framework a CP is issued or renewed on the order of once a year (Section 10.4), so the zone changes by about one name per originator per year. The period can be of that length because revocation does not depend on it: a verifier queries the Originator Key Record of the CP and the Revocation Record of each PA at every verification and fails on anything but a Secure answer (Section 6.1), so a revocation is seen within a time to live or a negative caching period (Section 10.4), whatever the Signature Validity Period of the CP. The steady cost of the zone is a different thing: the renewal of its DNSSEC signatures before they expire, every few days for a validity of one to two weeks, which the signing software performs on its own schedule whatever the CPs. Issuing a CP adds one name, which costs one signature for the RRset and the re-signing of the two NSEC or NSEC3 records that bracket it; revoking a CP removes a name at the same cost. Incremental signing is recommended for the zone that holds Originator Key Records; DNS software provides it, for example, through inline signing in the authoritative server. With incremental signing the cost of one issuance is expected not to depend on the size of the zone, although that was not measured; re-signing the zone file as a whole after each change does depend on it. In the laboratory it took as long as the first signing, or a little longer, up to one million names, and more than an hour and a half at ten million: ten minutes or more for each issuance, which rules out re-signing the whole zone at every issuance for an issuer of that size. A CP issuer that expects many originators can divide its Originator Key Records among several zones (Section 3.2), each signed and delegated, without any change visible to verifiers.¶

10.6. Basis of the Figures

The counts of Section 10.1 follow from the Core Specification [OPF-CORE] and from the use case specifications; an implementation of the Core Specification's procedure, run in the laboratory in the arrangement of that section, with and without an accreditation body between the root and the issuers, made the number of queries the formulas give. The measured figures were taken by the authors in a closed laboratory, with BIND 9.20.29 as the authoritative server, Unbound 1.25.2 as the validating resolver, with query name minimisation and aggressive negative caching enabled, and the dnssec-signzone of BIND 9.20.29 as the signer. The test zones were signed from a private trust anchor and served by one authoritative server behind one resolver, so that no referral was counted and no query reached the public DNS. The figures are not measurements of a deployment: a population of resolvers that share caches, prefetch or serve stale data ([RFC8767]) behaves differently. The sizes under post-quantum algorithms are computed from the measured responses and the sizes of the signatures and keys, those of [FIPS204] as produced by OpenSSL 4.0.3, since the DNS software in the laboratory does not sign with them; how DNSSEC will carry those signatures is not settled, and the sizes will change with it.¶

The zones of the response sizes were sz13.lab.test (ECDSA P-256), sz15.lab.test (Ed25519) and sz8.lab.test (RSA-2048), each signed with NSEC, and the same three signed with NSEC3 as sz13h.lab.test, sz15h.lab.test and sz8h.lab.test; each zone was the signer of its records, with one key. The sizes for a KSK and a ZSK and for rollovers were measured in twenty further zones signed from the same records, with ECDSA P-256 and Ed25519 and with NSEC and NSEC3: one KSK and one ZSK; one KSK and two ZSKs, of which one or both sign; and two KSKs, both signing the DNSKEY RRset, and two ZSKs, of which one or both sign. In the first zone, the Issuer Key Record, the Originator Key Record, with a label of 36 characters, and the absent Revocation Record were at the following names:¶

_issuer-key._op.sz13.lab.test.
7f3e1c2a-9b4d-4e8f-a1c5-2d6b8e0f4a01._originator-key._op.sz13.lab.test.
3a9f6d1e-5c2b-4a7e-9e0d-b4f1c8a2e6d8._revocation._op.sz13.lab.test.

For a longer zone name, a response grows by the added length in the query name and in each name that message compression does not shorten, such as the signer name of each RRSIG. The zones of Section 10.5 were named cpi.example, with one Originator Key Record per name under _originator-key._op.cpi.example.¶

The times, the memory and the rates of Section 10.5 were taken on a server with two Intel Xeon E5645 processors of 2010, twelve cores and twenty-four threads in all, 47 GB of memory and hard disks, running Debian 13, with the dnssec-signzone of BIND 9.20.29 as the signer. Zones of up to one million names were signed on a memory-backed file system; the zone of ten million names was signed on the hard disks, which had added about two percent to the time at one million names. BIND 9.20.29, NSD 4.12.0 and Knot DNS 3.4.6 served the zones from memory, and dnsperf 2.14.0, run on the same server, generated the load, so that the rates are comparable among themselves and not an upper bound for the hardware. The counts, the response sizes, the visibility times of Section 10.4 and the sizes of the signed zones do not depend on the machine; the first three were taken in the laboratory described above, whose servers ran in containers, and the signed zones were of the same size in binary form, to the octet, in the laboratory and on the server.¶

11.1. Dependence on DNSSEC

Everything in this document depends on DNSSEC. Without DNSSEC an OPKEY RRset can be forged or suppressed by anyone on the resolution path, and a verifier that accepted an Insecure RRset would be accepting a key with no more assurance than the CP already provides. This is why Section 6 requires Secure validation and treats every outcome other than Secure as failure. It also means that a CP issuer or PA issuer can operate only under a name below which DS records can be published at every zone cut (Section 3).¶

A verifier within browsing software, such as a browser extension, cannot rely on the resolution that the browsing software performs for its own purposes, which does not in general validate DNSSEC. The web media use case specification [OPF-WEB-MEDIA] therefore has such a verifier carry a validator of its own or an authenticated channel to a validating resolver, the two means of Section 6.1.¶

The operators of the zones involved (the CP issuer's zone and each PA issuer's zone) are trusted parties: whoever controls a zone controls the keys it asserts. The security of the zone's DNSSEC keys, of its provisioning interface, and of the registration of the domain name itself (a CP issuer or PA issuer is identified by its name, so a transfer of the name transfers everything under it) is therefore part of the security of the Originator Profile Framework. The corresponding requirements are operational and are not specified here.¶

At the names of a CP issuer or PA issuer an answer reached through an alias is a verification failure (Section 6.1), so a zone operator cannot move the authority over these names to a zone it does not control by publishing a CNAME or DNAME; without that rule the check of Section 3.2 that a carried name lies below the CP issuer's node would be defeated at the DNS layer.¶

11.2. Pinning and Resolution Failures

Pinning is the originator's choice. An originator that publishes no SVCB record at _op.<originator> has simply not pinned, and a verifier proceeds without the check; nothing in this document treats that as a weakness. The concern of this section is an originator that has pinned, and the assurance it gets from doing so. If a verifier treated a failed query like a proven absence, an attacker holding a CP for the originator from a CP issuer other than the pinned one could clear the pin by merely disrupting the resolution of the SVCB record, and the pin would protect nothing. This is why the Core Specification, as Section 8 describes, keeps the two cases apart: a Secure denial of existence, and an Insecure response for which DNSSEC vouches neither way, lead to the unpinned path, while a SERVFAIL, a timeout, a Bogus response, and an Indeterminate result are failures. An originator that pins can thus rely on its pin being removable only by a change to its own zone, apart from the replay of an earlier Secure answer from that zone until the signatures on it expire (Section 11.6).¶

This holds only for a verifier that knows its resolver validates. A resolver that does not validate, or a path on which the AD bit is cleared before the answer reaches the verifier, makes every answer appear Insecure, and at _op.<originator> an Insecure answer leads to the unpinned path. Section 6.1 therefore requires that assurance.¶

This document does not require pinning, but an originator whose zone is signed is advised to pin: for such an originator the record costs nothing more than publishing it, and it closes the way in which a CP from another CP issuer could be presented for the originator.¶

A wildcard or a DNAME [RFC6672] in an originator's zone can make _op.<originator> answer through an alias when no record exists there; such an answer, Secure or Insecure, leaves the originator unpinned, as an Insecure answer does, and it cannot remove a pin, since a pinned originator has a record at that name: a wildcard does not reach a name that exists, and no name can exist below a DNAME.¶

11.3. Response Size

OPKEY responses are small, since they carry digests only. Responses that carry the RRs of several keys at one name, together with their DNSSEC signatures, can still be large; large responses over UDP invite truncation and fragmentation. Section 10.3 gives the sizes measured with the signature algorithms recommended for signing today, and computes what a post-quantum algorithm would add.¶

11.4. Digest Agility

Each OPKEY RR names its digest algorithm in its Matching Type. Should SHA-256 come to be weakened, a record publisher can publish, for every key, RRs of Matching Type 2 beside those of Matching Type 1 (Section 5), and a verifier that supports Matching Type 2 then selects it (Section 6.2); the Matching Type 1 RRs remain for the verifiers that support only that. A further digest algorithm would be added in the same way, by a revision of this document that permits a further Matching Type of the TLSA registry [RFC6698]. An attacker cannot make a verifier select a weaker Matching Type by removing RRs from an RRset without breaking its DNSSEC signature.¶

11.5. Availability

Verification fails closed. A verifier that cannot obtain a Secure answer, because resolution fails, because the DNSSEC signatures of an issuer's zone have expired, or because the registration of the issuer's name has lapsed, fails every verification that depends on that zone (Section 6.1). An outage of a CP issuer's zone thus stops the verification of the content of every originator to which it has issued a CP, and an outage of a PA issuer's zone that of every PA it has issued. This is a choice of the design: reading such a failure as an absence would let anyone able to disrupt resolution hide a revocation or clear a pin (Section 11.2). It is mitigated by the ordinary means of DNS availability: several authoritative servers in different networks, signatures renewed well before they expire, and times to live that let resolvers answer from their caches through a short outage (Section 10.4).¶

11.6. Removed Keys and Caching

When the OPKEY RRs for a key are removed from an RRset, verifiers that hold the previous RRset in cache continue to accept the key until the TTL expires. Likewise, the RRSIG validity period bounds how long a previously captured, still-signed RRset can be replayed to a verifier that does not see the current zone; this includes a denial of existence at a Revocation Record Name, whose replay hides a revocation, and, at _op.<originator>, a proof that no SVCB RRset existed there or an earlier answer naming a previous CP issuer, whose replay unpins the originator or lets a CP from that previous CP issuer be accepted (Section 11.2). A resolver that serves stale data [RFC8767] when the authoritative server is unreachable can extend this further. In the other direction, a resolver that has cached a denial of existence [RFC2308] does not see a record added after the denial was cached, such as the OPKEY RR for a new key or a Revocation Record (Section 8.3), until the negative cache entry expires; a resolver that synthesizes negative answers from cached NSEC or NSEC3 records [RFC8198] can answer negatively, from an earlier proof, for a name it has never queried, including a name at which a record has since been added. How these windows are matched to the application's needs, by the choice of TTLs, of RRSIG validity periods, and of when the RRs for a key that is no longer in use are removed, is an operational matter, addressed in the operational documents that accompany the Core Specification [OPF-CORE] (Section 10.4).¶

11.7. Information Exposure

Queries for Originator Key Records reach the CP issuer's authoritative servers, in aggregate, through recursive resolvers. The CP issuer can thus observe, per originator, that verification is taking place, in the same way that any zone operator observes queries for its names. Individual verifiers are not identified by the query, and the originator does not see the queries. The record label is opaque in that it is not derived from the originator's name, so an observer of DNS traffic alone learns that some Originator Key Record is being queried, not which originator it belongs to. The label is not secret: it is carried in the CP, and a CP is published with the content it accompanies, so an observer that has collected CPs can map labels to originators. The opacity limits what passive observation of the DNS reveals; it is not confidentiality, and it is no protection against the CP issuer, which assigned the label.¶

What holds at the authoritative servers does not hold at the verifier's own resolver. That resolver receives each query from the verifier, and so sees which Originator Key Record Names and Revocation Record Names a given verifier looks up, and when. Since the labels can be mapped to originators from the CPs, and a verifier within browsing software queries when its user reads content, these queries tell the operator of that resolver what the user reads, as the web media use case specification notes [OPF-WEB-MEDIA]. A resolver that sends the EDNS Client Subnet option [RFC7871] passes part of the verifier's address on to the authoritative servers of the CP issuer and the PA issuers as well. Which resolver a verifier uses, whether it reaches that resolver over an encrypted channel such as DNS over TLS [RFC7858] or DNS over HTTPS [RFC8484], and whether that resolver sends the Client Subnet option, are choices of the use case specification and of the implementation; this document does not constrain them.¶

Until its signature is verified, the record names and issuer names a document carries are, for all the verifier knows, chosen by an arbitrary party. A verifier that queried them before verifying the signature would reveal, to the zone they point at, that the document reached it, and could be made to query any name; this is why Section 6 requires the signature to be verified first.¶

A CP issuer's Originator Key Records are enumerable through DNSSEC denial of existence unless the record labels have sufficient entropy and NSEC3 [RFC5155] is used, or minimally covering NSEC records with online signing [RFC4470] [RFC7129] are used. NSEC3 is used without the Opt-Out flag: the Core Specification [OPF-CORE] requires that the absence of a name below _op.<cp-issuer> or _op.<pa-issuer> be a Secure proof, which an Opt-Out denial is not (Section 9.2 of [RFC5155]), and reads such a denial as a failure. Which of the two forms the zone of a CP issuer or PA issuer uses is a choice of its operator; Section 10.2 gives the reason to prefer NSEC where absence is the common answer. NSEC3 only raises the cost of enumeration to that of an offline dictionary attack, which the random bits of a UUID of version 4 defeat but a guessable label does not; and the number of Originator Key Records remains observable in either case. Enumeration yields opaque labels and key digests, not originator names. Whether that exposure matters is for the CP issuer to decide.¶

11.8. Transitional TLSA Records

The TLSA records permitted by Section 4.1 use the TLSA type outside the semantics of [RFC6698]. They are placed under _op, not at the owner names at which TLSA records for TLS are placed, so they cannot be mistaken for TLS associations. A verifier that has fallen back to TLSA applies exactly the same checks as for OPKEY (Section 4.3). This use is transitional. The OPKEY RR type is requested at the outset; once the value exists, the form used is OPKEY itself (in the generic representation of [RFC3597] where necessary), and TLSA is limited to the period before the value exists.¶

12.1. Normative References

[RFC1034]

Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, <https://www.rfc-editor.org/rfc/rfc1034>.

[RFC1035]

Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, November 1987, <https://www.rfc-editor.org/rfc/rfc1035>.

[RFC2119]

Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/rfc/rfc2119>.

[RFC2308]

Andrews, M., "Negative Caching of DNS Queries (DNS NCACHE)", RFC 2308, DOI 10.17487/RFC2308, March 1998, <https://www.rfc-editor.org/rfc/rfc2308>.

[RFC3279]

Bassham, L., Polk, W., and R. Housley, "Algorithms and Identifiers for the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 3279, DOI 10.17487/RFC3279, May 2002, <https://www.rfc-editor.org/rfc/rfc3279>.

[RFC3597]

Gustafsson, A., "Handling of Unknown DNS Resource Record (RR) Types", RFC 3597, DOI 10.17487/RFC3597, September 2003, <https://www.rfc-editor.org/rfc/rfc3597>.

[RFC4033]

Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "DNS Security Introduction and Requirements", RFC 4033, DOI 10.17487/RFC4033, March 2005, <https://www.rfc-editor.org/rfc/rfc4033>.

[RFC4034]

Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "Resource Records for the DNS Security Extensions", RFC 4034, DOI 10.17487/RFC4034, March 2005, <https://www.rfc-editor.org/rfc/rfc4034>.

[RFC4035]

Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "Protocol Modifications for the DNS Security Extensions", RFC 4035, DOI 10.17487/RFC4035, March 2005, <https://www.rfc-editor.org/rfc/rfc4035>.

[RFC4592]

Lewis, E., "The Role of Wildcards in the Domain Name System", RFC 4592, DOI 10.17487/RFC4592, July 2006, <https://www.rfc-editor.org/rfc/rfc4592>.

[RFC5155]

Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS Security (DNSSEC) Hashed Authenticated Denial of Existence", RFC 5155, DOI 10.17487/RFC5155, March 2008, <https://www.rfc-editor.org/rfc/rfc5155>.

[RFC5280]

Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, <https://www.rfc-editor.org/rfc/rfc5280>.

[RFC5480]

Turner, S., Brown, D., Yiu, K., Housley, R., and T. Polk, "Elliptic Curve Cryptography Subject Public Key Information", RFC 5480, DOI 10.17487/RFC5480, March 2009, <https://www.rfc-editor.org/rfc/rfc5480>.

[RFC6698]

Hoffman, P. and J. Schlyter, "The DNS-Based Authentication of Named Entities (DANE) Transport Layer Security (TLS) Protocol: TLSA", RFC 6698, DOI 10.17487/RFC6698, August 2012, <https://www.rfc-editor.org/rfc/rfc6698>.

[RFC7517]

Jones, M., "JSON Web Key (JWK)", RFC 7517, DOI 10.17487/RFC7517, May 2015, <https://www.rfc-editor.org/rfc/rfc7517>.

[RFC7518]

Jones, M., "JSON Web Algorithms (JWA)", RFC 7518, DOI 10.17487/RFC7518, May 2015, <https://www.rfc-editor.org/rfc/rfc7518>.

[RFC8017]

Moriarty, K., Ed., Kaliski, B., Jonsson, J., and A. Rusch, "PKCS #1: RSA Cryptography Specifications Version 2.2", RFC 8017, DOI 10.17487/RFC8017, November 2016, <https://www.rfc-editor.org/rfc/rfc8017>.

[RFC8174]

Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.

[RFC8552]

Crocker, D., "Scoped Interpretation of DNS Resource Records through "Underscored" Naming of Attribute Leaves", BCP 222, RFC 8552, DOI 10.17487/RFC8552, March 2019, <https://www.rfc-editor.org/rfc/rfc8552>.

[RFC9460]

Schwartz, B., Bishop, M., and E. Nygren, "Service Binding and Parameter Specification via the DNS (SVCB and HTTPS Resource Records)", RFC 9460, DOI 10.17487/RFC9460, November 2023, <https://www.rfc-editor.org/rfc/rfc9460>.

12.2. Informative References

[FIPS204]

National Institute of Standards and Technology, "Module-Lattice-Based Digital Signature Standard", FIPS 204, August 2024, <https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.204.pdf>.

[IANA-DNSSEC-ALG]

IANA, "Domain Name System Security (DNSSEC) Algorithm Numbers", n.d., <https://www.iana.org/assignments/dns-sec-alg-numbers/dns-sec-alg-numbers.xhtml>.

[OPF-AOV]

Suzuki, S. and M. Kuriyama, "Originator Profile Framework: Architectural Overview", Work in Progress, 27 October 2026, <https://docs.originator-profile.org/aov/>.

[OPF-CORE]

Suzuki, S., "Originator Profile Framework: Core Specification", Work in Progress, 27 October 2026, <https://docs.originator-profile.org/core/>.

[OPF-EMAIL]

Suzuki, S., "Originator Profile Framework: Email Use Case Specification", Work in Progress, 27 October 2026, <https://docs.originator-profile.org/email/>.

[OPF-OPS]

Suzuki, S., "Originator Profile Framework: Operations", Work in Progress (not yet published), 2026.

[OPF-WEB-MEDIA]

Suzuki, S., "Originator Profile Framework: Web Media Use Case Specification", Work in Progress, 27 October 2026, <https://docs.originator-profile.org/web-media/>.

[RFC3339]

Klyne, G. and C. Newman, "Date and Time on the Internet: Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002, <https://www.rfc-editor.org/rfc/rfc3339>.

[RFC4470]

Weiler, S. and J. Ihren, "Minimally Covering NSEC Records and DNSSEC On-line Signing", RFC 4470, DOI 10.17487/RFC4470, April 2006, <https://www.rfc-editor.org/rfc/rfc4470>.

[RFC6672]

Rose, S. and W. Wijngaards, "DNAME Redirection in the DNS", RFC 6672, DOI 10.17487/RFC6672, June 2012, <https://www.rfc-editor.org/rfc/rfc6672>.

[RFC6895]

Eastlake 3rd, D., "Domain Name System (DNS) IANA Considerations", BCP 42, RFC 6895, DOI 10.17487/RFC6895, April 2013, <https://www.rfc-editor.org/rfc/rfc6895>.

[RFC7129]

Gieben, R. and W. Mekking, "Authenticated Denial of Existence in the DNS", RFC 7129, DOI 10.17487/RFC7129, February 2014, <https://www.rfc-editor.org/rfc/rfc7129>.

[RFC7218]

Gudmundsson, O., "Adding Acronyms to Simplify Conversations about DNS-Based Authentication of Named Entities (DANE)", RFC 7218, DOI 10.17487/RFC7218, April 2014, <https://www.rfc-editor.org/rfc/rfc7218>.

[RFC7595]

Thaler, D., Ed., Hansen, T., and T. Hardie, "Guidelines and Registration Procedures for URI Schemes", BCP 35, RFC 7595, DOI 10.17487/RFC7595, June 2015, <https://www.rfc-editor.org/rfc/rfc7595>.

[RFC7638]

Jones, M. and N. Sakimura, "JSON Web Key (JWK) Thumbprint", RFC 7638, DOI 10.17487/RFC7638, September 2015, <https://www.rfc-editor.org/rfc/rfc7638>.

[RFC7671]

Dukhovni, V. and W. Hardaker, "The DNS-Based Authentication of Named Entities (DANE) Protocol: Updates and Operational Guidance", RFC 7671, DOI 10.17487/RFC7671, October 2015, <https://www.rfc-editor.org/rfc/rfc7671>.

[RFC7766]

Dickinson, J., Dickinson, S., Bellis, R., Mankin, A., and D. Wessels, "DNS Transport over TCP - Implementation Requirements", RFC 7766, DOI 10.17487/RFC7766, March 2016, <https://www.rfc-editor.org/rfc/rfc7766>.

[RFC7858]

Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D., and P. Hoffman, "Specification for DNS over Transport Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May 2016, <https://www.rfc-editor.org/rfc/rfc7858>.

[RFC7871]

Contavalli, C., van der Gaast, W., Lawrence, D., and W. Kumari, "Client Subnet in DNS Queries", RFC 7871, DOI 10.17487/RFC7871, May 2016, <https://www.rfc-editor.org/rfc/rfc7871>.

[RFC7929]

Wouters, P., "DNS-Based Authentication of Named Entities (DANE) Bindings for OpenPGP", RFC 7929, DOI 10.17487/RFC7929, August 2016, <https://www.rfc-editor.org/rfc/rfc7929>.

[RFC7942]

Sheffer, Y. and A. Farrel, "Improving Awareness of Running Code: The Implementation Status Section", BCP 205, RFC 7942, DOI 10.17487/RFC7942, July 2016, <https://www.rfc-editor.org/rfc/rfc7942>.

[RFC8020]

Bortzmeyer, S. and S. Huque, "NXDOMAIN: There Really Is Nothing Underneath", RFC 8020, DOI 10.17487/RFC8020, November 2016, <https://www.rfc-editor.org/rfc/rfc8020>.

[RFC8162]

Hoffman, P. and J. Schlyter, "Using Secure DNS to Associate Certificates with Domain Names for S/MIME", RFC 8162, DOI 10.17487/RFC8162, May 2017, <https://www.rfc-editor.org/rfc/rfc8162>.

[RFC8198]

Fujiwara, K., Kato, A., and W. Kumari, "Aggressive Use of DNSSEC-Validated Cache", RFC 8198, DOI 10.17487/RFC8198, July 2017, <https://www.rfc-editor.org/rfc/rfc8198>.

[RFC8310]

Dickinson, S., Gillmor, D., and T. Reddy, "Usage Profiles for DNS over TLS and DNS over DTLS", RFC 8310, DOI 10.17487/RFC8310, March 2018, <https://www.rfc-editor.org/rfc/rfc8310>.

[RFC8484]

Hoffman, P. and P. McManus, "DNS Queries over HTTPS (DoH)", RFC 8484, DOI 10.17487/RFC8484, October 2018, <https://www.rfc-editor.org/rfc/rfc8484>.

[RFC8767]

Lawrence, D., Kumari, W., and P. Sood, "Serving Stale Data to Improve DNS Resiliency", RFC 8767, DOI 10.17487/RFC8767, March 2020, <https://www.rfc-editor.org/rfc/rfc8767>.

[RFC9077]

van Dijk, P., "NSEC and NSEC3: TTLs and Aggressive Use", RFC 9077, DOI 10.17487/RFC9077, July 2021, <https://www.rfc-editor.org/rfc/rfc9077>.

[RFC9156]

Bortzmeyer, S., Dolmans, R., and P. Hoffman, "DNS Query Name Minimisation to Improve Privacy", RFC 9156, DOI 10.17487/RFC9156, November 2021, <https://www.rfc-editor.org/rfc/rfc9156>.

[RFC9210]

Kristoff, J. and D. Wessels, "DNS Transport over TCP - Operational Requirements", BCP 235, RFC 9210, DOI 10.17487/RFC9210, March 2022, <https://www.rfc-editor.org/rfc/rfc9210>.

[RFC9562]

Davis, K., Peabody, B., and P. Leach, "Universally Unique IDentifiers (UUIDs)", RFC 9562, DOI 10.17487/RFC9562, May 2024, <https://www.rfc-editor.org/rfc/rfc9562>.

[RFC9715]

Fujiwara, K. and P. Vixie, "IP Fragmentation Avoidance in DNS over UDP", RFC 9715, DOI 10.17487/RFC9715, January 2025, <https://www.rfc-editor.org/rfc/rfc9715>.

[RFC9904]

Hardaker, W. and W. Kumari, "DNSSEC Cryptographic Algorithm Recommendation Update Process", RFC 9904, DOI 10.17487/RFC9904, November 2025, <https://www.rfc-editor.org/rfc/rfc9904>.