[lamps] Benjamin Kaduk's Discuss on draft-ietf-lamps-cms-hash-sig-09: (with DISCUSS and COMMENT)

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

Benjamin Kaduk has entered the following ballot position for
draft-ietf-lamps-cms-hash-sig-09: 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-lamps-cms-hash-sig/



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

Two fairly minor points that should be easy to resolve, but seem to be
worth some time:

I think we need to be a bit more clear about what exactly the contents
of the signature OCTET STRING are.  Section 3 has a fairly abstract note
about including enough information to be self-describing (within the
HSS/LMS variants), and Section 5 does better with "the single HSS
signature value resulting from the signing operation as specified in
[HASHSIG]", but it doesn't seem too burdensome to say something like
"the string returned from Algorithm 3 in [RFC8554]" or even refer back
to the description language at the end of Section 2 and avoid any
confusion.

Section 5 has a "MUST" for using the same hash for the CMS
digestAlgorithm and the HSS/LMS tree, but Section 6 only has a "SHOULD"
for the message-digest attribute's digest and the signed attributes
digest (the latter of which MUST be the HSS/LMS hash per the previous);
should these two requirements be at the same level of normativity?  I'm
not sure why the one would be more important for correct operation than
the other.


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

Section 1

   based digital signature, and it is described in [HASHSIG].  The
   HSS/LMS signature algorithm can only be used for a fixed number of
   signing operations.  [...]

nit: with a given key

   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 (qu-bits).  It is open to conjecture when it will be

nit(?): I'm much more used to seeing "q-bits" or "qbits" than "qu-bits".

Section 2.2

It's a bit unfortunate that we have to mix 0- (signed public keys) and
1-based (tree nodes) indexing, but it seems that this is inherent in RFC
8554 and not really avoidable in this document.

Section 3

   The signature value identifies the hash function used in the HSS/LMS
   tree.  In [HASHSIG] only the SHA-256 hash function [SHS] is
   supported, but it also establishes an IANA registry [IANA-LMS] to
   permit the registration of additional hash functions in the future.

(This pattern occurs in several places, but I pick an arbitrary one to
comment on) I am not sure that the "In [HASHSIG] only <foo> is
supported, but it also establishes an IANA registry" is going to present
the best interface to readers; the language in Section 2 about "the
algorithm specified in [HASHSIG] currently only uses <foo>, but it also
establishes an IANA registry to permit the registration of additional
[...]" seems to give more emphasis on the registry as opposed to the
snapshot in [HASHSIG].  On the other hand, someone is probably going to
complain that "currently" will not age well...

Section 4

It feels a little surprising to make explicit requirements on the
keyUsage contents but not say anything about extendedKeyUsage.  Having a
static whitelist of EKU OIDs is not reasonable, of course, and the
PUBLIC-KEY class from RFC 5912 only covers regular keyUsage, but some
advice about "encipherment methods are not going to make sense" might
still be appropriate.

   The public key value is an OCTET STRING.  Like the signature format,
   it is designed for easy parsing.  The value is the number of levels
   in the public key, L, followed by the LMS public key.

   The HSS/LMS public key value can be summarized as:

      u32str(L) || lms_public_key

"Can be summarized as" does not say to me "here is a rigorous protocol
specification" (though it does seem to actually be one, given the
notation used in this document and 8554).  So unlike the signature OCTET
STRING contents, this one is not DISCUSS-worthy, since it's in the same
section as the thing being described.

Section 5

   When signed attributes are absent, the HSS/LMS signature is computed
   over the content.  When signed 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 to contain the resulting hash value, and then the result
   of DER encoding the set of signed attributes (which MUST include a
   content-type attribute and a message-digest attribute, and then the
   HSS/LMS signature is computed over the DER-encoded output.  In

nit(?): is this "the message-digest attribute" constructed in the
previous step (as opposed to any old message-digest attribute)?

Section 6

   tracking data can cause a one-time key to be used more than once.  As
   a result, when a private key and the tracking data are stored on non-
   volatile media or stored in a virtual machine environment, care must
   be taken to preserve confidentiality and integrity.

It might be worth explicitly noting "in the face of failed writes,
virtual machine snapshotting or cloning, and other operational
concerns".

Appendix: ASN.1 Module

   MTS-HashSig-2013

Once written, the module name can never change? :)