MIME-Version: 1.0
References: 
 <177505503029.1878830.18439971232258801938@dt-datatracker-5775bcb475-pnkww>
In-Reply-To: 
 <177505503029.1878830.18439971232258801938@dt-datatracker-5775bcb475-pnkww>
From: Mike Ounsworth <ounsworth+ietf@gmail.com>
Date: Wed, 8 Apr 2026 19:41:04 -0500
Message-ID: 
 <CAKZgXHpMPz1vTfnhSzW9YVmyD3dABCw6S_mp3DQcV0+p-2=m2w@mail.gmail.com>
To: Mike Bishop <mbishop@evequefou.be>
Content-Type: multipart/alternative; boundary="0000000000002d9675064efc46a1"
Message-ID-Hash: QH67QV7HITWXZM5I72SJTPI2EKGM7QI7
CC: The IESG <iesg@ietf.org>, draft-ietf-lamps-pq-composite-sigs@ietf.org,
 housley@vigilsec.com, lamps-chairs@ietf.org, spasm@ietf.org
Precedence: list
Subject: =?utf-8?q?=5Blamps=5D_Re=3A_Mike_Bishop=27s_No_Objection_on_draft-ietf-lamps?=
 =?utf-8?q?-pq-composite-sigs-15=3A_=28with_COMMENT=29?=
Archived-At: 
 <https://mailarchive.ietf.org/arch/msg/spasm/bG6zR5gxoFZFtUkWQOSUQgCuE5Q>

--0000000000002d9675064efc46a1
Content-Type: text/plain; charset="UTF-8"

Hi @Mike Bishop

Thanks for the careful review.

I have made these changes here:
https://github.com/lamps-wg/draft-composite-sigs/commit/c2d3ca12014874ab5adbc3a4750ed59e36c54011


I think this COMMENT of yours is really astute and probably actually should
be a DISCUSS. So let's discuss ;)

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?


That section basically says "We are aware that people are going to have to
violate the core security requirement of the draft, so let's analyse
exactly what happens when you do".
Trust me, it also makes me nervous. Very nervous.
I have a customer in this situation, and trust me, I have tried my hardest
to talk them out of it.
The thinking here is that if we can't stop it, then at least we can
document what sharp pointy edges you need to watch out for.
Thoughts?

On Wed, 1 Apr 2026 at 09:50, Mike Bishop via Datatracker <noreply@ietf.org>
wrote:

> 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.
>
>
>
> _______________________________________________
> Spasm mailing list -- spasm@ietf.org
> To unsubscribe send an email to spasm-leave@ietf.org
>

--0000000000002d9675064efc46a1
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>Hi=C2=A0<a class=3D"gmail_plusreply" id=3D"plusReplyC=
hip-0">@Mike Bishop</a></div><div><br></div><div>Thanks for the careful rev=
iew.</div><div><br></div><div>I have made these changes here:</div><div><a =
href=3D"https://github.com/lamps-wg/draft-composite-sigs/commit/c2d3ca12014=
874ab5adbc3a4750ed59e36c54011">https://github.com/lamps-wg/draft-composite-=
sigs/commit/c2d3ca12014874ab5adbc3a4750ed59e36c54011</a></div><div><br></di=
v><div><br></div><div>I think this COMMENT of yours is really astute and pr=
obably actually should be a DISCUSS. So let&#39;s discuss ;)</div><div><br>=
</div><div><pre class=3D"gmail-wordwrap">In Section 9.3:

&gt;   designers are aware that some implementers may be forced to break
&gt;   this rule due to operational constraints.  This section documents th=
e
&gt;   implications of doing so.

This statement makes me nervous. Maybe this section should explain why the =
MUST
exists, and not touch any implied &quot;permission&quot; to violate it?</pr=
e><br></div><div>That section basically says &quot;We are aware that people=
 are going to have to violate the core security requirement of the draft, s=
o let&#39;s analyse exactly what happens when you do&quot;.</div><div>Trust=
 me, it also makes me nervous. Very nervous.</div><div>I have a customer in=
 this situation, and trust me, I have tried my hardest to talk them out of =
it.</div><div>The thinking here is that if we can&#39;t stop it, then at le=
ast we can document what sharp pointy edges you need to watch out for.</div=
><div>Thoughts?</div></div><br><div class=3D"gmail_quote gmail_quote_contai=
ner"><div dir=3D"ltr" class=3D"gmail_attr">On Wed, 1 Apr 2026 at 09:50, Mik=
e Bishop via Datatracker &lt;<a href=3D"mailto:noreply@ietf.org">noreply@ie=
tf.org</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"m=
argin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left=
:1ex">Mike Bishop has entered the following ballot position for<br>
draft-ietf-lamps-pq-composite-sigs-15: No Objection<br>
<br>
When responding, please keep the subject line intact and reply to all<br>
email addresses included in the To and CC lines. (Feel free to cut this<br>
introductory paragraph, however.)<br>
<br>
<br>
Please refer to <a href=3D"https://www.ietf.org/about/groups/iesg/statement=
s/handling-ballot-positions/" rel=3D"noreferrer" target=3D"_blank">https://=
www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/</a> <b=
r>
for more information about how to handle DISCUSS and COMMENT positions.<br>
<br>
<br>
The document, along with other ballot positions, can be found here:<br>
<a href=3D"https://datatracker.ietf.org/doc/draft-ietf-lamps-pq-composite-s=
igs/" rel=3D"noreferrer" target=3D"_blank">https://datatracker.ietf.org/doc=
/draft-ietf-lamps-pq-composite-sigs/</a><br>
<br>
<br>
<br>
----------------------------------------------------------------------<br>
COMMENT:<br>
----------------------------------------------------------------------<br>
<br>
Thank you for this work. This is an important step forward in our handling =
of<br>
PQ crypto.<br>
<br>
Section 3.1.1: There are a lot of MAY-examples in this section, when the wh=
ole<br>
thing is an overarching &quot;MAY do whatever internally so long as the ext=
ernal is<br>
consistent.&quot; Consider not using MAY for every single example.<br>
<br>
----<br>
<br>
Section 4 has:<br>
<br>
&gt;=C2=A0 =C2=A0example, a stand-alone RSA private key can be encoded in C=
hinese<br>
&gt;=C2=A0 =C2=A0Remainder Theorem form.=C2=A0 In order to obtain interoper=
ability,<br>
<br>
Consider an informative reference?<br>
<br>
----<br>
<br>
Section 6 has:<br>
<br>
&gt;=C2=A0 =C2=A0Labels are represented here as ASCII strings, but implemen=
ters MUST<br>
&gt;=C2=A0 =C2=A0convert them to byte strings using the obvious ASCII conve=
rsions<br>
<br>
While they may be obvious, calling them so comes across a bit oddly. Maybe =
just<br>
say something like &quot;Labels are represented here as ASCII strips, but a=
re octet<br>
sequences when used in...&quot;<br>
<br>
----<br>
<br>
Consider moving Section 6.2 to an appendix; it&#39;s not part of the core p=
rotocol,<br>
just design background.<br>
<br>
----<br>
<br>
In Section 9.1:<br>
<br>
&gt;=C2=A0 =C2=A0algorithm security or to provide migration flexibility.=C2=
=A0 Let&#39;s<br>
&gt;=C2=A0 =C2=A0quickly explore both.<br>
<br>
It&#39;s typically advised to avoid first- or second-person language in<br>
specifications. I&#39;d just drop this final sentence, personally.<br>
<br>
----<br>
<br>
In Section 9.3:<br>
<br>
&gt;=C2=A0 =C2=A0designers are aware that some implementers may be forced t=
o break<br>
&gt;=C2=A0 =C2=A0this rule due to operational constraints.=C2=A0 This secti=
on documents the<br>
&gt;=C2=A0 =C2=A0implications of doing so.<br>
<br>
This statement makes me nervous. Maybe this section should explain why the =
MUST<br>
exists, and not touch any implied &quot;permission&quot; to violate it?<br>
<br>
----<br>
<br>
In Section 9.4:<br>
<br>
&gt;=C2=A0 =C2=A0message which happens to start with this string.=C2=A0 The=
 designers<br>
&gt;=C2=A0 =C2=A0accepted this trade-off.<br>
<br>
I would remove this last sentence. You&#39;ve explained the trade-off; it&#=
39;s up to<br>
the implementers to decide whether it&#39;s worth making, no?<br>
<br>
----<br>
<br>
Consider moving Section 10 to an appendix.<br>
<br>
<br>
<br>
_______________________________________________<br>
Spasm mailing list -- <a href=3D"mailto:spasm@ietf.org" target=3D"_blank">s=
pasm@ietf.org</a><br>
To unsubscribe send an email to <a href=3D"mailto:spasm-leave@ietf.org" tar=
get=3D"_blank">spasm-leave@ietf.org</a><br>
</blockquote></div>

--0000000000002d9675064efc46a1--