]> Keio University / OP-CIP / WIDE Project

shigeya@wide.ad.jp

Originator Profile DNS DNSSEC DANE OPKEY 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.

Introduction The Originator Profile Framework (OPF) , 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 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 . 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 that this document registers (). The OPKEY RDATA has the same wire and presentation format as the TLSA record . A separate RR type is used rather than TLSA itself so that the semantics of the two records stay distinct, as does for S/MIME with a type that also shares the TLSA format, and as 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 ) are published in the TLSA form of . 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 and for 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. The rest of this document is organized as follows. defines the OPKEY RR. 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. covers publication before the DNS software in use recognizes the new type, and lists what record publishers and verifiers are required to support. specifies how a verifier uses the records, discusses their size in the DNS, and 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. 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 ; 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 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 .

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

Terminology The DNS terminology of and 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 and .

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 (, ). Which roles an entity holds is stated by the Originator Profile Framework , 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 defines it.

Content Validity Period:

A period that a PA can state for what it states, which contains the PA's Signature Validity Period .

Issuer Key Record:

The OPKEY RRset at _issuer-key._op.<cp-issuer> or _issuer-key._op.<pa-issuer> (). It identifies, by the digests of their SubjectPublicKeyInfo (), 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 (), 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 (). 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 ().

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

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 (). 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 . 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 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, although this document fixes the values of two of them, so that the RDATA has the wire format of TLSA: the TLSA form of then carries the same RDATA, and existing tools for TLSA records can produce and read it.

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 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 also defines 0 (no hash; the full SubjectPublicKeyInfo). The Originator Profile Framework does not use Matching Type 0 . 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 ().

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 , 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 calls TLSA records with unsupported parameters unusable. The remaining RRs of the RRset are used for matching as described in . 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 ().

Key Representation The Certificate Association Data is computed over the DER encoding of the SubjectPublicKeyInfo (SPKI) structure defined in , 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 . 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 ; for an RSA key it is the rsaEncryption AlgorithmIdentifier with the RSAPublicKey structure of , as specified in . The JWK parameters of these two key types are defined in . 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 , which MUST NOT be used as Certificate Association Data.

Presentation Format The presentation format of the OPKEY RDATA is the same as that of the TLSA RDATA (Section 2.2 of ). The mnemonics for the Certificate Usage, Selector, and Matching Type fields defined in 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:

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.<name>, and the names below _originator-key._op.<name> or _revocation._op.<name>, respectively) do not collide with the records a party publishes about itself as an originator (), which are at _op.<name> (the Issuer Pinning Record) and below _site._op.<name>. A party that is both an originator and a CP issuer or PA issuer publishes all of them under its one _op.<name>. This document defines two locations for OPKEY records, and then states what a record publisher does not place at these names (). 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 without the Opt-Out flag, and securely delegated, so that a chain of trust leads to it from the root zone and the absence of a name in it is a Secure proof (). An OPKEY RRset in an unsigned zone yields an Insecure response, which is a verification failure (); a CP issuer or PA issuer therefore needs a name under which DS records can be published at each zone cut ().

Records for the Keys of CP Issuers and PA Issuers A CP issuer publishes the OPKEY RRset identifying its own signing keys at ]]> and a PA issuer publishes the OPKEY RRset identifying its own signing keys at ]]> 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 (); the key itself is carried in the document and is not obtained from the DNS.

Originator Key Records A CP issuer publishes one OPKEY RRset, the Originator Key Record, for each CP it has issued, under ]]> The owner name of an Originator Key Record, the Originator Key Record Name, is ._originator-key._op. ]]> where <record-label> stands for the record label, the opaque label that the CP issuer assigns to the CP (a UUID, as described below; 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 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 () pass, before it issues the CP that carries its name, as the Core Specification 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 ; 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 requires; an Originator Key Record in an unsigned zone yields an Insecure response, which is a verification failure (). 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 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, ).

Semantics of Presence and Absence An OPKEY RRset is published either as an Originator Key Record () or as the Issuer Key Record of a CP issuer or PA issuer (). 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, ) 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 (). 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, ) 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.

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 (). 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 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 ), but this document does not ask verifiers to distinguish it, since the harm of a wildcard falls on the record publisher that placed it.

Transitional Publication Deploying a new RR type takes time. Two periods are distinguished, separated by the allocation of the OPKEY type value ().

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 requires the value, and DNS software has no mnemonic to recognize. A value from the private-use range of 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 at the owner name at which the OPKEY RRset will be published. The TLSA RRset carries no meaning under . 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 is made before any record publisher deploys, this period is empty and the TLSA form is never used.

After the Type Value Is Allocated Once the type value is allocated, OPKEY is handled as an unknown type, as specified in , 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 where the mnemonic is not accepted. The record of is then written as \# 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 (). 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 . 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.

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 (). 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 , 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 .

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 ) and reject a key that the 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 (). 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.

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 defines; the DNS checks on that key () 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 (). A verifier builds the names it queries from the FQDNs that the documents carry, in the form the Core Specification defines for domain names (); under the Core Specification, an FQDN that cannot be put in that form is a verification failure.

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 ): for example DNS over TLS under the Strict Privacy profile of , DNS over HTTPS , 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 ().
• An Indeterminate result, one for which the verifier could not determine the validation state (Section 5 of ), 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 ().
• A Secure denial of existence (NXDOMAIN or NODATA) means that the RRset is absent. Verifiers MUST treat NXDOMAIN and NODATA alike.

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 ().
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 (), 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 . 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 (). 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 (); this document defines only the Matching Types in which a digest can appear in the DNS.

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 (), 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 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 . 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.

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 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 (); for a CP, that check is part of . 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 . The only further OPKEY lookups these checks involve are applications of the same rule at each CP issuer and PA issuer in the chain.

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 ). The consequences of caching for the detection of removed keys are discussed in ; the choice of TTL values is an operational matter.

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 (). What a post-quantum DNSSEC signature algorithm would do to the size of the responses is computed in .

Other Records under _op This section is informative, except for , 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 () 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 . A third record under _op, defined by the Core Specification rather than by this document, is noted in . At the originator's names of this section (, ), a verifier under the Core Specification 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 (). The records at the alias target are never used.

SVCB Mapping for _op This subsection is normative. This document is the protocol mapping document required by Section 2.4.3 of for SVCB records under the _op label (Section 2.3 of ); the underscored name _op is registered for SVCB in , and the entry for op in the URI Schemes registry that Section 11 of requires of a protocol using SVCB is addressed in . 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 : 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 , 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 and is described in .

CP Issuer Pinning at the Originator (SVCB) An originator can publish an SVCB RRset , the Issuer Pinning Record of the Core Specification , at ]]> under the mapping of . 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 ). 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 ), 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 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 ) 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 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 ). Whether and how the verifier retries is a matter of local policy.

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 <record-label> stands for the record label, as in . 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 , 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 (): 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 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 " ]]> where v=op1 identifies this version of the format and <time> is the time of revocation in the format of . 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 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.

Permitted Host Records (TXT) The Core Specification 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 ._site._op. ]]> 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 and for email . Its use of the TXT type is covered by the registration in .

IANA Considerations

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 . The allocation template of Appendix A of , completed for OPKEY except for the date of its posting, is given in . Under the Expert Review procedure of , 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 is short.

Underscored Name _op This document requests that IANA add the following entry to the "Underscored and Globally Scoped DNS Node Names" registry :

RR Type	_NODE NAME	Reference
OPKEY	_op	(this document)
SVCB	_op	(this document)
TXT	_op	(this document)

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 (). They do not require registration.

URI Scheme op Section 11 of requires that a protocol using SVCB have an entry for its scheme in the "Uniform Resource Identifier (URI) Schemes" registry , besides the entry in the "Underscored and Globally Scoped DNS Node Names" registry that requests. The name op has no entry in the URI Schemes registry. Its provisional registration under Section 7.2 of 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 in full.

Operational Considerations This section is informative. It estimates what the records of this document ask of the DNS: how many queries a verification makes, how large the responses are, how the time-to-live values and negative caching bound what a verifier sees, and what signing an issuer's zone costs. The counts and the sizes follow from the design; where a figure was measured, says how. Figures for a deployment of a given scale are orders of magnitude, not predictions. The section also computes, as a calculation and not a measurement, how much larger the responses would be if DNSSEC came to use a post-quantum signature algorithm; nothing in this document depends on that case. The times, the memory and the query rates were measured on a server of the generation of 2010 (). They are to be measured again on a current server, on which the times are expected to be shorter; until then, they show the order of magnitude and how each grows with the number of names in a zone. The query counts and the response sizes do not depend on the machine.

Queries per Verification The Core Specification 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 of ). 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 of ), 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 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 adds the DKIM key and the DMARC policy record of the sending domain, two names; the web media use case 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 (), which adds one query per OPKEY name while a zone publishes the TLSA form only.

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 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 and has seen that name's denial answers for every name below it without a query. In the laboratory of , 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 . 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 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.

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 (); the SVCB and TXT records of 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 (), 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 (); 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 (). ML-DSA-44, allocated the DNSSEC algorithm number 18 , has a signature of 2420 octets : 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 and 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 (); NSEC is the form recommended for such a zone in the deployment of the framework ().

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 (, ). That period also bounds, in a zone whose NSEC or NSEC3 records carry the TTL requires, what a resolver synthesizes from them (), and it is the period a CP issuer lets pass before it issues a CP that carries a new Originator Key Record Name (). An answer that was true when signed can be replayed until its signatures expire (). 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 , 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 , 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.

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 (): 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 . 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 (), 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 (), so a revocation is seen within a time to live or a negative caching period (), 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 (), each signed and delegated, without any change visible to verifiers.

Basis of the Figures The counts of follow from the Core Specification 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 () behaves differently. The sizes under post-quantum algorithms are computed from the measured responses and the sizes of the signatures and keys, those of 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: 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 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 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 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.

Security Considerations

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 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 (). 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 therefore has such a verifier carry a validator of its own or an authenticated channel to a validating resolver, the two means of . 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 (), 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 that a carried name lies below the CP issuer's node would be defeated at the DNS layer.

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 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 (). 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. 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 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.

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. gives the sizes measured with the signature algorithms recommended for signing today, and computes what a post-quantum algorithm would add.

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 (), and a verifier that supports Matching Type 2 then selects it (); 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 . An attacker cannot make a verifier select a weaker Matching Type by removing RRs from an RRset without breaking its DNSSEC signature.

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 (). 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 (). 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 ().

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 (). A resolver that serves stale data when the authoritative server is unreachable can extend this further. In the other direction, a resolver that has cached a denial of existence does not see a record added after the denial was cached, such as the OPKEY RR for a new key or a Revocation Record (), until the negative cache entry expires; a resolver that synthesizes negative answers from cached NSEC or NSEC3 records 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 ().

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 . A resolver that sends the EDNS Client Subnet option 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 or DNS over HTTPS , 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 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 is used, or minimally covering NSEC records with online signing are used. NSEC3 is used without the Opt-Out flag: the Core Specification 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 ), 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; 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.

Transitional TLSA Records The TLSA records permitted by use the TLSA type outside the semantics of . 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 (). 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 where necessary), and TLSA is limited to the period before the value exists.

References Normative References This RFC is the revised basic definition of The Domain Name System. It obsoletes RFC-882. This memo describes the domain style names and their used for host address look up and electronic mail forwarding. It discusses the clients and servers in the domain name system and the protocol used between them. This RFC is the revised specification of the protocol and format used in the implementation of the Domain Name System. It obsoletes RFC-883. This memo documents the details of the domain name client - server communication. RFC1034 provided a description of how to cache negative responses. It however had a fundamental flaw in that it did not allow a name server to hand out those cached responses to other resolvers, thereby greatly reducing the effect of the caching. This document addresses issues raise in the light of experience and replaces RFC1034 Section 4.3.4. [STANDARDS-TRACK] This document specifies algorithm identifiers and ASN.1 encoding formats for digital signatures and subject public keys used in the Internet X.509 Public Key Infrastructure (PKI). Digital signatures are used to sign certificates and certificate revocation list (CRLs). Certificates include the public key of the named subject. [STANDARDS-TRACK] Extending the Domain Name System (DNS) with new Resource Record (RR) types currently requires changes to name server software. This document specifies the changes necessary to allow future DNS implementations to handle new RR types transparently. [STANDARDS-TRACK] The Domain Name System Security Extensions (DNSSEC) add data origin authentication and data integrity to the Domain Name System. This document introduces these extensions and describes their capabilities and limitations. This document also discusses the services that the DNS security extensions do and do not provide. Last, this document describes the interrelationships between the documents that collectively describe DNSSEC. [STANDARDS-TRACK] This document is part of a family of documents that describe the DNS Security Extensions (DNSSEC). The DNS Security Extensions are a collection of resource records and protocol modifications that provide source authentication for the DNS. This document defines the public key (DNSKEY), delegation signer (DS), resource record digital signature (RRSIG), and authenticated denial of existence (NSEC) resource records. The purpose and format of each resource record is described in detail, and an example of each resource record is given. This document obsoletes RFC 2535 and incorporates changes from all updates to RFC 2535. [STANDARDS-TRACK] This document is part of a family of documents that describe the DNS Security Extensions (DNSSEC). The DNS Security Extensions are a collection of new resource records and protocol modifications that add data origin authentication and data integrity to the DNS. This document describes the DNSSEC protocol modifications. This document defines the concept of a signed zone, along with the requirements for serving and resolving by using DNSSEC. These techniques allow a security-aware resolver to authenticate both DNS resource records and authoritative DNS error indications. This document obsoletes RFC 2535 and incorporates changes from all updates to RFC 2535. [STANDARDS-TRACK] This is an update to the wildcard definition of RFC 1034. The interaction with wildcards and CNAME is changed, an error condition is removed, and the words defining some concepts central to wildcards are changed. The overall goal is not to change wildcards, but to refine the definition of RFC 1034. [STANDARDS-TRACK] The Domain Name System Security (DNSSEC) Extensions introduced the NSEC resource record (RR) for authenticated denial of existence. This document introduces an alternative resource record, NSEC3, which similarly provides authenticated denial of existence. However, it also provides measures against zone enumeration and permits gradual expansion of delegation-centric zones. [STANDARDS-TRACK] This memo profiles the X.509 v3 certificate and X.509 v2 certificate revocation list (CRL) for use in the Internet. An overview of this approach and model is provided as an introduction. The X.509 v3 certificate format is described in detail, with additional information regarding the format and semantics of Internet name forms. Standard certificate extensions are described and two Internet-specific extensions are defined. A set of required certificate extensions is specified. The X.509 v2 CRL format is described in detail along with standard and Internet-specific extensions. An algorithm for X.509 certification path validation is described. An ASN.1 module and examples are provided in the appendices. [STANDARDS-TRACK] This document specifies the syntax and semantics for the Subject Public Key Information field in certificates that support Elliptic Curve Cryptography. This document updates Sections 2.3.5 and 5, and the ASN.1 module of "Algorithms and Identifiers for the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 3279. [STANDARDS-TRACK] Encrypted communication on the Internet often uses Transport Layer Security (TLS), which depends on third parties to certify the keys used. This document improves on that situation by enabling the administrators of domain names to specify the keys used in that domain's TLS servers. This requires matching improvements in TLS client software, but no change in TLS server software. [STANDARDS-TRACK] A JSON Web Key (JWK) is a JavaScript Object Notation (JSON) data structure that represents a cryptographic key. This specification also defines a JWK Set JSON data structure that represents a set of JWKs. Cryptographic algorithms and identifiers for use with this specification are described in the separate JSON Web Algorithms (JWA) specification and IANA registries established by that specification. This specification registers cryptographic algorithms and identifiers to be used with the JSON Web Signature (JWS), JSON Web Encryption (JWE), and JSON Web Key (JWK) specifications. It defines several IANA registries for these identifiers. This document provides recommendations for the implementation of public-key cryptography based on the RSA algorithm, covering cryptographic primitives, encryption schemes, signature schemes with appendix, and ASN.1 syntax for representing keys and for identifying the schemes. This document represents a republication of PKCS #1 v2.2 from RSA Laboratories' Public-Key Cryptography Standards (PKCS) series. By publishing this RFC, change control is transferred to the IETF. This document also obsoletes RFC 3447. Formally, any DNS Resource Record (RR) may occur under any domain name. However, some services use an operational convention for defining specific interpretations of an RRset by locating the records in a DNS branch under the parent domain to which the RRset actually applies. The top of this subordinate branch is defined by a naming convention that uses a reserved node name, which begins with the underscore character (e.g., "_name"). The underscored naming construct defines a semantic scope for DNS record types that are associated with the parent domain above the underscored branch. This specification explores the nature of this DNS usage and defines the "Underscored and Globally Scoped DNS Node Names" registry with IANA. The purpose of this registry is to avoid collisions resulting from the use of the same underscored name for different services. This document specifies the "SVCB" ("Service Binding") and "HTTPS" DNS resource record (RR) types to facilitate the lookup of information needed to make connections to network services, such as for HTTP origins. SVCB records allow a service to be provided from multiple alternative endpoints, each with associated parameters (such as transport protocol configuration), and are extensible to support future uses (such as keys for encrypting the TLS ClientHello). They also enable aliasing of apex domains, which is not possible with CNAME. The HTTPS RR is a variation of SVCB for use with HTTP (see RFC 9110, "HTTP Semantics"). By providing more information to the client before it attempts to establish a connection, these records offer potential benefits to both performance and privacy. In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. Informative References This document defines a date and time format for use in Internet protocols that is a profile of the ISO 8601 standard for representation of dates and times using the Gregorian calendar. This document describes how to construct DNSSEC NSEC resource records that cover a smaller range of names than called for by RFC 4034. By generating and signing these records on demand, authoritative name servers can effectively stop the disclosure of zone contents otherwise made possible by walking the chain of NSEC records in a signed zone. [STANDARDS-TRACK] The DNAME record provides redirection for a subtree of the domain name tree in the DNS. That is, all names that end with a particular suffix are redirected to another part of the DNS. This document obsoletes the original specification in RFC 2672 as well as updates the document on representing IPv6 addresses in DNS (RFC 3363). [STANDARDS-TRACK] This document specifies Internet Assigned Numbers Authority (IANA) parameter assignment considerations for the allocation of Domain Name System (DNS) resource record types, CLASSes, operation codes, error codes, DNS protocol message header bits, and AFSDB resource record subtypes. It obsoletes RFC 6195 and updates RFCs 1183, 2845, 2930, and 3597. Authenticated denial of existence allows a resolver to validate that a certain domain name does not exist. It is also used to signal that a domain name exists but does not have the specific resource record (RR) type you were asking for. When returning a negative DNS Security Extensions (DNSSEC) response, a name server usually includes up to two NSEC records. With NSEC version 3 (NSEC3), this amount is three. This document provides additional background commentary and some context for the NSEC and NSEC3 mechanisms used by DNSSEC to provide authenticated denial-of-existence responses. Experience has shown that people get confused when discussing the three numeric fields of the TLSA record. This document specifies descriptive acronyms for the three numeric fields in TLSA records. This document updates the format of the IANA registry created by RFC 6698. This specification defines a method for computing a hash value over a JSON Web Key (JWK). It defines which fields in a JWK are used in the hash computation, the method of creating a canonical form for those fields, and how to convert the resulting Unicode string into a byte sequence to be hashed. The resulting hash value can be used for identifying or selecting the key represented by the JWK that is the subject of the thumbprint. This document clarifies and updates the DNS-Based Authentication of Named Entities (DANE) TLSA specification (RFC 6698), based on subsequent implementation experience. It also contains guidance for implementers, operators, and protocol developers who want to use DANE records. This document updates the guidelines and recommendations, as well as the IANA registration processes, for the definition of Uniform Resource Identifier (URI) schemes. It obsoletes RFC 4395. This document specifies the requirement for support of TCP as a transport protocol for DNS implementations and provides guidelines towards DNS-over-TCP performance on par with that of DNS-over-UDP. This document obsoletes RFC 5966 and therefore updates RFC 1035 and RFC 1123. This document describes the use of Transport Layer Security (TLS) to provide privacy for DNS. Encryption provided by TLS eliminates opportunities for eavesdropping and on-path tampering with DNS queries in the network, such as discussed in RFC 7626. In addition, this document specifies two usage profiles for DNS over TLS and provides advice on performance considerations to minimize overhead from using TCP and TLS with DNS. This document focuses on securing stub-to-recursive traffic, as per the charter of the DPRIVE Working Group. It does not prevent future applications of the protocol to recursive-to-authoritative traffic. This document describes an Extension Mechanisms for DNS (EDNS0) option that is in active use to carry information about the network that originated a DNS query and the network for which the subsequent response can be cached. Since it has some known operational and privacy shortcomings, a revision will be worked through the IETF for improvement. OpenPGP is a message format for email (and file) encryption that lacks a standardized lookup mechanism to securely obtain OpenPGP public keys. DNS-Based Authentication of Named Entities (DANE) is a method for publishing public keys in DNS. This document specifies a DANE method for publishing and locating OpenPGP public keys in DNS for a specific email address using a new OPENPGPKEY DNS resource record. Security is provided via Secure DNS, however the OPENPGPKEY record is not a replacement for verification of authenticity via the "web of trust" or manual verification. The OPENPGPKEY record can be used to encrypt an email that would otherwise have to be sent unencrypted. This document describes a simple process that allows authors of Internet-Drafts to record the status of known implementations by including an Implementation Status section. This will allow reviewers and working groups to assign due consideration to documents that have the benefit of running code, which may serve as evidence of valuable experimentation and feedback that have made the implemented protocols more mature. This process is not mandatory. Authors of Internet-Drafts are encouraged to consider using the process for their documents, and working groups are invited to think about applying the process to all of their protocol specifications. This document obsoletes RFC 6982, advancing it to a Best Current Practice. This document states clearly that when a DNS resolver receives a response with a response code of NXDOMAIN, it means that the domain name which is thus denied AND ALL THE NAMES UNDER IT do not exist. This document clarifies RFC 1034 and modifies a portion of RFC 2308: it updates both of them. This document describes how to use secure DNS to associate an S/MIME user's certificate with the intended domain name, similar to the way that DNS-Based Authentication of Named Entities (DANE), RFC 6698, does for TLS. The DNS relies upon caching to scale; however, the cache lookup generally requires an exact match. This document specifies the use of NSEC/NSEC3 resource records to allow DNSSEC-validating resolvers to generate negative answers within a range and positive answers from wildcards. This increases performance, decreases latency, decreases resource utilization on both authoritative and recursive servers, and increases privacy. Also, it may help increase resilience to certain DoS attacks in some circumstances. This document updates RFC 4035 by allowing validating resolvers to generate negative answers based upon NSEC/NSEC3 records and positive answers in the presence of wildcards. This document discusses usage profiles, based on one or more authentication mechanisms, which can be used for DNS over Transport Layer Security (TLS) or Datagram TLS (DTLS). These profiles can increase the privacy of DNS transactions compared to using only cleartext DNS. This document also specifies new authentication mechanisms -- it describes several ways that a DNS client can use an authentication domain name to authenticate a (D)TLS connection to a DNS server. Additionally, it defines (D)TLS protocol profiles for DNS clients and servers implementing DNS over (D)TLS. This document updates RFC 7858. This document defines a protocol for sending DNS queries and getting DNS responses over HTTPS. Each DNS query-response pair is mapped into an HTTP exchange. This document defines a method (serve-stale) for recursive resolvers to use stale DNS data to avoid outages when authoritative nameservers cannot be reached to refresh expired data. One of the motivations for serve-stale is to make the DNS more resilient to DoS attacks and thereby make them less attractive as an attack vector. This document updates the definitions of TTL from RFCs 1034 and 1035 so that data can be kept in the cache beyond the TTL expiry; it also updates RFC 2181 by interpreting values with the high-order bit set as being positive, rather than 0, and suggests a cap of 7 days. Due to a combination of unfortunate wording in earlier documents, aggressive use of NSEC and NSEC3 records may deny the existence of names far beyond the intended lifetime of a denial. This document changes the definition of the NSEC and NSEC3 TTL to correct that situation. This document updates RFCs 4034, 4035, 5155, and 8198. This document describes a technique called "QNAME minimisation" to improve DNS privacy, where the DNS resolver no longer always sends the full original QNAME and original QTYPE to the upstream name server. This document obsoletes RFC 7816. This document updates RFCs 1123 and 1536. This document requires the operational practice of permitting DNS messages to be carried over TCP on the Internet as a Best Current Practice. This operational requirement is aligned with the implementation requirements in RFC 7766. The use of TCP includes both DNS over unencrypted TCP as well as over an encrypted TLS session. The document also considers the consequences of this form of DNS communication and the potential operational issues that can arise when this Best Current Practice is not upheld. This specification defines UUIDs (Universally Unique IDentifiers) -- also known as GUIDs (Globally Unique IDentifiers) -- and a Uniform Resource Name namespace for UUIDs. A UUID is 128 bits long and is intended to guarantee uniqueness across space and time. UUIDs were originally used in the Apollo Network Computing System (NCS), later in the Open Software Foundation's (OSF's) Distributed Computing Environment (DCE), and then in Microsoft Windows platforms. This specification is derived from the OSF DCE specification with the kind permission of the OSF (now known as "The Open Group"). Information from earlier versions of the OSF DCE specification have been incorporated into this document. This document obsoletes RFC 4122. The widely deployed Extension Mechanisms for DNS (EDNS(0)) feature in the DNS enables a DNS receiver to indicate its received UDP message size capacity, which supports the sending of large UDP responses by a DNS server. Large DNS/UDP messages are more likely to be fragmented, and IP fragmentation has exposed weaknesses in application protocols. It is possible to avoid IP fragmentation in DNS by limiting the response size where possible and signaling the need to upgrade from UDP to TCP transport where necessary. This document describes techniques to avoid IP fragmentation in DNS. The DNSSEC protocol makes use of various cryptographic algorithms to provide authentication of DNS data and proof of nonexistence. To ensure interoperability between DNS resolvers and DNS authoritative servers, it is necessary to specify both a set of algorithm implementation requirements and usage guidelines to ensure that there is at least one algorithm that all implementations support. This document replaces and obsoletes RFC 8624 and moves the canonical source of algorithm implementation requirements and usage guidance for DNSSEC from RFC 8624 to the IANA DNSSEC algorithm registries. This is done to allow the list of requirements to be more easily updated and referenced. Extensions to these registries can be made in future RFCs. This document also updates RFC 9157 and incorporates the revised IANA DNSSEC considerations from that RFC. This document does not change the recommendation status (MUST, MAY, RECOMMENDED, etc.) of the algorithms listed in RFC 8624; that is the work of future documents. National Institute of Standards and Technology IANA n.d. Work in Progress Work in Progress Work in Progress Work in Progress Work in Progress (not yet published)

Examples The names, labels, and digests below are fictitious. In the zone fragments, the UUIDs to the left of _originator-key and _revocation are record labels: each stands where <record-label> stands in the names of and . A CP issuer cip.op-example.org publishes the OPKEY RR for its own signing key and the Originator Key Record of a CP it has issued to the originator example-news.jp; the CP contains two keys. After the type value is allocated but before the DNS software in use recognizes the OPKEY mnemonic, the same record is written in the generic representation of , where <n> is the allocated type value: \# 35 ( 030101 c9d1...cip-key...02 ) ]]> Before the type value is allocated, a record publisher taking part in the experiment publishes the RDATA as TLSA instead (): A CP issuer that divides its Originator Key Records among several zones may place a label between the record label and _originator-key; the verifier does not interpret it: A PA issuer factcheck.example publishes the OPKEY RR for its own key and one Revocation Record: The originator may pin its CP issuer:

Experiment Goal This document is published as Experimental. What remains to be shown is not the design of the record but whether a new RR type can be put into service for this purpose by the parties involved. Specifically: do the authoritative and recursive DNS software, and the DNS hosting providers used by CP issuers and PA issuers, come to support OPKEY well enough (beyond handling it as an unknown type ) that the TLSA form of , and the verifier-side fallback to it, can be discontinued? That is the question the experiment answers. It is answered by observing, among participating zones, the form in which OPKEY records are published (the mnemonic; the generic representation, which is OPKEY itself and needs no discontinuation (); or the TLSA form) and whether the provisioning interfaces of the DNS hosting providers in use accept the generic representation; and, among verifiers, how often the TLSA fallback of is taken, and how many verifiers deployed before the allocation, which do not know the type value, continue to query for the TLSA RRset alone. Implementers and operators are asked to report these observations. Two further observations are expected from the same deployment, without being conditions of the experiment's success. The first is whether Originator Key Records expressed as a DNS subtree of opaque labels under _originator-key._op remain manageable in zone size, signing load, and provisioning when a CP issuer issues CPs to a large number of originators. The second is whether verifiers, in particular those within browsing software, can obtain the DNSSEC validation state by a route that is practical in deployment: a validator of their own, or a secure channel to a validating resolver (). If the experiment succeeds, its findings are expected to inform a revision of this document. Those implementing and deploying this specification are encouraged to publicly document their experiences so that such a revision can benefit from them.

RRTYPE Allocation Template The template of Appendix A of , completed for OPKEY:

A. Submission Date:

To be filled in when the template is posted.

B.1 Submission Type:

New RRTYPE.

B.2 Kind of RR:

Data RR.

C. Contact Information for submitter:

Shigeya Suzuki, shigeya@wide.ad.jp.

D. Motivation for the new RRTYPE application:

In the Originator Profile Framework, verifiers of content and of the documents that describe its originator need an authenticated way to confirm that a public key used by an originator or by an issuer of those documents is currently valid, and that the originator's Core Profile has not been revoked. OPKEY associates the digest of a public key with a DNS name under _op, and its presence or absence, validated with DNSSEC, gives that answer.

E. Description of the proposed RR type:

and of this document.

F. What existing RRTYPE or RRTYPEs come closest to filling that need and why are they unsatisfactory?

TLSA , whose format OPKEY shares. TLSA associates certificates or keys with TLS services at names of the form _port._proto.host; using it for the signing keys of documents would give one type two semantics (), as SMIMEA avoided for S/MIME. OPENPGPKEY carries a key itself, not a digest, and is specific to OpenPGP.

G. What mnemonic is requested for the new RRTYPE?

OPKEY.

H. Does the requested RRTYPE make use of any existing IANA registry or require the creation of a new IANA subregistry in DNS Parameters?

It uses the TLSA Certificate Usages, TLSA Selectors and TLSA Matching Types registries of , restricted as states. No new subregistry is required. The underscored name _op is registered as requests.

I. Does the proposal require/expect any changes in DNS servers/resolvers that prevent the new type from being processed as an unknown RRTYPE?

No. OPKEY can be processed as an unknown RRTYPE .

J. Comments:

Until a value is allocated, the RDATA is published as TLSA at the same owner names ().

Implementation Status RFC Editor: please remove this section, and the reference to , before publication. This section records the status of known implementations of the protocol defined by this specification at the time of posting of this Internet-Draft, and is based on a proposal described in . The description of implementations in this section is intended to assist the IETF in its decision processes in progressing drafts to RFCs. Please note that the listing of any individual implementation here does not imply endorsement by the IETF. Furthermore, no effort has been spent to verify the information presented here that was supplied by IETF contributors. This is not intended as, and must not be construed to be, a catalog of available implementations or their features. Readers are advised to note that other implementations may exist. According to , "this will allow reviewers and working groups to assign due consideration to documents that have the benefit of running code, which may serve as evidence of valuable experimentation and feedback that have made the implemented protocols more mature. It is up to the individual working groups to use this information as they see fit".

op-lib-go:

A library in Go, written by the author as an experimental implementation of the Core Specification and of this document. It generates and interprets the records under _op, generates signed test zones, and carries out the verifier's procedure, including the checks of . Maturity: research prototype. It is the implementation with which the counts of were checked in the laboratory of . Contact: the author.