Use of GOST Signature Algorithms in DNSKEY and RRSIG Resource Records for DNSSEC
Note: This ballot was opened for revision 07 and is now closed.
(Ralph Droms) Yes
(Ron Bonica) No Objection
(Ross Callon) No Objection
(Lisa Dusseault) No Objection
(Pasi Eronen) No Objection
(Adrian Farrel) No Objection
(Russ Housley) (was Discuss, No Objection) No Objection
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.
(Alexey Melnikov) (was Discuss) No Objection
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.