Well, this is quite a blanket statement, without any substantiation of
claims.
If there would have been an issue, I would have expected you to
immediately call for withdrawing RFC 8692 [1], where - according to the
IESG ballot evaluation record [2] - you did not bring any conversion
issues up yourself. Instead, I have been waiting for over half a year
for a follow-up email on suggested resolution of a few small comments
you had on the draft (and still have not heard back to this date on the
June 9, 2021 email).
If you believe nothing of NIST can be trusted, I would have expected an
email marked "extremely urgent - all ietf" with any substantiation of
claims so that one can roll up one's sleeves and verify this and define
follow-up actions accordingly. Instead, I have not seen anything of this
type.
Given this, I have to say I am struggling with the ethical remarks.
Ref: [1] RFC 8692 - Internet X.509 Public Key Infrastructure, Additional
Algorithm Identifiers for RSASSA-PSS and ECDSA Using SHAKEs (December 2019)
[2] https://datatracker.ietf.org/doc/rfc8692/ballot/
On 2021-12-01 2:26 p.m., Benjamin Kaduk wrote:
On Wed, Dec 01, 2021 at 02:16:10PM -0500, Rene Struik wrote:
Please note, however, have no impact on the specification of ECDSA and
the iana cose codepoints for the invocations with SHAKE* functionality.
I think there is a question about whether all of NISTs publications
(including examples) are internally consistent. It is perhaps conceivable
that NIST would choose to make the published examples (and implementations
that used them as test vectors) the "correct" version and change the ECDSA
(or SHA-3/SHAKE) specification to resolve such an inconsistency, so I am
relucant to agree to a "no impact" determination. (Note that due to
illness and a busy schedule I am not caught up on all the relevant mail, so
maybe I missed some important previous traffic on this topic.)
To be frank: your comment is just about an (in your mind) one-line
glitch in two informational examples I included as courtesy to readers
to illustrate a specification.
I do not think that the scope of Ilari's concerns is limited to just this
"one-line glitch". I am hearing the sentiment that NIST has set things up
with a significant risk of a harmful "gotcha" for implementations, and that
by specifying codepoints for ECDSA with SHAKE* we are enabling that
"gotcha" and thereby incurring an ethical responsibility to include a
prominent disclaimer about the "gotcha" and how to avoid it. This is not
limited to the examples and we incur the responsibility just by specifying
the combination of ECDSA and SHAKE*, independently of whether we provide
examples of such functionality.
-Ben
--
email: [email protected] | Skype: rstruik
cell: +1 (647) 867-5658 | US: +1 (415) 287-3867
_______________________________________________
COSE mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/cose
