Re: [dnsext] I-D Action: draft-ietf-dnsext-dnssec-algo-imp-status-04.txt

[Joe Abley <[e-mail]>]

On 2013-03-11, at 15:43, Andrew Sullivan <[e-mail]> wrote:

> What about "Because this document establishes the implementation
> status of every algorithm, it should be listed as a reference for the
> registry itself (leaving in place the individual entries for the
> algorithms referring to the documents that specify them)." ?

That seems like it would have eliminated my confusion. Perhaps also explicitly state that this document aims to classify existing and all future algorithms that might be standardised, until replaced. This could be done by adding to the table earlier in the document make it clear explicitly that "Optional" includes all future algorithms.

    +------------+------------+-------------------+-------------------+
    |    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 |                   |
    +------------+------------+-------------------+-------------------+

REMOVE:

  Any registered algorithm not listed in this table

ADD:

  Any registered algorithm not listed in this table, including any algorithm registered in the future.

One further comment, the document justifies as "recommended" ECDSA on the grounds that they might be popular in the future because they feature small key sizes.

   Likewise, ECDSA with the two identified curves (ECDSAP256SHA256 and
   ECDSAP384SHA384) are algorithms 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.

ECC-GOST are not recommended, although I believe they have the same advantages. Arguably ECC-GOST has been around for longer, and hence has an advantage over ECDSA. Both have stable references, in English, in the RFC series. What is the reason for appearing to promote one over the other?

> Note that the last part of your "ADD" is explicitly disallowed.  Any
> future entry is either Optional (in which case no new entry is
> needed), or else this entire document needs to be made obsolete and
> replaced.  

That's clear, now, and seems like a reasonable approach.


Joe