[COSE] Benjamin Kaduk's Discuss on draft-ietf-cose-hash-sig-07: (with DISCUSS and COMMENT)

[Benjamin Kaduk via Datatracker <[e-mail]>]

Benjamin Kaduk has entered the following ballot position for
draft-ietf-cose-hash-sig-07: Discuss

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/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-cose-hash-sig/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

I do see the previous discussion in
https://mailarchive.ietf.org/arch/msg/cose/E6ApKPKlESQQSZwySJAVF1l27OE
but I am still unclear on where exactly we can represent the octet
string that is the HMS-LMS public key.  Do we not need to define a COSE
Key Type Parameter (i.e., label) that maps to the public key value?  For
reference, the examples in Appendix C.7.1 of RFC 8152 include key/value
pairs with the negative map labels from
https://www.iana.org/assignments/cose/cose.xhtml#key-type-parameters
corresponding to the key type in question.
Hopefully I'm just confused and missing where this is already done, but
marking as a Discuss point in case I'm not.  (The linked
cose-wg/Examples seem to be using a JSON structure to describe the input
to the example generation, with the "public" and "private" members of
the "key" that do not seem to correspond to anything that I can find at
https://www.iana.org/assignments/jose/jose.xhtml#web-key-parameters, and
which would in any case not directly apply to the *COSE* usage.)


----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Related to the above Discuss, should we have an explicit statement that we do
not define a way to convey an HSS/LMS private key in a COSE_Key object?
(I think it is correct to not define such a thing, since conveying a
stateful private key is something of a non-sequitur.)


It's not entirely clear to me how much of RFC 8554 we need to duplicate
in order to give the reader an understanding of the signature structure
we're using.  A few times while reading Sections 2.x I had to
double-check that I was reading the right document :)

Section 1.1

   If large-scale quantum computers are ever built, these computers will
   be able to break many of the public-key cryptosystems currently in
   use.  A post-quantum cryptosystem [PQC] is a system that is secure
   against quantum computers that have more than a trivial number of
   quantum bits (qubits).  It is open to conjecture when it will be

(nit: they're also secure against quantum computers that do have a
trivial number of bits.  Yes, I know this is also true about classical
signature algorithms with sufficiently large keys, but the text here is
perhaps not making quite the point we want to make.)

   Since the HSS/LMS signature algorithm does not depend on the
   difficulty of discrete logarithm or factoring, the HSS/LMS signature
   algorithm is considered to be post-quantum secure.  The use of HSS/
   LMS hash-based signatures to protect software update distribution,
   perhaps using the format that is being specified by the IETF SUIT
   Working Group, will allow the deployment of software that implements
   new cryptosystems.

In light of the genart reviewer's comments, we could recast this as
"there is desire have HSS/LMS-based signatures available to protect
software update distribution, including from the IETF SUIT Working
Group" to place the focus on the desire, which is more easily fixed in
time, rather than the WG output, which will change with time.

Section 2.2

   Each tree in the hash-based signature algorithm specified in
   [HASHSIG] uses the Leighton-Micali Signature (LMS) system.  LMS
   systems have two parameters.  The first parameter is the height of
   the tree, h, which is the number of levels in the tree minus one.

I strongly suggest making it more clear that there are two (types of)
trees involved -- the HSS tree of Section 2.1, and a tree within a given
LMS signature (what's being discussed here).  Just using an unadorned
"the tree" is a recipe for confusion.

   The [HASHSIG] specification defines the value I as the private key
   identifier, and the same I value is used for all computations with
   the same LMS tree.  In addition, the [HASHSIG] specification defines

I think RFC 8554 uses I as the identifier for the key pair, not just the
private key, and it seems that in the COSE context we are more likely to
be referring to a public key than a private key.

Section 2.3

      n -  The number of bytes output by the hash function.  This
           specification supports only SHA-256 [SHS], with n=32.

      H -  A preimage-resistant hash function that accepts byte strings
           of any length, and returns an n-byte string.  This
           specification supports only SHA-256 [SHS].

Is supporting other n values basically just a matter of allocating from
a registry?  If so, we might want to tweak the wording a bit to leave
the possibility for such a generalization.

   The LM-OTS signature value can be summarized as the identifier of the
   LM-OTS variant, the random value, and a sequence of hash values (y[0]
   through y[p-1]) that correspond to the elements of the public key as
   described in Section 4.5 of [HASHSIG]:

nit: I'd consider a different wording than "correspond to"; the
correspondence is a bit hard to describe clearly, but "hash values that
include as input" (or similar) is IMO fairly clear.

Section 3

      o  The 'kty' field MUST be present, and it MUST be 'HSS-LMS'.

(Re. "MUST be present", I note that RFC 8152 already has """The element
"kty" is a required element in a COSE_Key map."""

      o  If the 'alg' field is present, and it MUST be 'HSS-LMS'.

nit: no "and".


Section 5

   To ensure that none of tree nodes are used to generate more than one
   signature, the signer maintains state across different invocations of
   the signing algorithm.  Section 12.2 of [HASHSIG] offers some
   practical implementation approaches around this statefulness.  In

There is no Section 12.2 in RFC 8554; is perhaps Section 9.2 the
intended one?