Re: [lamps] [Gen-art] Genart last call review of draft-ietf-lamps-cms-hash-sig-08
Russ Housley <housley@vigilsec.com> Thu, 18 July 2019 14:26 UTC
Return-Path: <housley@vigilsec.com>
X-Original-To: spasm@ietfa.amsl.com
Delivered-To: spasm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4036512037A for <spasm@ietfa.amsl.com>; Thu, 18 Jul 2019 07:26:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=unavailable autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3enu6VxFpzaG for <spasm@ietfa.amsl.com>; Thu, 18 Jul 2019 07:26:45 -0700 (PDT)
Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 39B02120374 for <spasm@ietf.org>; Thu, 18 Jul 2019 07:26:45 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 694A1300B01 for <spasm@ietf.org>; Thu, 18 Jul 2019 10:00:13 -0400 (EDT)
X-Virus-Scanned: amavisd-new at mail.smeinc.net
Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id AU8PCXnzv4p0 for <spasm@ietf.org>; Thu, 18 Jul 2019 10:00:10 -0400 (EDT)
Received: from a860b60074bd.fios-router.home (unknown [138.88.156.37]) by mail.smeinc.net (Postfix) with ESMTPSA id 671ED300A02; Thu, 18 Jul 2019 10:00:10 -0400 (EDT)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
From: Russ Housley <housley@vigilsec.com>
In-Reply-To: <156341753682.25805.15107717483258855258@ietfa.amsl.com>
Date: Thu, 18 Jul 2019 10:19:26 -0400
Cc: IETF Gen-ART <gen-art@ietf.org>, LAMPS WG <spasm@ietf.org>, IETF <ietf@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <47826955-B512-4806-9971-211F4F4F24D0@vigilsec.com>
References: <156341753682.25805.15107717483258855258@ietfa.amsl.com>
To: Dale Worley <worley@ariadne.com>
X-Mailer: Apple Mail (2.3445.104.11)
Archived-At: <https://mailarchive.ietf.org/arch/msg/spasm/q65nWmImS6RWJzcvngNM9kU6SRA>
Subject: Re: [lamps] [Gen-art] Genart last call review of draft-ietf-lamps-cms-hash-sig-08
X-BeenThere: spasm@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." <spasm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/spasm>, <mailto:spasm-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/spasm/>
List-Post: <mailto:spasm@ietf.org>
List-Help: <mailto:spasm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/spasm>, <mailto:spasm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 18 Jul 2019 14:26:46 -0000
Dale: Thank you for the careful review. > Summary: > > This draft is in great shape and ready for publication as a > proposed standard RFC, with only a few editorial nits. Good to hear. > Nits/editorial comments: > > 2.2. Leighton-Micali Signature (LMS) > > The [HASHSIG] specification supports five tree sizes: > > LMS_SHA256_M32_H5; > LMS_SHA256_M32_H10; > LMS_SHA256_M32_H15; > LMS_SHA256_M32_H20; and > LMS_SHA256_M32_H25. > > This text seems redundant with the description in the preceding > paragraph. True. The intent was to provide the identifiers for the five tree sizes. Perhaps the two paragraphs should be merged, with the sentence before the list saying: ... As a result, the [HASHSIG] specification supports five tree sizes; they are identified as: > The LMS public key is the string consists of four elements: the > > Perhaps "An LMS public key consists of ...". Yes, that reads better. > u32str(lms_algorithm_type) || u32str(otstype) || I || T[1] > > The notation "T[1]" seems to be undefined (although the intended value > is described clearly in the preceding paragraph). Good catch. How about: ... and the m-byte string associated with the root node of the tree (T[1]). > 2.3. Leighton-Micali One-time Signature Algorithm (LM-OTS) > > n - The number of bytes associated with the hash function. > [HASHSIG] supports only SHA-256 [SHS], with n=32. > > "associated" seems to me to be vague. Perhaps "The length in bytes of > the output of the hash function." Okay. How about: n - The length in bytes of the hash function output. ... > ls - The number of left-shift bits used in the checksum function, > which is defined in Section 4.4 of [HASHSIG]. > > "The number of left-shift bits" is not quite right. Perhaps "The > number of bits of left-shifting used in ..." or "The amount/size of > the left-shift used in ...". These words were taken directly from Section 4.1 of RFC 8554. That said, I think you are right that it could be more clear. How about: ls - The number of bits that are left-shifted in the final step of the checksum function, which is defined in Section 4.4 of [HASHSIG]. > 5. Signed-data Conventions > > This paragraph has to be a number of minor wording issues, which I > have described interline: > > As specified in [CMS], the digital signature is produced from the > message digest and the signer's private key. The signature is > computed over different value depending on whether signed attributes > > s/value/values/ Fixed. > are absent or present. When signed attributes are absent, the > HSS/LMS signature is computed over the content. When signed > > It might help the reader to put a paragraph break before "When signed > attributes are present..." Okay. Done. > 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 resulting hash > > I would replace "with" with "containing" or "whose value is" How about: ... a message-digest attribute is constructed to contain the resulting hash value, and ... > value, and then DER encode the set of signed attributes, which MUST > > For parallelism, this clause should start with a subject and a passive > verb. Perhaps "the DER encoding is constructed of ...". How about: ... and then the result of DER encoding the set of signed attributes, which ... > > include a content-type attribute and a message-digest attribute, and > > It might be clearer if the clause "which MUST ... attribute" was put > in parentheses. Okay. There are a lot of commas in this sentence. > then the HSS/LMS signature is computed over the output of the DER- > encode operation. In summary: > > You can probably change "the output of the DER-encode operation" with > "the DER encoding". How about: ... then the HSS/LMS signature is computed over the DER-encoded output. > The paragraph contains four clauses joined by three successive "and > then". You probably want to change that, perhaps breaking it out as a > numbered/bulleted list. (What does the Editor recommend?) I think the text is accurate. I wil wait for the RFC Editor to propose a different format if they want to do so. > And in this computation: > > IF (signed attributes are absent) > THEN HSS_LMS_Sign(content) > ELSE message-digest attribute = Hash(content); > > I think you want to add a hyphen: > s/message-digest attribute/message-digest-attribute/ No. This is the way that the attributes are talked about in RFC 5652. (See the indented paragraphs on Page 15 of RFC 5652 as an example.) > > HSS_LMS_Sign(DER(SignedAttributes)) Thanks again for the careful review. Russ
- [lamps] Genart last call review of draft-ietf-lam… Dale Worley via Datatracker
- Re: [lamps] [Gen-art] Genart last call review of … Russ Housley
- Re: [lamps] [Gen-art] Genart last call review of … Alissa Cooper