[lamps] Mike Bishop's No Objection on draft-ietf-lamps-pq-composite-sigs-15: (with COMMENT)

[Mike Bishop via Datatracker <[e-mail]>]

Mike Bishop has entered the following ballot position for
draft-ietf-lamps-pq-composite-sigs-15: 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-pq-composite-sigs/



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

Thank you for this work. This is an important step forward in our handling of
PQ crypto.

Section 3.1.1: There are a lot of MAY-examples in this section, when the whole
thing is an overarching "MAY do whatever internally so long as the external is
consistent." Consider not using MAY for every single example.

----

Section 4 has:

>   example, a stand-alone RSA private key can be encoded in Chinese
>   Remainder Theorem form.  In order to obtain interoperability,

Consider an informative reference?

----

Section 6 has:

>   Labels are represented here as ASCII strings, but implementers MUST
>   convert them to byte strings using the obvious ASCII conversions

While they may be obvious, calling them so comes across a bit oddly. Maybe just
say something like "Labels are represented here as ASCII strips, but are octet
sequences when used in..."

----

Consider moving Section 6.2 to an appendix; it's not part of the core protocol,
just design background.

----

In Section 9.1:

>   algorithm security or to provide migration flexibility.  Let's
>   quickly explore both.

It's typically advised to avoid first- or second-person language in
specifications. I'd just drop this final sentence, personally.

----

In Section 9.3:

>   designers are aware that some implementers may be forced to break
>   this rule due to operational constraints.  This section documents the
>   implications of doing so.

This statement makes me nervous. Maybe this section should explain why the MUST
exists, and not touch any implied "permission" to violate it?

----

In Section 9.4:

>   message which happens to start with this string.  The designers
>   accepted this trade-off.

I would remove this last sentence. You've explained the trade-off; it's up to
the implementers to decide whether it's worth making, no?

----

Consider moving Section 10 to an appendix.