Subject: NSEC3 Issue 22: Defining new hash algorithms.

From: David Blacka <[email-masked]>
Date: Fri, 23 Jun 2006 09:42:20 -0400

Issue:

Currently, the NSEC3 draft indicates that it uses the same IANA  
registry as DS for its hash algorithms.  This leads to a number of  
potential concerns:

   a) Operators might get the impression that if a new hash algorithm  
is added to the DS registry, then it is automatically defined for use  
in NSEC3.  I'm not sure that this is correct.

   b) The desirable criteria for a DS digest algorithm and an NSEC3  
hash algorithm are not exactly the same.  For instance, NSEC3 is less  
sensitive to the second pre-image resistance property of a hash.  In  
fact, algorithms that would simply not be acceptable for DS may be  
totally fine for NSEC3 (e.g., MD5.)

   c) There are things that must be defined about how a hash works  
with NSEC3 before it can be successfully used.  For instance, if the  
hash length is longer that 63 characters in base 32, then the hash  
must be split across multiple labels.  The consequences of this will  
no doubt require a significant amount of specification, possibly  
modifying the current NSEC3 specification.

Discussion:

1) The draft can establish a new IANA registry for NSEC3 hash  
algorithms, or

2) the draft can continue to use the DS registry.  This will prevent  
people from defining new hash algorithms that are fine for use with  
NSEC3 but not acceptable for use with DS (point b, above).

Independent from this decision the draft could be modified to stress  
that hash algorithms MUST be specified before use.

My recommendation:

Both establish a new registry and require that new algorithms have a  
specification describing its use with NSEC3.

--
David Blacka    <[email-masked]>
Sr. Engineer    VeriSign Applied Research

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>