Internet Systems Consortium

PO Box 360 Newmarket NH 03857 US marka@isc.org

When DS records where defined the ability to fully identify the DNSSEC algorithms using PRIVATEDNS and PRIVATEOID was overlooked. This documents specifies 2 DS Algorithm Types which allow the DNSSEC algorithm sub type to be encoded in the DS record.

When DS records where defined the ability to fully identify the DNSSEC algorithms using PRIVATEDNS and PRIVATEOID was overlooked. This document specifies 2 DS Algorithm Types, DIGESTDNS and DIGESTOID, which allow the DNSSEC algorithm sub types of PRIVATEDNS and PRIVATEOID respectively to be encoded in the DS record. This allow validators which support private DNSSEC algorithms to properly identify the DNSKEY record the DS record matches. Currently if there are two or more entities using PRIVATEDNS or PRIVATEOID there is no way to differentiate the use and as such determine if the delegated zone is treated as secure or not.

The DS digest type "DIGESTDNS" (TBA recommended 253) is used to identify the PRIVATEDNS algorithm used in the corresponding DNSKEY. The original digest field of the DS records is further broken down into 3 fields, the Sub Digest Type, the DNS NAME from the PRIVATEDNS DNSKEY record and digest of the DNSKEY record as identified by the Sub Digest Type field. The values of the Sub Digest Type field are drawn from the same table as the Digest Type.

1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Key Tag | PRIVATEDNS | DIGESTDNS | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Sub Digest Type| / +-+-+-+-+-+-+-+-+ / / Name / / / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / / / Digest / / / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

The DS digest type "DIGESTOID" (TBA recommended 254) is used to identify the PRIVATEOID algorithm used in the corresponding DNSKEY. The original digest field of the DS records is further broken down into 3 fields, the Sub Digest Type, the OID from the PRIVATEOID DNSKEY record and digest of the DNSKEY record as identified by the Sub Digest Type field. The values of the Sub Digest Type field are drawn from the same table as the Digest Type.

1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Key Tag | PRIVATEOID | DIGESTOID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Sub Digest Type| / +-+-+-+-+-+-+-+-+ / / OID / / / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / / / Digest / / / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

When validating tha DNSKEY RRset using a private algorithm, in addition to matching the DNS Algorithm fields in the DS and DNSKEY records the corresponding NAME or OID from the DS and DNSKEY records also need to match. This is an extention to RFC 4033 and is backwards compatible. Validators that are unaware of DIGESTDNS or DIGESTOID will treat the zone as insecure if those are the only Digest Types present.

This document be the reference document for DIGESTDNS and DIGESTOID. That DIGESTDNS be assigned the value 253 and that DIGESTOID be assigned the value 254 in the DNSSEC Delegation Signer (DS) Resource Record (RR) Type Digest Algorithms registry to be consistent with the values for PRIVATEDNS (253) and PRIVATEOID (254) from DNS Security Algorithm Numbers. Both DIGESTDNS and DIGESTOID have status OPTIONAL.

This document allows PRIVATEDNS and PRIVATEOID DNSKEYS to be used for secure delegations in DNSSEC.

Why not just add Name or OID to the start of the existing digests for PRIVATEDNS and PRIVATEOID? This would break existing software that checks the length of the digest field against the digest type for known values. The existing checks are not conditional on the DNS Algorithm. Why not use a single Digest Type Value and use the DNS Algorithm to identify whether the second field is a DNS name or an OID? This was definitely possible but I felt it was cleaner to use two values. What about RRSIG? RRSIG strictly doesn't need to fully identify the signing key but it would be advantages to also identify the the DNSKEY algorithm along with the keyid. Whether the private key identifier is added to the RRSIG can be specfied as part of the signature specification.