<?xml version="1.0"?>
<!DOCTYPE rfc [
<!ENTITY rfc2119 PUBLIC "" "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY rfc4034 PUBLIC "" "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4034.xml">
]>
<rfc ipr="trust200902" submissionType="IETF" category="std" docName="draft-andrews-ds-support-for-private-algorithms-00">
  <front>
    <title abbrev="">DS support for private DNSSEC algorithms</title>
    <author initials="M." surname="Andrews" fullname="M. Andrews">
      <organization abbrev="ISC">Internet Systems Consortium</organization>
      <address>
        <postal>
          <street>PO Box 360</street>
          <city>Newmarket</city>
          <region>NH</region>
          <code>03857</code>
          <country>US</country>
        </postal>
        <email>marka@isc.org</email>
      </address>
    </author>
    <date day="16" month="May" year="2025"/>
    <abstract>
      <t>
	Extend the DS digest field of the DS record to identify the
	private DNSSEC algorithm of the DNSKEY matching the DS
	record.
      </t>
    </abstract>
  </front>
  <middle>
    <section anchor="intro" title="Introduction">
      <t>
	When the DNSSEC algorithm is PRIVATEDNS (233) or PRIVATEOID
	(254) the private algorithm identifier is embedded at the
	start of the key data in KEY, CDNSKEY, and DNSKEY records
	and at the start of the signature data in the RRSIG and SIG
	records <xref target="RFC4034"/>.  This allows the private
	algorithm to be fully identified.
      </t>
      <t>
	DS record, however, do not embed this identifier at
	the start of the digest field.  This results in PRIVATEDNS
	and PRIVATEOID keys not being able to be used in all the
	scenarios where non private keys can be. i.e. publishing
	of DS records for yet to be published DNSKEYs, determining
	if a DS based trust anchor represents a supported algorithm.
      </t>
      <t>
	This document adds DS digest types which embed the private
	algorithm identifiers to the start of the digest field to
	provide equivalent functionality to PRIVATE key types.
      </t>
      <t>
	This document was inspired by the work done to add private
	DNSSEC algorithm support to BIND 9.
      </t>
      <section anchor="reserved" title="Reserved Words">
        <t>
          The key words "MUST", "MUST NOT", "REQUIRED", "SHALL",
          "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",
          and "OPTIONAL" in this document are to be interpreted as
          described in <xref target="RFC2119" />.
        </t>
      </section>
    </section>
    <section anchor="structure" title="Updated DS digest field structure">
      <t>
	The digest field of CDS and DS records with digest types
	other than SHA-1 (1), SHA-256 (2), GOST R 34.11-94 (3),
	SHA-384 (4), GOST R 34.11-2012 (5) and SM3 (6) MUST now
	embed the private algorithm identifier before the digest
	data if the DS algorithm field is PRIVATEDNS or PRIVATEOID
	in the same manner as is done for the matching DNSKEY record.
      </t>
      <t>
	It is RECOMMENDED that only DS records with DS digest types
	that embed the private DNSSEC algorithm are used with private
	DNSSEC algorithms as allows for publishing of DS records
	without the corresponding DNSKEY record being published.
      </t>
    </section>
    <section anchor="algorithms" title="New DS Types">
      <t>
	New DS type identifiers which support embedding the private
	DNSSEC algorithm identifier are needed for SHA-256, SHA-384,
	GOST R 34.11-2012 and SM3 are needed along with identifing
	names.  The new names and types are SHA-256-PRIVATE (TBA),
        SHA-384-PRIVATE (TBA), GOST R 34.11-2012 PRIVATE (TBA) and
	SM3-PRIVATE (TBA) respectively.
      </t>
    </section>
    <section anchor="iana" title="IANA Considerations">
      <t>
	IANA is requested to assign DS types for SHA-256-PRIVATE,
	SHA-384-PRIVATE, GOST R 34.11-2012 PRIVATE and SM3-PRIVATE.
      </t>
    </section>
    <section anchor="security" title="Security Considerations">
      <t>
        This adds no known security issues.
      </t>
    </section>
  </middle>
  <back>
    <references title="Normative References">
     &rfc2119; &rfc4034;
    </references>
  </back>
</rfc>
