[CFRG] Re: [Technical Errata Reported] RFC8554 (8035)

[Rebecca VanRheenen <[e-mail]>]

Hello,

This erratum report is for the same issue as was reported in erratum report 7994 (https://www.rfc-editor.org/errata/eid7994) In fact, it is identical to erratum report 7994, even the notes.

As such, we have deleted this report. 

Please let us know any concerns. 

Thank you,
RFC Editor/rv


> On Jul 17, 2024, at 4:21 AM, RFC Errata System <[e-mail]> wrote:
> 
> The following errata report has been submitted for RFC8554,
> "Leighton-Micali Hash-Based Signatures".
> 
> --------------------------------------
> You may review the report below and at:
> https://www.rfc-editor.org/errata/eid8035
> 
> --------------------------------------
> Type: Technical
> Reported by: Pirat Untan <[e-mail]>
> 
> Section: GLOBAL
> 
> Original Text
> -------------
> /* leighton-micali signatures (lms) */
> 
>   union lms_path switch (lms_algorithm_type type) {
>    case lms_sha256_n32_h5:
>      bytestring32 path_n32_h5[5];
>    case lms_sha256_n32_h10:
>      bytestring32 path_n32_h10[10];
>    case lms_sha256_n32_h15:
>      bytestring32 path_n32_h15[15];
>    case lms_sha256_n32_h20:
>      bytestring32 path_n32_h20[20];
>    case lms_sha256_n32_h25:
>      bytestring32 path_n32_h25[25];
>    default:
>      void;     /* error condition */
>   };
> 
>   struct lms_signature {
>     unsigned int q;
>     lmots_signature lmots_sig;
>     lms_path nodes;
>   };
> 
>   struct lms_key_n32 {
>     lmots_algorithm_type ots_alg_type;
>     opaque I[16];
>     opaque K[32];
>   };
> 
>   union lms_public_key switch (lms_algorithm_type type) {
>    case lms_sha256_n32_h5:
>    case lms_sha256_n32_h10:
>    case lms_sha256_n32_h15:
>    case lms_sha256_n32_h20:
>    case lms_sha256_n32_h25:
>         lms_key_n32 z_n32;
> 
> Corrected Text
> --------------
>  /* leighton-micali signatures (lms) */
> 
>   union lms_path switch (lms_algorithm_type type) {
>    case lms_sha256_m32_h5:
>      bytestring32 path_m32_h5[5];
>    case lms_sha256_m32_h10:
>      bytestring32 path_m32_h10[10];
>    case lms_sha256_m32_h15:
>      bytestring32 path_m32_h15[15];
>    case lms_sha256_m32_h20:
>      bytestring32 path_m32_h20[20];
>    case lms_sha256_m32_h25:
>      bytestring32 path_m32_h25[25];
>    default:
>      void;     /* error condition */
>   };
> 
>   struct lms_signature {
>     unsigned int q;
>     lmots_signature lmots_sig;
>     lms_path nodes;
>   };
> 
>   struct lms_key_m32 {
>     lmots_algorithm_type ots_alg_type;
>     opaque I[16];
>     opaque K[32];
>   };
> 
>   union lms_public_key switch (lms_algorithm_type type) {
>    case lms_sha256_m32_h5:
>    case lms_sha256_m32_h10:
>    case lms_sha256_m32_h15:
>    case lms_sha256_m32_h20:
>    case lms_sha256_m32_h25:
>         lms_key_m32 z_m32;
> 
> Notes
> -----
> While "n" is the parameter used in LMOTS, "m" is the parameter used in LMS. In order to be consistent with the other parts of RFC 8554 and with the IANA registry, 
> the LMS parameter set names need to be changed from "_n32_" to "_m32_". For consistency, all other references to the number of bytes in each node should changed from "n32" to "m32"
> 
> Instructions:
> -------------
> This erratum is currently posted as "Reported". (If it is spam, it 
> will be removed shortly by the RFC Production Center.) Please
> use "Reply All" to discuss whether it should be verified or
> rejected. When a decision is reached, the verifying party  
> will log in to change the status and edit the report, if necessary.
> 
> --------------------------------------
> RFC8554 (draft-mcgrew-hash-sigs-15)
> --------------------------------------
> Title               : Leighton-Micali Hash-Based Signatures
> Publication Date    : April 2019
> Author(s)           : D. McGrew, M. Curcio, S. Fluhrer
> Category            : INFORMATIONAL
> Source              : Crypto Forum Research Group
> Stream              : IRTF
> Verifying Party     : IRSG
>