Subject: [dnsext] draft-ietf-dnsext-dnssec-rsasha256-06 nits

From: Alfred Hönes <[email-masked]>
Date: Fri, 31 Oct 2008 17:56:14 +0100 (MEZ)

Hello again,

I closely re-visited the latest revision of the DNSSEC SHA-2 draft.
Indeed, technically [ and politically :-) ] now all seems to be
in a rather good shape.

However, I have a few small nits that might be worth addressing
before publication as an RFC, perhaps during AUTH48:

(1)  Section 2

I suggest to replace the comma by a semicolon, because this
punctuation separates two almost independent full sentences.

(2)  Sections 2.1 and 2.2

For consistency in style, please  s/RFC5155/RFC 5155/
in the prose of the second paragraph each.

Also, I suggest to remove the redundant and unpleasant repetitions
of "*key* [size]" in the last paragraph each.

For 2.1:
                                                      vvvvv
|  For interoperability, as in RFC 3110 [RFC3110], the key size of RSA/
   SHA-256 keys MUST NOT be less than 512 bits, and MUST NOT be more
   than 4096 bits.
---                                                   v
|  For interoperability, as in RFC 3110 [RFC3110], the size of RSA/
   SHA-256 keys MUST NOT be less than 512 bits, and MUST NOT be more
   than 4096 bits.

For 2.2:

      vvvvv
|  The key size of RSA/SHA-512 keys MUST NOT be less than 1024 bits, and
   MUST NOT be more than 4096 bits.
---   v
|  The size of RSA/SHA-512 keys MUST NOT be less than 1024 bits, and MUST
   NOT be more than 4096 bits.

(3)  Section 3

(3a)
For enhanced readability, I suggest to indent the two formulae
one step more than the prose.

(3b)
For ultimate precision and unambiguity, I suggest to add the words
"in octets" after "length" in the last line of the penultimate
paragraph -- cryptographers are used to think and talk in bit sizes
 -- see the discussion about RSA keys in the draft as well!
(Otherwise, the text now is o.k. there.)

   key.  The FF octet MUST be repeated the exact number of times so that
   the total length of the concatenated term in parentheses equals the
|  length of the modulus of the signer's public key ("n").
---      ^
   key.  The FF octet MUST be repeated the exact number of times so that
   the total length of the concatenated term in parentheses equals the
|  length (in octets) of the modulus of the signer's public key ("n").
         ^^^^^^^^^^^^^

(3c)
In the last paragraph, the second sentence could be simplified,
in order to enhance the readability and to emphasize that the
same document is referenced for the two algorithms, without
repeating the full denomination of the document.
Furthermore, the double "specifications" in the same sentence
is unpleasant; how about replacing the first instance by "rules" ?

Incorporating both proposals, the following change would result:

   The "prefix" is intended to make the use of standard cryptographic
   libraries easier.  These specifications are taken directly from the
|  specifications of RSASSA-PKCS1-v1_5 in PKCS #1 v2.1 section 8.2
|  [RFC3447], and EMSA-PKCS1-v1_5 encoding in PKCS #1 v2.1 section 9.2
|  [RFC3447].  The prefixes for the different algorithms are specified
   below.
---
   The "prefix" is intended to make the use of standard cryptographic
|  libraries easier.  These rules are taken directly from the
|  specifications of RSASSA-PKCS1-v1_5 in section 8.2, and the
|  EMSA-PKCS1-v1_5 encoding in section 9.2 of PKCS #1 v2.1 [RFC3447].
   The prefixes for the different algorithms are specified below.

(4)  Sections 3.1 and 3.2

(4a)
In the second paragraph each, the replicated "prefix" is not only
unpleasant, but arguably even wrong; what is called the
"algorithm designator prefix" in fact is the *entire*
"algorithm identifier".  I admit "designator" as a stylistic
variant, but I recommend to drop the second "prefix":

For 3.1:
                                                           vvvvvvvv
|  The prefix is the ASN.1 BER SHA-256 algorithm designator prefix as
   specified in PKCS #1 v2.1 [RFC3447]:
---                                                        v
|  The prefix is the ASN.1 BER SHA-256 algorithm designator as specified
   in PKCS #1 v2.1 [RFC3447]:

For 3.2:
                                                           vvvvvvvv
|  The prefix is the ASN.1 BER SHA-512 algorithm designator prefix as
   specified in PKCS #1 v2.1 [RFC3447]:
---                                                        v
|  The prefix is the ASN.1 BER SHA-512 algorithm designator as specified
   in PKCS #1 v2.1 [RFC3447]:

(4b)
For enhanced readability, I also suggest to indent the trailing
lines with the hex representation one step more than the prose.

Kind regards,
  Alfred.

-- 

+------------------------+--------------------------------------------+
| TR-Sys Alfred Hoenes   |  Alfred Hoenes   Dipl.-Math., Dipl.-Phys.  |
| Gerlinger Strasse 12   |  Phone: (+49)7156/9635-0, Fax: -18         |
| D-71254  Ditzingen     |  E-Mail:  [email-masked]                     |
+------------------------+--------------------------------------------+

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