Use of GOST Signature Algorithms in DNSKEY and RRSIG Resource Records for DNSSEC
draft-ietf-dnsext-dnssec-gost-07

As per Olafur, there is WG consensus not to register the new hashing function in the IANA registry established by RFC 5155. So I am downgrading this to a COMMENT.


6.1.  Support for GOST signatures

   DNSSEC aware implementations SHOULD be able to support RRSIG and
   DNSKEY resource records created with the GOST algorithms as
   defined in this document.

Use of this SHOULD was debated in details on SecDir mailing list. People has suggested that this should be a MAY. I don't think a choice of SHOULD versa MAY actually matters in this case, because this document doesn't say that it "Updates" RFC 4034 (And I think it a good case should be made that it shouldn't include "Updates: RFC 4034".) and because the document clearly states that the newly registered algorithms are OPTIONAL to support.

Note that I also generally agree with concerns about introducing additional signature/hashing algorithms for use in DNSSEC, however I think that any DNSSEC policy on this is out of scope for the document. And the document is currently silent on this anyway.

  Please consider the comments from the Gen-ART Review by Vijay Gurbani
  on 19-Feb-2010:

  1) In the Abstract, the draft has references of the form
     "[DRAFT1, DRAFT2, DRAFT3]".  I would humbly suggest that
     these be removed from the Abstract and placed in the body
     of the document.  In their current form, these references
     appear, well ... temporary, given their names (DRAFT1, etc.)

     I have come across services that index IETF RFCs and also
     include the abstract in the index.  In that context, having an
     Abstract include references to seemingly impermanent
     placeholders appears disconcerting.  Note that references
     to RFC numbers themselves -- as the Abstract also shows -- is
     okay since RFC numbers denote some sort of permanence.

  2) The references "DRAFT1" etc. seem to best fit in
     Section 1, paragraph 4.