draft-ietf-dnsext-dnssec-alg-allocation-01.txt   draft-ietf-dnsext-dnssec-alg-allocation-02.txt 
Network Working Group P. Hoffman Network Working Group P. Hoffman
Internet-Draft VPN Consortium Internet-Draft VPN Consortium
Updates: 2535, 3755, 4034 January 20, 2010 Updates: 2535, 3755, 4034 January 25, 2010
(if approved) (if approved)
Intended status: Standards Track Intended status: Standards Track
Expires: July 24, 2010 Expires: July 29, 2010
Cryptographic Algorithm Identifier Allocation for DNSSEC Cryptographic Algorithm Identifier Allocation for DNSSEC
draft-ietf-dnsext-dnssec-alg-allocation-01 draft-ietf-dnsext-dnssec-alg-allocation-02
Abstract Abstract
This document specifies how DNSSEC cryptographic algorithm This document specifies how DNSSEC cryptographic algorithm
identifiers in the IANA registries are allocated. It changes the identifiers in the IANA registries are allocated. It changes the
requirement from "standard required" to "RFC required". It does not requirement from "standard required" to "RFC required". It does not
change the list of algorithms that are recommended or required for change the list of algorithms that are recommended or required for
DNSSEC implementations. DNSSEC implementations.
Status of this Memo Status of this Memo
skipping to change at page 1, line 42 skipping to change at page 1, line 42
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on July 24, 2010. This Internet-Draft will expire on July 29, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 48 skipping to change at page 2, line 48
value. value.
2. Requirements for Assignments in the DNS Security Algorithm Numbers 2. Requirements for Assignments in the DNS Security Algorithm Numbers
Registry Registry
This document changes the requirement for registration from requiring This document changes the requirement for registration from requiring
a Standards Track RFC to requiring a published RFC of any type. a Standards Track RFC to requiring a published RFC of any type.
There are two reasons for relaxing the requirement: There are two reasons for relaxing the requirement:
o There are some algorithms that are useful that may not be able to o There are some algorithms that are useful that may not be able to
be in a Standards Track RFC. For example, an algorithm might be be in a Standards Track RFC. For any number of reasons, an
sponsored by a government and use cryptography that has not been algorithm might not have been evaluated thoroughly enough to be
evaluated thoroughly enough to be able to be put on the Standards able to be put on the Standards Track. Another example is that
Track. Another example is that the algorithm might have unclear the algorithm might have unclear intellectual property rights that
intellectual property rights that prevents the algorithm from prevents the algorithm from being put on the Standards Track.
being put on the Standards Track.
o Although the size of the registry is restricted (about 250 o Although the size of the registry is restricted (about 250
entries), new algorithms are proposed infrequently. It could entries), new algorithms are proposed infrequently. It could
easily be many decades before there is any reason to consider easily be many decades before there is any reason to consider
restricting the registry again. restricting the registry again.
Some developers will care about the standards level of the RFCs that Some developers will care about the standards level of the RFCs that
are in the registry. The registry should be updated to reflect the are in the registry. The registry should be updated to reflect the
current standards level of each algorithm listed. current standards level of each algorithm listed.
skipping to change at page 3, line 48 skipping to change at page 3, line 47
items listed in the IANA registry that need not be (and in some items listed in the IANA registry that need not be (and in some
cases, should not be) included in all implementations. cases, should not be) included in all implementations.
There are many reasons why a DNSSEC implementation might not include There are many reasons why a DNSSEC implementation might not include
one or more of the algorithms listed, even those on the Standards one or more of the algorithms listed, even those on the Standards
Track. In order to be compliant with the RFC 4034, an implementation Track. In order to be compliant with the RFC 4034, an implementation
only needs to implement the algorithms listed as mandatory to only needs to implement the algorithms listed as mandatory to
implement in that standard, or updates to that standard. This implement in that standard, or updates to that standard. This
document does nothing to change the list of mandatory to implement document does nothing to change the list of mandatory to implement
algorithms in RFC 4034. This document does not change the algorithms in RFC 4034. This document does not change the
requirements for when an algorithm because mandatory to implement. requirements for when an algorithm becomes mandatory to implement.
Such requirements should come in a separate, focused document. Such requirements should come in a separate, focused document.
It should be noted that the order of algorithms in the IANA registry It should be noted that the order of algorithms in the IANA registry
does not signify or imply cryptographic strength or preference. does not signify or imply cryptographic strength or preference.
4. IANA Considerations 4. IANA Considerations
This document updates allocation requirements for unassigned values This document updates allocation requirements for unassigned values
in the "Domain Name System Security (DNSSEC) Algorithm Numbers" in the "Domain Name System Security (DNSSEC) Algorithm Numbers"
registry located at http://www.iana.org/assignments/ registry located at http://www.iana.org/assignments/
skipping to change at page 6, line 21 skipping to change at page 6, line 21
Various editorial changes and clarifications that came during WG LC. Various editorial changes and clarifications that came during WG LC.
Asked IANA to mark values 123 through 250 as "Reserved". Asked IANA to mark values 123 through 250 as "Reserved".
In the expectations for implementers, added "This document does not In the expectations for implementers, added "This document does not
change the requirements for when an algorithm because mandatory to change the requirements for when an algorithm because mandatory to
implement. Such requirements should come in a separate, focused implement. Such requirements should come in a separate, focused
document." document."
B.4. Differences between draft-ietf-dnsext-dnssec-alg-allocation-01 and
draft-ietf-dnsext-dnssec-alg-allocation-02
Reworded the first bullet in Section 2 to remove "government".
Author's Address Author's Address
Paul Hoffman Paul Hoffman
VPN Consortium VPN Consortium
Email: paul.hoffman@vpnc.org Email: paul.hoffman@vpnc.org
 End of changes. 7 change blocks. 
11 lines changed or deleted 15 lines changed or added

This html diff was produced by rfcdiff 1.37c. The latest version is available from http://tools.ietf.org/tools/rfcdiff/