Re: [lamps] Barry Leiba's No Objection on draft-ietf-lamps-cms-hash-sig-09: (with COMMENT)

[Russ Housley <[e-mail]>]

Barry:

> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> Thanks, Russ, as always, for a clear and well-written document.

Thanks for the careful review.

> Some editorial nits:
> 
> — Section 1.3 —
> 
>   Each of these advances pose a
>   threat to widely deployed digital signature algorithms.
> 
> “poses”, to match the singular “each”.

Fixed.

>   Recent advances in cryptoanalysis [BH2013]
> 
> “cryptanalysis”, no “o”.

Indeed.  Fixed.

>   The HSS/LMS signature algorithm does not depend on the difficulty of
>   discrete logarithm or factoring, as a result these algorithms are
> 
> Comma splice.  Make it a semicolon.

How about:

   Since the HSS/LMS signature algorithm does not depend on the
   difficulty of discrete logarithm or factoring, the HSS/LMS signature
   algorithm is considered to be post-quantum secure.

> — Section 2.2 —
> 
>   The second parameter is
>   the number of bytes output by the hash function, m, which is the
>   amount of data associated with each node in the tree.
> 
> It’s a small thing, but I think the “m” is misplaced where it is, and suggest
> “…the number of bytes, m, output by the hash function….”

How about:

   The second parameter is
   the number of bytes output by the hash function, m, and it is the
   amount of data associated with each node in the tree. 

> — Section 3 —
> 
>   Each format includes a counter and type
>   codes that indirectly providing all of the information that is needed
> 
> “provide”

Fixed.

> — Section 5 —
> 
>   When signed attributes are absent, the HSS/LMS signature is computed
>   over the content.  When signed attributes are present, a hash is
>   computed over the content using the same hash function that is used
>   in the HSS/LMS tree, and then a message-digest attribute is
>   constructed to contain the resulting hash value, and then the result
>   of DER encoding the set of signed attributes (which MUST include a
>   content-type attribute and a message-digest attribute, and then the
>   HSS/LMS signature is computed over the DER-encoded output.
> 
> You’re missing a “)” there, which makes it a bit odd.  I think it should be
> “(which MUST include a content-type attribute and a message-digest attribute),
> and then….”

This text was changed to address a comment from Ben Kaduk.  It now says:

   When signed attributes are absent, the HSS/LMS signature is computed
   over the content.  When signed attributes are present, a hash is
   computed over the content using the same hash function that is used
   in the HSS/LMS tree, and then a message-digest attribute is
   constructed with the hash of the content, and then the HSS/LMS
   signature is computed over the DER-encoded set of signed attributes
   (which MUST include a content-type attribute and a message-digest
   attribute).  In summary:

      IF (signed attributes are absent)
      THEN HSS_LMS_Sign(content)
      ELSE message-digest attribute = Hash(content);
           HSS_LMS_Sign(DER(SignedAttributes))

>         digestAlgorithm MUST contain the one-way hash function used to in
>         the HSS/LMS tree.
> 
> Remove “to”.

Fixed.

> — Section 6 —
> 
>   While the consequences of an inadequate pseudo-random
>   number generator (PRNGs) to generate these values is much less severe
>   than the generation of private keys
> 
> “than in the generation”

Sure.  Fixed.

> — Appendix —
> Just a note that I did not review the ASN.1 module.

Gee, why not?  ;-)

Russ