Subject: [lamps] I-D Action: draft-ietf-lamps-cms-hash-sig-05.txt

From: [email-masked]
Date: Fri, 22 Feb 2019 14:46:11 -0800

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Limited Additional Mechanisms for PKIX and SMIME WG of the IETF.

        Title           : Use of the HSS/LMS Hash-based Signature Algorithm in the Cryptographic Message Syntax (CMS)
        Author          : Russ Housley
	Filename        : draft-ietf-lamps-cms-hash-sig-05.txt
	Pages           : 14
	Date            : 2019-02-22

Abstract:
   This document specifies the conventions for using the the HSS/LMS
   hash-based signature algorithm with the Cryptographic Message Syntax
   (CMS).  In addition, the algorithm identifier and public key syntax
   are provided.  The HSS/LMS algorithm is one form of hash-based
   digital signature; it is described in [HASHSIG].

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-lamps-cms-hash-sig/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-lamps-cms-hash-sig-05
https://datatracker.ietf.org/doc/html/draft-ietf-lamps-cms-hash-sig-05

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-lamps-cms-hash-sig-05

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Russ Housley <[email-masked]>
Date: Fri, 22 Feb 2019 17:48:45 -0500

I believe that this version resolves the comments from Scott and Jim.

Russ

> On Feb 22, 2019, at 5:46 PM, [email-masked] wrote:
> 
>

---

From: Daniel Van Geest <[email-masked]>
Date: Mon, 25 Feb 2019 17:19:55 +0000

I think you didn’t mean to include this verbatim quote from Scott in the draft, since your edits to the previous paragraph include the same information.

   Well, yes, there is quite a range of possible time/memory trade-offs
   available when storing the private key; if you need to, the private
   key can be expressed in quite a small amount of space (albeit at the
   expense of making the signature generation operation expensive).

With the changes in the latest draft, a pre-hash is no longer signed, it’s either the content directly or the DER_encoded signed attributes (which will contain a hash of the content). I agree that this is the cleanest (and possibly intended) way of using HSS.  However, from a practical perspective I have concerns. I’m not an expert in how CMS is used in the real world, so maybe someone can address these concerns.  The primary use case for this draft is code signing.  Code can be very large.  If there are no signed attributes, the entire content is processed and signed by the HSS algorithm.  So, if the HSS algorithm is implemented in an HSM (and due to the statefulness of the algorithm it should really be implemented in an HSM) then the entire content to be signed needs to be transferred to the HSM. Do HSMs have enough memory to receive and store the entire content so that it can be signed? Could there be requirements on how quickly HSMs should process signing requests? Would those requirements be too negatively affected by the time required to transmit the entire content, and process the entire content within the HSM rather than just transmitting and processing a pre-hash?

Thanks,
Daniel

On 2019-02-22, 5:48 PM, "Spasm on behalf of Russ Housley" <[email-masked]<mailto:[email-masked]> on behalf of [email-masked]<mailto:[email-masked]>> wrote:

Russ

On Feb 22, 2019, at 5:46 PM, [email-masked]<mailto:[email-masked]> wrote:

_______________________________________________
Spasm mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/spasm

---

From: Russ Housley <[email-masked]>
Date: Mon, 25 Feb 2019 12:55:31 -0500

>    expense of making the signature generation operation expensive).

Indeed.  That was clearly an editing mistake.

> With the changes in the latest draft, a pre-hash is no longer signed, it’s either the content directly or the DER_encoded signed attributes (which will contain a hash of the content). I agree that…

I am aware of some HSMs that allow a stream-like interface for hash calculation.  Something like the interface original used by Ron Rivest for MD2 in RFC 1319 ...

	MD2Init (context);
	MD2Update (context, input, input_length);
	MD2Final (hash_value, context);

In the case of code signing, releases do not get signed too frequently, so an interface like this seems viable.  I am sure that improvements are possible.

If there are signed attributes, the information passed to the HSM is quite small, but the hash of the content does not include a salt value.

Russ

---

From: Jim Schaad <[email-masked]>
Date: Mon, 25 Feb 2019 10:06:16 -0800

In regards to the issue of code signing:

1.	If you use a content type other than id-data, then the use of SignedAttributes is required.  I am a strong advocate of identifying contents by OIDs if they are not just plain text string.  This means that I think that SignedAttributes is always present.
2.	Unlike the use of EdDSA, if you have identified the key and algorithm to the HSM prior to sending the content to the HSM then the content can be sent to the HSM in chucks and hashed in chucks as you go along.  EdDSA does have a requirement that the entire message be held in memory as the content is processed in two separate passes.
3.	My understanding is that in many cases what is to be signed is the manifest and the code image is going to be indirectly signed rather than being directly included in the manifest.  That means that you might be in the situation of already doing something similar to signed attributes already.

Jim

From: Spasm <[email-masked]> On Behalf Of Daniel Van Geest
Sent: Monday, February 25, 2019 9:20 AM
To: Russ Housley <[email-masked]>; [email-masked]
Subject: Re: [lamps] I-D Action: draft-ietf-lamps-cms-hash-sig-05.txt

Thanks,

Daniel

On 2019-02-22, 5:48 PM, "Spasm on behalf of Russ Housley" <[email-masked] <mailto:[email-masked]>  on behalf of [email-masked] <mailto:[email-masked]> > wrote:

Russ

On Feb 22, 2019, at 5:46 PM, [email-masked] <mailto:[email-masked]>  wrote:

        Author          : Russ Housley

           Pages           : 14

           Date            : 2019-02-22

Abstract:

Spasm mailing list

[email-masked] <mailto:[email-masked]>