Subject: [dnsext] review and support of rsasha256

From: Wes Hardaker <[email-masked]>
Date: Wed, 24 Sep 2008 16:37:37 -0700

First off, this document is important and should go forward.  Count me
in as a supporter of it.

Quick thoughts though:

Section 2.1, 2.2

  I'd suggest that the document that sites the key lengths minimums be
  referenced here so that readers understand these numbers aren't pulled
  out of the air (which I suspect is NIST 800-57, but I'll let you state
  the appropriate one).

Section 3:

  The wording in the 3rd paragraph is a bit odd because of the
  word "maximum".  I'd suggest rewording it from:

 OLD:

                                The FF octet MUST be repeated the
   maximum number of times so that the total length of the signature
   equals the length of the modulus of the signer's public key ("n").

 NEW:

                                The FF octet MUST be repeated the
   ***necessary*** number of times so that the total length of the signature
   equals the length of the modulus of the signer's public key ("n").

Section 5.2 is plain odd.

  Although I think NSEC3 is important and am a
  proponent of it, there is no explained reason why this document declares
  it a MUST to support.  It seems really oddly placed unless there is a
  strong technical reason to require it, I'd say it shouldn't be there at
  all.

Section 7.2

  I agree with the others that more text on a transition recommendation
  is needed for switching from one algorithm to another and the
  important timing considerations (in terms of TTLs) should be outlined
  (or another document referenced, which might be easier).

-- 
"In the bathtub of history the truth is harder to hold than the soap,
 and much more difficult to find."  -- Terry Pratchett

--
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/>

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 25 Sep 2008 08:26:45 -0700

>   strong technical reason to require it, I'd say it shouldn't be there at

Yipes, I missed that in my reading. Yes, that seems very odd and very 
out of place.

--Paul Hoffman, Director
--VPN Consortium

---

From: Jelte Jansen <[email-masked]>
Date: Mon, 29 Sep 2008 12:16:31 +0200

>   (or another document referenced, which might be easier).

IMHO, this problem should not be addressed in the RSA/SHA2 document. It
is an operation problem for any algorithm rollover, and would be more
suited in a document such as 4641bis. I have already suggested some text
to go in there, if it is to be reopened.

As someone pointed out in an earlier revision though, it's hard to refer
to something that does not exist (yet).

Jelte