Hi all,
We have updated the document as described. However, we have a couple of
followup questions.
1) Use of “as well as” makes it sound as though the national standards for
China and the ISO/IEC standards are different. We think the intent is to say
that this specification uses SM cryptographic algorithms, which are national
standards for China and are used in ISO/IEC standards. If this is correct,
please consider the following update:
Current:
It makes use of cryptographic algorithms that
are national standards for China, as well as ISO/IEC standards (ISO/
IEC 14888:3-2018 [ISO-IEC14888-3_2018] and ISO/IEC 10118:3-2018
[ISO-IEC10118-3_2018]).
Perhaps:
It makes use of SM cryptographic algorithms, which
are national standards for China and are used in ISO/IEC standards
(ISO/IEC 14888:3-2018 [ISO-IEC14888-3_2018] and ISO/IEC 10118:3-2018
[ISO-IEC10118-3_2018]).
2) With the addition of the following text, we have included an informative
reference to RFC 6840. Please let us know if it should be normative instead.
Many implementations may not support SM2 signatures and SM3 digests.
Section 5.2 of [RFC6840] specifies handling of answers in such cases.
Diffs of the recent updates only:
https://www.rfc-editor.org/authors/rfc9563-lastdiff.html
https://www.rfc-editor.org/authors/rfc9563-lastrfcdiff.html
Comprehensive diffs:
https://www.rfc-editor.org/authors/rfc9563-diff.html
https://www.rfc-editor.org/authors/rfc9563-rfcdiff.html
AUTH48 diff:
https://www.rfc-editor.org/authors/rfc9563-auth48diff.html
Thanks,
RFC Editor/sg
On Sep 12, 2024, at 2:21 AM, zhangcuiling<[email protected]>
wrote:
Hi Eliot,
Thanks for your reminding.
Hi Sandy,
Please kindly add two new paragraphs to Introduction section.
Many implementations may not support SM2 signatures and SM3 digests. RFC 6840
Section 5.2 specifies handling of answers in such cases.
Caution: This specification is not a standard and does not have IETF community
consensus. It makes use of cryptographic algorithms that are national standards
for China, as well as ISO/IEC standards (ISO/IEC 14888:3-2018 and ISO/IEC
10118:3-2018). Neither the IETF nor the IRTF has analyzed that algorithm for
suitability for any given application, and it may contain either intended or
unintended weaknesses.
Thanks a lot.
Regards,
Cathy
From: Independent Submissions Editor (Eliot Lear)
Date: 2024-09-11 18:01
To: zhangcuiling; Sandy Ginoza
CC: rfc-editor; 刘昱琨; lengfeng; zhaoqi; hezh; Alexis Rossi; auth48archive
Subject: Re: AUTH48: RFC-to-be 9563 <draft-cuiling-dnsop-sm2-alg-15> for your
review
Actually, Cathy, if we can ask for the assistance of the RFC Editor, they can
make the changes from here. Just tell them what you want.
On 11.09.2024 11:01, zhangcuiling wrote:
Hi Eliot,
Thanks for your prompt reply.
I would make the following two modifications in the next version of the draft.
Regards,
Cathy
From: Independent Submissions Editor (Eliot Lear)
Date: 2024-09-11 15:58
To: zhangcuiling; Sandy Ginoza
CC: rfc-editor; 刘昱琨; lengfeng; zhaoqi; hezh; Alexis Rossi; auth48archive
Subject: Re: AUTH48: RFC-to-be 9563 <draft-cuiling-dnsop-sm2-alg-15> for your
review
Hi Cathy,
On 11.09.2024 08:51, zhangcuiling wrote:
Hi Eliot and Sandy,
About the new comment:
Many implementations may not support SM2 signatures and digests. RFC 6840
Section 5.2 specifies handling of answers in such cases.
The example is pretty clear and it's OK to add it to the document. One small
change:
Many implementations may not support SM2 signatures and SM3 digests. RFC
6840 Section 5.2 specifies handling of answers in such cases.
That's fine.
I'm not sure about the location of this part, because I just found RFC 9558 has
similar description in section 6 Implementation Considerations, not in section
1 Introduction.
Yes, that's right. I would suggest that it's not necessary to create a new
section for two sentences, but if you want to, you can. Your call. What is
important is that implementers understand what the expected behavior will be
from implementations that do not understand SM2/SM3.
I'll add these sentences to the introduction section.
About the 'caution' paragragh:
Most of this statement is OK for us, except one detail.
Although ShangMi (SM) cryptographic algorithms haven't been analyzed by the
IETF and the IRTF, SM2 and SM3 algorithms have been added to ISO/IEC standards.
So is it possible to remove the third sentence, to avoid the misunderstanding
that these algorithms are just national standards instead of international
standards?
Or is it possible to change the second sentence to:
It makes use of cryptographic algorithms that are national standards for
China, as well as ISO/IEC standards (ISO/IEC 14888:3-2018 and ISO/IEC
10118:3-2018).
I'm sorry, but that's not possible. This came about as an interim means to
address IETF and IAB concerns about national cryptography. However, it is fine
to add a sentence above to refer to the ISO standard. FWIW, your document will
probably be the last crypto I publish for a good period of time, while the IETF
tries to figure out what the long term approach should be.
And the following paragragh, too.
Caution: This specification is not a standard and does not have IETF community
consensus. It makes use of cryptographic algorithms that are national standards
for China, as well as ISO/IEC standards (ISO/IEC 14888:3-2018 and ISO/IEC
10118:3-2018). Neither the IETF nor the IRTF has analyzed that algorithm for
suitability for any given application, and it may contain either intended or
unintended weaknesses.
Eliot
