[dnsext] Protocol Action: 'Applicability Statement: DNS Security (DNSSEC) DNSKEY Algorithm Implementation Status' to Best Current Practice (draft-ietf-dnsext-dnssec-algo-imp-status-04.txt)

[The IESG <[e-mail]>]

The IESG has approved the following document:
- 'Applicability Statement: DNS Security (DNSSEC) DNSKEY Algorithm
   Implementation Status'
  (draft-ietf-dnsext-dnssec-algo-imp-status-04.txt) as Best Current
Practice

This document is the product of the DNS Extensions Working Group.

The IESG contact persons are Ralph Droms and Brian Haberman.

A URL of this Internet Draft is:
http://datatracker.ietf.org/doc/draft-ietf-dnsext-dnssec-algo-imp-status/




Technical Summary 

  The DNS Security Extensions (DNSSEC) requires the use of 
  cryptographic algorithm suites for generating digital signatures 
  over DNS data.  There is currently an IANA registry for these 
  algorithms that it lacks the recommended implementation status of 
  each algorithm.  This document provides an applicability statement 
  on algorithm implementation status for DNSSEC component software. 
  This document lists each algorithm's status based on the current 
  reference.  In the case that an algorithm is specified without an 
  implementation status, this document assigns one.  The document 
  updates RFCs 2536, 2539, 3110, 4034, 4398, 5155, 5702, and 5933. 

Working Group Summary 

    The intended effect of this draft was originally captured in 
    draft-ietf-dnsext-dnssec-registry-fixes-08, which made a novel and 
    controversial use of the IANA registry.  That approach was too 
    controversial, and so the WG split the document into two parts. 
    This draft is one of them. 

    The present approach was far less controversial than the previous 
    one, and nobody has raised any objection to the current text. 

Document Quality 

    The draft does not specify a protocol of any kind, but it does 
    make a recommendation in favour of some algorithms that are so far 
    not widely deployed.  

    The discussion of dnssec-registry-fixes led to the approach 
    instantiated in this draft.  

Personnel 

    Andrew Sullivan is the Document Shepherd, and Ralph Droms is the 
    Responsible Area Director. 


RFC Editor Note

Please make the following two changes:

In section 2.2:

OLD:

2.2.  Algorithm Implementation Status Assignment Rationale

   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/

NEW:

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/

END

In the IANA considerations:

OLD:

   Because this document establishes the implementation status of every
   algorithm, it should be listed as a reference for the entire
   registry.

NEW:

  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).

END