Cathy,

Could you please contact CSTC?  The HTTP server is not responding to queries I am seeing complaints.


Eliot


On 18.11.2024 08:54, zhangcuiling wrote:
Hi Sandy and Eliot,

CSTC has uploaded the translated standards, and the links are as follows:

GMT-0003.1
SM2 Public Key Cryptographic Algorithms Based on Elliptic Curves Part 1: General
http://www.gmbz.org.cn/upload/2024-11-18/1731899501687024253.pdf

GMT-0003.2
SM2 Public Key Cryptographic Algorithms Based on Elliptic Curves Part 2: Digital Signature Algorithm
http://www.gmbz.org.cn/upload/2024-11-18/1731899583359013934.pdf

GMT-0004
SM3 Cryptographic Hash Algorithm
http://www.gmbz.org.cn/upload/2024-11-18/1731899426565012428.pdf

And [GBT-32918.1-2016], [GBT-32918.2-2016] and [GBT-32905-2016] could be removed from "9.1. Normative References" list.

Thanks a lot for your patience.

Best regards,
Cathy

    *From:* Independent Submissions Editor (Eliot Lear)
    <mailto:[email protected]>
    *Date:* 2024-10-22 23:15
    *To:* zhangcuiling <mailto:[email protected]>; Sandy Ginoza
    <mailto:[email protected]>
    *CC:* rfc-editor <mailto:[email protected]>; 刘昱琨
    <mailto:[email protected]>; lengfeng <mailto:[email protected]>;
    zhaoqi <mailto:[email protected]>; hezh <mailto:[email protected]>;
    Alexis Rossi <mailto:[email protected]>; auth48archive
    <mailto:[email protected]>
    *Subject:* Re: AUTH48: RFC-to-be 9563
    <draft-cuiling-dnsop-sm2-alg-15> for your review

    Thank you, Cathy. We await your update.


    Eliot


    On 22.10.2024 11:00, zhangcuiling wrote:
    Hi Sandy and Eliot,

    I've checked with CSTC about the progress again.
    The translated standards need a final confirmation review, which
    probably will be held in two weeks.
    The standards will be published on http://gmbz.org.cn shortly
    after the meeting.
    I'll submit the links as soon as possible.
    Sorry for the long wait and thanks for your patience.

    Regards,

    Cathy

        *From:* Independent Submissions Editor (Eliot Lear)
        <mailto:[email protected]>
        *Date:* 2024-10-22 14:34
        *To:* Sandy Ginoza <mailto:[email protected]>
        *CC:* zhangcuiling <mailto:[email protected]>; RFC Editor
        <mailto:[email protected]>; 刘昱琨
        <mailto:[email protected]>; lengfeng
        <mailto:[email protected]>; zhaoqi <mailto:[email protected]>;
        hezh <mailto:[email protected]>; Alexis Rossi
        <mailto:[email protected]>; auth48archive
        <mailto:[email protected]>
        *Subject:* Re: AUTH48: RFC-to-be 9563
        <draft-cuiling-dnsop-sm2-alg-15> for your review

        Hi Sandy,

        I am waiting for those references as well.

        Eliot

        On 22.10.2024 01:13, Sandy Ginoza wrote:
        Hi Eliot and Cathy,
        We’re checking the status of this document.  Are any updates required?
        Cathy, please let us know when and where the referenced translations 
are available.
        Thanks,
        RFC Editor/sg
        On Sep 20, 2024, at 4:05 AM, Independent Submissions Editor (Eliot 
Lear)<[email protected]> wrote:
        Ok.  Thank you, Cathy.
        Sandy, I intend to send a note to SAAG about this draft on Monday.  
Please HOLD for publication for now but I expect to sign off by later next week.
        Regards,
        Eliot
        On 20.09.2024 12:47, zhangcuiling wrote:
        Hi Sandy,
        Thanks for your work.
        And no objection to the suggestions.
        Regards,
        Cathy
From: Independent Submissions Editor (Eliot Lear)
        Date: 2024-09-20 15:28
        To: Sandy Ginoza; zhangcuiling
        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
        Sandy,
        Thank you.  Cathy, please respond with your concurrence or proposed 
edits.
        Eliot
        On 19.09.2024 23:28, Sandy Ginoza wrote:
        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
-- 
auth48archive mailing list -- [email protected]
To unsubscribe send an email to [email protected]
  • [auth48] Re:... Independent Submissions Editor (Eliot Lear) via auth48archive
    • [auth48... Sandy Ginoza via auth48archive
      • [au... zhangcuiling via auth48archive
    • [auth48... Independent Submissions Editor (Eliot Lear) via auth48archive
      • [au... zhangcuiling via auth48archive
        • ... zhangcuiling via auth48archive
          • ... Independent Submissions Editor (Eliot Lear) via auth48archive

Reply via email to