[art] Re: draft-ietf-pquip-pqc-hsm-constrained-06 ietf last call Artart review

[Russ Housley <[e-mail]>]

My comments are resolved by this PR.

Russ

> On Jul 10, 2026, at 1:28 AM, K Tirumaleswar Reddy (Nokia) <[e-mail]> wrote:
> 
> Thanks Russ for the review, raised PR https://github.com/tireddy2/hsm-pqc/pull/77 to address them.
>  
> -Tiru
>  
> -----Original Message-----
> From: Russ Housley via Datatracker <[e-mail] <mailto:[e-mail]>> 
> Sent: Tuesday, July 7, 2026 1:17 AM
> To: [e-mail] <mailto:[e-mail]>
> Cc: [e-mail] <mailto:[e-mail]>; [e-mail] <mailto:[e-mail]>; [e-mail] <mailto:[e-mail]>
> Subject: draft-ietf-pquip-pqc-hsm-constrained-06 ietf last call Artart review
>  
>  
> CAUTION: This is an external email. Please be very careful when clicking links or opening attachments. See the URL nok.it/ext <http://nok.it/ext> for additional information.
>  
>  
>  
> Document: draft-ietf-pquip-pqc-hsm-constrained
> Title: Adapting Constrained Devices for Post-Quantum Cryptography
> Reviewer: Russ Housley
> Review result: Almost Ready
>  
> I am the assigned ART-ART reviewer for this draft. Please treat these comments just like any other last call comments.
>  
>  
> Document: draft-ietf-pquip-pqc-hsm-constrained-06
> Reviewer: Russ Housley
> Review Date: 2026-07-06
> IETF LC End Date: 2026-07-07
> IESG Telechat date: unknown
>  
> Summary: Almost Ready
>  
>  
> Major Concerns:
>  
> Section 3.1.3: This section needs a warning about the strength of the TLS keys and the key-encryption keys.  These need to be at least as strong and the PQC private key that is being protected.
>  
>  
> Minor Concerns:
>  
> Section 3:  The terms 'IDevID' and 'LDevID' come from IEEE 802.1AR.  Please include a reference to this document or some other place that has definitions.
>  
> Section 3.1.1: The text says:
>  
>    In many embedded deployments, SLH-DSA is
>    expected to be used primarily for firmware verification, in which
>    case key generation is performed offline and does not impact device
>    performance.  However, in scenarios where the device generates its
>    own SLH-DSA key pairs, the higher key generation cost may influence
>    seed-storage design decisions and depend on performance
>    considerations or standards compliance (e.g., PKCS#11).
>  
> In this case, the devide does not have access to the SLH-DSA private key.
> The use of 'off;ine' is not appropriate.   The private key is known only
> to the firmware signer; the firmware verifier only knows the public key.
>  
> Section 3.1.3.1: Why not other security protocols?  The end-to-end nature of TLS is important, but DTLS has that property too.  Maybe it would be better to list the properties of the security protocol that is needed, and provide TLS as an example.  Further, please prove a reference for TLS.
>  
> Section 3.1.3.2: It might be better to point to RFC 5649.  The expanded private key may not align with the block size of the symmetric algorithm.
>  
> Section 6.1.1: The text says:
>  
>    In firmware update and secure boot scenarios, signature verification
>    is typically performed during early boot stages, where the bootloader
>    has exclusive access to system resources.  In such environments, the
>    practical impact of resource constraints on signature verification is
>    reduced compared to general runtime environments.
>  
> The discussion of new firmware installation deserves a discussion.  In some devices, it is important to check the next generation of firmware while the current generation is running.  The goal is minimal downtime during a swap.
>  
>  
> Nits:
>  
> In the datatracker, the value for 'Consensus boilerplate' needs to be set.
>  
> Section 3,1.2: s/seeds with each request/seeds for each operation/
>  
> Section 4: s/flavours/flavors/
>  
> Section 6: s/due to<br/><br/>their construction/due to their construction/
>  
> IDnits complains thet:
>   == The document doesn't use any RFC 2119 keywords, yet seems to have RFC
>      2119 boilerplate text.