Enum hickory_proto::rr::dnssec::Algorithm

source ·

#[non_exhaustive]pub enum Algorithm {
    RSAMD5,
    DSA,
    RSASHA1,
    RSASHA1NSEC3SHA1,
    RSASHA256,
    RSASHA512,
    ECDSAP256SHA256,
    ECDSAP384SHA384,
    ED25519,
    Unknown(u8),
}

Available on crate feature dnssec only.

Expand description

DNSSEC signing and validation algorithms.

For reference the iana documents have all the officially registered algorithms.

RFC 6944, DNSSEC DNSKEY Algorithm Status, April 2013


2.2.  Algorithm Implementation Status Assignment Rationale

RSASHA1 has an implementation status of Must Implement, consistent
with [RFC4034].  RSAMD5 has an implementation status of Must Not
Implement because of known weaknesses in MD5.

The status of RSASHA1-NSEC3-SHA1 is set to Recommended to Implement
as many deployments use NSEC3.  The status of RSA/SHA-256 and RSA/
SHA-512 are also set to Recommended to Implement as major deployments
(such as the root zone) use these algorithms [ROOTDPS].  It is
believed that RSA/SHA-256 or RSA/SHA-512 algorithms will replace
older algorithms (e.g., RSA/SHA-1) that have a perceived weakness.

Likewise, ECDSA with the two identified curves (ECDSAP256SHA256 and
ECDSAP384SHA384) is an algorithm that may see widespread use due to
the perceived similar level of security offered with smaller key size
compared to the key sizes of algorithms such as RSA.  Therefore,
ECDSAP256SHA256 and ECDSAP384SHA384 are Recommended to Implement.

All other algorithms used in DNSSEC specified without an
implementation status are currently set to Optional.

2.3.  DNSSEC Implementation Status Table

The DNSSEC algorithm implementation status table is listed below.
Only the algorithms already specified for use with DNSSEC at the time
of writing are listed.

 +------------+------------+-------------------+-------------------+
 |    Must    |  Must Not  |    Recommended    |      Optional     |
 |  Implement | Implement  |   to Implement    |                   |
 +------------+------------+-------------------+-------------------+
 |            |            |                   |                   |
 |   RSASHA1  |   RSAMD5   |   RSASHA256       |   Any             |
 |            |            |   RSASHA1-NSEC3   |   registered      |
 |            |            |    -SHA1          |   algorithm       |
 |            |            |   RSASHA512       |   not listed in   |
 |            |            |   ECDSAP256SHA256 |   this table      |
 |            |            |   ECDSAP384SHA384 |                   |
 +------------+------------+-------------------+-------------------+

   This table does not list the Reserved values in the IANA registry
   table or the values for INDIRECT (252), PRIVATE (253), and PRIVATEOID
   (254).  These values may relate to more than one algorithm and are
   therefore up to the implementer's discretion.  As noted, any
   algorithm not listed in the table is Optional.  As of this writing,
   the Optional algorithms are DSASHA1, DH, DSA-NSEC3-SHA1, and GOST-
   ECC, but in general, anything not explicitly listed is Optional.

2.4.  Specifying New Algorithms and Updating the Status of Existing
      Entries

   [RFC6014] establishes a parallel procedure for adding a registry
   entry for a new algorithm other than a standards track document.
   Because any algorithm not listed in the foregoing table is Optional,
   algorithms entered into the registry using the [RFC6014] procedure
   are automatically Optional.

   It has turned out to be useful for implementations to refer to a
   single document that specifies the implementation status of every
   algorithm.  Accordingly, when a new algorithm is to be registered
   with a status other than Optional, this document shall be made
   obsolete by a new document that adds the new algorithm to the table
   in Section 2.3.  Similarly, if the status of any algorithm in the
   table in Section 2.3 changes, a new document shall make this document
   obsolete; that document shall include a replacement of the table in
   Section 2.3.  This way, the goal of having one authoritative document
   to specify all the status values is achieved.

   This document cannot be updated, only made obsolete and replaced by a
   successor document.

Variants (Non-exhaustive)§

This enum is marked as non-exhaustive

Non-exhaustive enums could have additional variants added in future. Therefore, when matching against variants of non-exhaustive enums, an extra wildcard arm must be added to account for any future variants.

§