MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: Roman Danyliw via Datatracker <noreply@ietf.org>
To: "The IESG" <iesg@ietf.org>
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: 
 <173628429221.2059407.15874262587531331514@dt-datatracker-65f549669d-2xld9>
Date: Tue, 07 Jan 2025 13:11:32 -0800
Message-ID-Hash: TEQY7QYTJP654MA3K2IAFALVGWAR5H2N
CC: draft-ietf-lamps-cms-sphincs-plus@ietf.org, lamps-chairs@ietf.org,
 spasm@ietf.org, tim.hollebeek@digicert.com
Reply-To: Roman Danyliw <rdd@cert.org>
Subject: =?utf-8?q?=5Blamps=5D_Roman_Danyliw=27s_No_Objection_on_draft-ietf-lamps-cms?=
	=?utf-8?q?-sphincs-plus-17=3A_=28with_COMMENT=29?=
Archived-At: 
 <https://mailarchive.ietf.org/arch/msg/spasm/Hy_UIMUqhUEqUwC29IZqyrLzKC4>

Roman Danyliw has entered the following ballot position for
draft-ietf-lamps-cms-sphincs-plus-17: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ 
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-lamps-cms-sphincs-plus/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Thank you to Vijay Gurbani for the GENART review.

** Section 1.2
   One use of a PQC signature algoritm is the protection of software
   updates, perhaps using the format described in [RFC4108], to enable
   deployment of software that implements other new PQC algorithms for
   key management and confidentiality.

-- Typo. s/algoritm/algorithm/

-- Editorial.  Is this paragraph needed?  It seems out of place in its
specificity.  Is the primary use of CMS for software updates?

** Section 3. Editorial.  Consider an explicit sentence here citing that the
identifiers come from [FIPS205].

** Section 4
      When signed attributes are present, to ensure
      collision resistance, the identified hash function SHOULD produce
      a hash value that is at least twice the size of the hash function
      used in the SLH-DSA tree.

When would it be acceptable not seek collision resistance and choose a hash
function which does NOT produce a hash value that is at least twice the size of
the hash function?

** Section 5.
    Implementers SHOULD consider …

(used twice in this section)

What does it mean to “SHOULD consider …” a topic?  This is an optional
adherence (“SHOULD”) to a non-binding review (“consider”).

** Section 6.
   If slh_sign is implemented in a hardware device such as hardware
   security module (HSM) or portable cryptographic token,
   implementations might want to avoid sending the full content to the
   device.

What does “might want to” mean in terms of guidance?