Re: [auth48] *[ISE] Re: AUTH48: RFC-to-be 9548 <draft-pkcs12-gost-08> for your review

[Karelina Ekaterina <[e-mail]>]

Hi,

I've made a request for the registry oid-info.com
The description of "1.2.643.7.1.0.2" identifier has already been corrected.
"1.2.643.7.1.0.5" identifier is still being checked to be added to the registry.

Kate

-----Original Message-----
From: Independent Submissions Editor (Eliot Lear) <[e-mail]> 
Sent: Friday, April 12, 2024 7:03 PM
To: Lynne Bartholomew <[e-mail]>
Cc: Karelina Ekaterina <[e-mail]>; [e-mail]; [e-mail]
Subject: Re: *[ISE] Re: AUTH48: RFC-to-be 9548 <draft-pkcs12-gost-08> for your review

Hi Lynne,

Yes.  This document must be held until we have officially assigned 
OIDs.  I'm sorry we didn't catch this earlier.  Kate, if you are unable 
to get the OIDs assigned in the Russian arc, you could conceivably use a 
vendor arc.

Eliot

On 12.04.2024 17:49, Lynne Bartholomew wrote:
> Hi, Eliot.
>
> Checking in with you to confirm that we need to continue holding this document until the OID situation gets sorted out.
>
> Thank you!
>
> RFC Editor/lb
>
>> On Mar 13, 2024, at 2:22 PM, Lynne Bartholomew <[e-mail]> wrote:
>>
>> Hi, Kate and Eliot.
>>
>> Kate, thank you for the improved line breaks for Appendix A.3.2.
>>
>> The latest files are here.  Please refresh your browser:
>>
>>    https://www.rfc-editor.org/authors/rfc9548.txt
>>    https://www.rfc-editor.org/authors/rfc9548.pdf
>>    https://www.rfc-editor.org/authors/rfc9548.html
>>    https://www.rfc-editor.org/authors/rfc9548.xml
>>    https://www.rfc-editor.org/authors/rfc9548-diff.html
>>    https://www.rfc-editor.org/authors/rfc9548-rfcdiff.html
>>    https://www.rfc-editor.org/authors/rfc9548-auth48diff.html
>>    https://www.rfc-editor.org/authors/rfc9548-lastdiff.html
>>    https://www.rfc-editor.org/authors/rfc9548-lastrfcdiff.html
>>
>>    https://www.rfc-editor.org/authors/rfc9548-xmldiff1.html
>>    https://www.rfc-editor.org/authors/rfc9548-xmldiff2.html
>>
>> Thanks again!
>>
>> RFC Editor/lb
>>
>>
>>> From: "Independent Submissions Editor (Eliot Lear)" <[e-mail]>
>>> Subject: Re: *[ISE] Re: AUTH48: RFC-to-be 9548 <draft-pkcs12-gost-08> for your review
>>> Date: March 13, 2024 at 1:35:45 PM PDT
>>> To: Karelina Ekaterina <[e-mail]>, Lynne Bartholomew <[e-mail]>
>>> Cc: "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>
>>>
>>> Hi Kate,
>>> On 13.03.2024 21:28, Karelina Ekaterina wrote:
>>>> This OID is newly introduced in this document.
>>>> In this case, does it need to be registered in the database before publishing the rfc?
>>> Yes.  And because of the branch that it is in you must find the right controller for that entry.
>>> I was able to find this information on the web.  You might try contacting this person:
>>>
>>>> Marina Ignatyeva
>>>> Address: Joint Stock Company (JSC) InfoTeCS Internet Trust
>>>> 1/23, building 1
>>>> Stary Petrovsko-Razumovsky proyezd
>>>> Moscow, 127827
>>>> Russian Federation (the) Phone: [phone] Fax: [phone]
>>> See http://oidref.com/1.2.643
>>> We'll hold the document until this gets sorted.
>>> Eliot
>>
>>> On Mar 13, 2024, at 1:28 PM, Karelina Ekaterina <[e-mail]> wrote:
>>>
>>> Hi,
>>>
>>> 1) >> Per our typical process of defining terms that might not be well known to readers, we expanded "PFX" in the document title, Abstract, and Introduction.  Please let us know any objections.
>>>
>>> No objections.
>>>
>>> 2) In return to the OIDs' issues, I'he figured out:
>>>
>>> a) >>We could not get output for "pkcs-12ruSyntax(5)" on the OID repository (http://www.oid-info.com/index.htm).
>>>>> 1.2.643.7.1.0.5 yields an error, as seen on <http://www.oid-info.com/cgi-bin/display?oid=1.2.643.7.1.0.5&a=display>.
>>>>> Original:
>>>>> PKCS-12RU
>>>>> {
>>>>> iso(1) member-body(2) ru(643) rosstandart(7)
>>>>> tc26(1) modules(0) pkcs-12ruSyntax(5)  }
>>>>> Backing out one level, we see the following on
>>>>> <http://www.oid-info.com/cgi-bin/display?oid=1.2.643.7.1.0&action=display>:
>>>>> modules(0)
>>>>> child OIDs:
>>>>> gostR3411-2012-PKISyntax(2)
>>>>> ruStrongCertsSyntax(6)
>>>>> Please let us know if any updates are needed.  Is "pkcs-12ruSyntax(5)"
>>>>> an unregistered entry?
>>> This OID is newly introduced in this document.
>>> In this case, does it need to be registered in the database before publishing the rfc?
>>>
>>>
>>> b) >>We did not find a match for "gostR3410-2012-PKISyntax(2)" on <http://www.oid-info.com/index.htm>.
>>>
>>>>> Original:
>>>>> FROM GostR3410–2012-PKISyntax
>>>>> {
>>>>>    iso(1) member-body(2) ru(643) rosstandart(7) tc26(1)
>>>>>    modules(0) gostR3410–2012-PKISyntax(2)  };
>>>>> We see the following on
>>>>> <http://www.oid-info.com/cgi-bin/display?oid=1.2.643.7.1.0.2&a=display>:
>>>>> gostR3411-2012-PKISyntax(2)
>>>>> Is the "3410" entry an unregistered entry?  We also see
>>>>> gostR3410-2012-PKISyntax(2) at the beginning of Appendix A of RFC 9215. -->
>>> There must have been an error while registering this OID in the database.
>>> Correct OID is "gostR3410-2012-PKISyntax(2)"  (https://tc26.ru/about/protsedury-i-reglamenty/identifikatory-obektov-oid-tekhnicheskogo-komiteta-po-standartizatsii-kriptograficheskaya-zashchita-1.html )
>>>
>>>
>>>
>>> 3) >>) <!-- [rfced] Appendices A.2.2 and subsequent...
>>>
>>>
>>> NEW text for xml-doc:
>>>
>>>            <section anchor="PFX_ASN_Ex2">
>>>            <name>PFX in ASN.1 Format</name>
>>> <sourcecode type="asn.1"><![CDATA[
>>> 0 1420:SEQUENCE:
>>>   4    1:  INTEGER:3
>>>   7 1317:  SEQUENCE:
>>> 11    9:   OBJECT IDENTIFIER:data [1.2.840.113549.1.7.1]
>>> 22 1302:   CONTEXT SPECIFIC (0):
>>> 26 1298:     OCTET STRING:
>>> 30 1294:      SEQUENCE:
>>> 34  833:        SEQUENCE:
>>> 38    9:         OBJECT IDENTIFIER:
>>>         :          encryptedData [1.2.840.113549.1.7.6]
>>> 49  818:         CONTEXT SPECIFIC (0):
>>> 53  814:           SEQUENCE:
>>> 57    1:            INTEGER:0
>>> 60  807:            SEQUENCE:
>>> 64    9:              OBJECT IDENTIFIER:data [1.2.840.113549.1.7.1]
>>> 75   85:              SEQUENCE:
>>> 77    9:               OBJECT IDENTIFIER:[1.2.840.113549.1.5.13]
>>> 88   72:               SEQUENCE:
>>> 90   41:                 SEQUENCE:
>>> 92    9:                  OBJECT IDENTIFIER:[1.2.840.113549.1.5.12]
>>> 103   28:                  SEQUENCE:
>>> 105    8:                    OCTET STRING:'14B92546B12C068D'
>>> 115    2:                    INTEGER:2048
>>> 119   12:                    SEQUENCE:
>>> 121    8:                     OBJECT IDENTIFIER:[1.2.643.7.1.1.4.2]
>>> 131    0:                     NULL:
>>> 133   27:                 SEQUENCE:
>>> 135    9:                  OBJECT IDENTIFIER:[1.2.643.7.1.1.5.1.2]
>>> 146   14:                  SEQUENCE:
>>> 148   12:                    OCTET STRING:
>>>         :                     F4793775A82D4B8F3E1BFC7E
>>> 162  705:              CONTEXT SPECIFIC (0):
>>>         :               618FAB1C4DFAC4EB29BAEE45FF51E586BD7
>>>         :               1FE40B4ED5FAEA3277F57942DF99999383F
>>>         :               05D139D5043E55B9E1DEFD649ACA6BEA1DB
>>>         :               E7B85A58BE9DD11E0961BA03A5FF1B6DA1F
>>>         :               D10075B662B5667FA7025B15BE62BAB34F8
>>>         :               87FF1140BFFD85ABA70F92E61CF2D5B18AC
>>>         :               46A2D0EC1B8176B20D2C004552502D062AB
>>>         :               0B36664AE5588DF9F4624B9C2CCD527702D
>>>         :               56AF04B8FB78D5A4042B03F2DA0987E12E9
>>>         :               69A74110BA5BB6A8AA62227C53C910D24D9
>>>         :               F92B633527ACCD112B3A6C5B5834A300ACD
>>>         :               AADBEFDEB8A863A78069A2F2E8057A963B1
>>>         :               E926AA87479908EF6387848A826CD318695
>>>         :               E1658EBD3D74FE641787BFA31285E061C17
>>>         :               AB101DD43AAD3D369F32334AF2BA8A09AA7
>>>         :               D4ED3C6BCE36FA395BD760C1E8314514339
>>>         :               6E9BC7735789B55BD02AE16EEDF3F51CC43
>>>         :               591CF793A8A314F946680F7EF1931310E44
>>>         :               784146F33A398DBF54D3716E0C567C662E3
>>>         :               F1A528B762709920F98111EE6553F5EFECA
>>>         :               8F316EB06337F05F1847AD64E3F40DA4A23
>>>         :               5414BFBD7860A7DA510CE7B21186CC82EFD
>>>         :               4D1880FADA9975F89237BEE6B08B698332B
>>>         :               9A4B8CF50154F6FFE444FF9CDAE0470EE38
>>>         :               6114512361174F29EFEC37BF1A656AD1965
>>>         :               C7F5F988B0F05D9367F7C249FEAF0A2AAC4
>>>         :               BA28CC23F6C2032954FCCD0330A840A3D8F
>>>         :               7D5461265D8B87EC7D15980C932AFFC14F9
>>>         :               FDEADBA8FA80A96EABF7354C2964CFFC2E2
>>>         :               E31AA04C7B58C3FF9F446D3F3FA5DA74D12
>>>         :               2208FD36237A72DF5475E300739526C55E0
>>>         :               AEFEDDC4B0C60741D74D0A1AC593F21CD8F
>>>         :               74840EC81E3F7A7A56D2AACA7A049BC9936
>>>         :               E175588E33978988F3D2FC753401524872E
>>>         :               39C905D99430FC93512B61DB5D12C3EDCFF
>>>         :               E33B92A5B9E6C021084683AE497B46B893F
>>>         :               EB5B71611744A336501822DEA063A67EC35
>>>         :               35F0CB6CAD133DA4375A765F264FF55F87D
>>>         :               F81F1D641655C6042EEF494C3C419EC5B52
>>>         :               4607B850829F28BD27457DD92B5B233125C
>>>         :               656B555E6E
>>> 871  453:        SEQUENCE:
>>> 875    9:         OBJECT IDENTIFIER:data [1.2.840.113549.1.7.1]
>>> 886  438:         CONTEXT SPECIFIC (0):
>>> 890  434:           OCTET STRING:
>>> 894  430:            SEQUENCE:
>>> 898  426:              SEQUENCE:
>>> 902   11:               OBJECT IDENTIFIER:pkcs-12-pkcs-8ShroudedKeyBag
>>>         :                [1.2.840.113549.1.12.10.1.2]
>>> 915  323:               CONTEXT SPECIFIC (0):
>>> 919  319:                 SEQUENCE:
>>> 923   85:                  SEQUENCE:
>>> 925    9:                    OBJECT IDENTIFIER:[1.2.840.113549.1.5.13]
>>> 936   72:                    SEQUENCE:
>>> 938   41:                     SEQUENCE:
>>> 940    9:                       OBJECT IDENTIFIER:
>>>         :                        [1.2.840.113549.1.5.12]
>>> 951   28:                       SEQUENCE:
>>> 953    8:                        OCTET STRING:
>>>         :                          FD04424D0ED6DC2F
>>> 963    2:                        INTEGER:2048
>>> 967   12:                        SEQUENCE:
>>> 969    8:                          OBJECT IDENTIFIER:
>>>         :                           [1.2.643.7.1.1.4.2]
>>> 979    0:                          NULL:
>>> 981   27:                     SEQUENCE:
>>> 983    9:                       OBJECT IDENTIFIER:
>>>         :                        [1.2.643.7.1.1.5.1.1]
>>> 994   14:                       SEQUENCE:
>>> 996   12:                        OCTET STRING:
>>>         :                          F0C52AA00000000000000000
>>> 1010  229:                  OCTET STRING:
>>>         :                    2A8FD988DD10DF2B984C77411E630B3B
>>>         :                    7E864AFF900DAF6C1484FE6A9C38C066
>>>         :                    09FBEA513127EC2EBE59D2F4F0A17D65
>>>         :                    6E82F765FFD5C9810BEFAFD0AEE293A1
>>>         :                    E08097A65721732D1D1A4FCCCC8B4745
>>>         :                    50B9C0ADA74F1C10E24293906F7184B1
>>>         :                    73A03D7A761B6A5F4FBF75083D1BCA44
>>>         :                    E44CC20486115CB9B502B733F64ECA56
>>>         :                    C4C9B8D32316BAFB110BAE4EBF340134
>>>         :                    903ADB2AE74CE9172AE9CE754F182ACE
>>>         :                    7488E9CA667135DBF0E3C6D9C6A4ED45
>>>         :                    50F1098013386AB3D29C070A55942C70
>>>         :                    FD2C86A32CC0761A104AC90C3ABA3225
>>>         :                    96D26CD13F9635D5FF013D852E2D4B15
>>>         :                    24B7F828FD
>>> 1242   84:               SET:
>>> 1244   35:                 SEQUENCE:
>>> 1246    9:                  OBJECT IDENTIFIER:localKeyID
>>>         :                   [1.2.840.113549.1.9.21]
>>> 1257   22:                  SET:
>>> 1259   20:                    OCTET STRING:
>>>         :                     795574F9D4B6E4C20224286998673FF00A14C04D
>>> 1281   45:                 SEQUENCE:
>>> 1283    9:                  OBJECT IDENTIFIER:
>>>         :                   friendlyName [1.2.840.113549.1.9.20]
>>> 1294   32:                  SET:
>>> 1296   30:                    BMP STRING:'p12FriendlyName'
>>> 1328   94:  SEQUENCE:
>>> 1330   78:   SEQUENCE:
>>> 1332   10:     SEQUENCE:
>>> 1334    8:      OBJECT IDENTIFIER:[1.2.643.7.1.1.2.3]
>>> 1344   64:     OCTET STRING:
>>>         :      E9E1EDB62665DD9EF474C40F7DC90BB3
>>>         :      42E27CA7105E3A9B0B9B675942AB7716
>>>         :      37B9CEA5B5BA4FFB54E71F579AF66CA9
>>>         :      BC9EC2CEB36ACF4FC8413A878066F388
>>> 1410    8:   OCTET STRING:'C62141F0E888C6D9'
>>> 1420    2:   INTEGER:2048
>>> ]]></sourcecode>
>>>                </section>
>>>
>>>
>>>
>>>
>>> -----Original Message-----
>>> From: Lynne Bartholomew <[e-mail]>
>>> Sent: Wednesday, March 13, 2024 7:27 PM
>>> To: Independent Submissions Editor (Eliot Lear) <[e-mail]>
>>> Cc: Karelina Ekaterina <[e-mail]>; [e-mail]; [e-mail]
>>> Subject: Re: *[ISE] Re: AUTH48: RFC-to-be 9548 <draft-pkcs12-gost-08> for your review
>>>
>>> Hi, Eliot.
>>>
>>> FYI that the "1) <!-- [rfced] Appendices A.2.2 and subsequent:  Please note that when
>>> creating the output files, we receive quite a few "Too long line"
>>> warnings. ..." item is still pending.  There are quite a few lines that are too long, as shown in the complete question further down in this email thread.
>>>
>>> Thank you.
>>>
>>> RFC Editor/lb
>>>
>>>> On Mar 13, 2024, at 9:09 AM, Independent Submissions Editor (Eliot Lear) <[e-mail]> wrote:
>>>>
>>>> Ok.  I think we are waiting on kate to address the MIB situation.
>>>>
>>>> Eliot
>>>>
>>>> On 13.03.2024 16:49, Lynne Bartholomew wrote:
>>>>> Hi, Kate and Eliot.
>>>>>
>>>>> Kate, we have further updated this document per your notes below.
>>>>>
>>>>> Regarding this item:
>>>>>
>>>>>> "RFX" is a typo.
>>>>>> The term "transport key container" is the same as "PFX". So replace it everywhere in the text:
>>>>>>
>>>>>> Delete the "transport key container" from keywords.
>>>>>>
>>>>>> Old (title):
>>>>>> Generating Transport Key Containers Using the GOST Algorithms
>>>>>> New (title):
>>>>>> Generating PFX Using the GOST Algorithms
>>>>> Per our typical process of defining terms that might not be well known to readers, we expanded "PFX" in the document title, Abstract, and Introduction.  Please let us know any objections.
>>>>>
>>>>> The latest files are posted here.  Please refresh your browser:
>>>>>
>>>>>   https://www.rfc-editor.org/authors/rfc9548.txt
>>>>>   https://www.rfc-editor.org/authors/rfc9548.pdf
>>>>>   https://www.rfc-editor.org/authors/rfc9548.html
>>>>>   https://www.rfc-editor.org/authors/rfc9548.xml
>>>>>   https://www.rfc-editor.org/authors/rfc9548-diff.html
>>>>>   https://www.rfc-editor.org/authors/rfc9548-rfcdiff.html
>>>>>   https://www.rfc-editor.org/authors/rfc9548-auth48diff.html
>>>>>   https://www.rfc-editor.org/authors/rfc9548-lastdiff.html
>>>>>   https://www.rfc-editor.org/authors/rfc9548-lastrfcdiff.html
>>>>>
>>>>>   https://www.rfc-editor.org/authors/rfc9548-xmldiff1.html
>>>>>   https://www.rfc-editor.org/authors/rfc9548-xmldiff2.html
>>>>>
>>>>> Thank you!
>>>>>
>>>>> RFC Editor/lb
>>>>>
>>>>>> On Mar 12, 2024, at 12:35 PM, Independent Submissions Editor (Eliot Lear) <[e-mail]> wrote:
>>>>>>
>>>>>>
>>>>>> On 12.03.2024 19:59, Lynne Bartholomew wrote:
>>>>>>> 2. Does your question below re. "gostR3410-2012-PKISyntax(2)" being an
>>>>>>> unregistered entry also apply to "pkcs-12ruSyntax(5)"? Both entries are
>>>>>>> unregistered.
>>>>>> Yes.
>>>>>> On Mar 12, 2024, at 12:51 PM, Karelina Ekaterina <[e-mail]> wrote:
>>>>>>
>>>>>> Hi,
>>>>>>
>>>>>>>> But it can't remain unregistered.  Are you in a position to request its registration?
>>>>>> I'll clarify this point.
>>>>>>
>>>>>>
>>>>>> 1) In section 3 (Basic terms and definition):
>>>>>>
>>>>>> Old:
>>>>>> <dt>|A|</dt>
>>>>>> <dd>the number of components (a length) of the vector A belonging to V<sup>*</sup> (if A is an empty string, then |A| = 0)</dd>
>>>>>>
>>>>>> New:
>>>>>> <dt>|A|</dt>
>>>>>> <dd>the number of components (a length) of the vector A belonging to V<sub>s</sub> (if A is an empty string, then |A| = 0)</dd>
>>>>>>
>>>>>> And please write the indexes correctly in "INT" definition:
>>>>>>
>>>>>>> <dt>INT(b)</dt>
>>>>>>> <dd>integer INT(b) = b<sub>1</sub> +b<sub>2</sub> * 256+⋯+b<sub>s</sub> * 256<sup>s-1</sup>, where b belongs to  V<sub>s</sub></dd>
>>>>>> 2) >>regarding this:
>>>>>>>> all three terms mean the same thing
>>>>>>>> I can remove all mentions "transport key container" in the text and replace it with "RFX" or add definition of "transport key container is PFX".
>>>>>>>> There is no such term "RFX" in the document.  I presume that's just a typo on your part.
>>>>>> "RFX" is a typo.
>>>>>> The term "transport key container" is the same as "PFX". So replace it everywhere in the text:
>>>>>>
>>>>>> Delete the "transport key container" from keywords.
>>>>>>
>>>>>> Old (title):
>>>>>> Generating Transport Key Containers Using the GOST Algorithms
>>>>>> New (title):
>>>>>> Generating PFX Using the GOST Algorithms
>>>>>>
>>>>>>
>>>>>> Old (abstract):
>>>>>> This document specifies how to use "PKCS #12: Personal Information Exchange Syntax v1.1" (RFC 7292) to generate transport key containers for storing keys and certificates in conjunction with the
>>>>>> Russian national standard GOST algorithms.
>>>>>> New (abstract):
>>>>>> This document specifies how to use "PKCS #12: Personal Information Exchange Syntax v1.1" (RFC 7292) to PFX  for storing keys and certificates in conjunction with the
>>>>>> Russian national standard GOST algorithms.
>>>>>>
>>>>>>
>>>>>> Old:
>>>>>> This memo describes the creation of transport key containers for keys and certificates using the GOST R 34.10-2012 algorithm.
>>>>>> The GOST R 34.11-2012 algorithm is used to ensure the integrity of transport key containers.
>>>>>> New:
>>>>>> This memo describes the creation of PFX for keys and certificates using the GOST R 34.10-2012 algorithm.
>>>>>> The GOST R 34.11-2012 algorithm is used to ensure the integrity of PFX.
>>>>>>
>>>>>>
>>>>>> Old:
>>>>>>           The transport key container (PFX; see <xref target="RFC7292"/>) is designed for secure storage and data transfer.
>>>>>>           The scope of this document is to define how the transport key container is used for private key and certificate protection with a password when GOST R 34.10-2012 is applied.
>>>>>> New:
>>>>>>           The PFX (see <xref target="RFC7292"/>) is designed for secure storage and data transfer.
>>>>>>           The scope of this document is to define how PFX is used for private key and certificate protection with a password when GOST R 34.10-2012 is applied.
>>>>>>
>>>>>>
>>>>>> Old:
>>>>>> In accordance with <xref target="RFC7292"/>, the transport key container has the following structure:
>>>>>> New:
>>>>>> In accordance with <xref target="RFC7292"/>, PFX has the following structure:
>>>>>>
>>>>>>
>>>>>> Old:
>>>>>> When processing a transport key container, this field should be checked first.
>>>>>> New:
>>>>>> When processing PFX, this field should be checked first.
>>>>>>
>>>>>>
>>>>>> Old:
>>>>>> For information on security considerations for generating transport key containers, see <xref target="RFC7292"/>.
>>>>>> New:
>>>>>> For information on security considerations for generating PFX, see <xref target="RFC7292"/>.
>>>>>>
>>>>>> Kate
>>>>>>
>>>>>> -----Original Message-----
>>>>>> From: Lynne Bartholomew <[e-mail]>
>>>>>> Sent: Tuesday, March 12, 2024 10:00 PM
>>>>>> To: Karelina Ekaterina <[e-mail]>
>>>>>> Cc: Independent Submissions Editor (Eliot Lear) <[e-mail]>; [e-mail]; [e-mail]
>>>>>> Subject: *[ISE] Re: AUTH48: RFC-to-be 9548 <draft-pkcs12-gost-08> for your review
>>>>>>
>>>>>> Hi, Kate and *Eliot.
>>>>>>
>>>>>> Kate, we have updated this document per your notes below.
>>>>>>
>>>>>> * Eliot,
>>>>>>
>>>>>> 1. Please review the latest updates to the list of notations in Section 3, as the newer changes are technical in nature.
>>>>>> ---------------
>>>>>> 2. Does your question below re. "gostR3410-2012-PKISyntax(2)" being an unregistered entry also apply to "pkcs-12ruSyntax(5)"? Both entries are unregistered.
>>>>>>
>>>>>>> Yes, "pkcs-12ruSyntax(5)" is an unregistered entry.
>>>>>> ---------------
>>>>>>
>>>>>> The latest files are here.  Please refresh your browser:
>>>>>>
>>>>>> https://www.rfc-editor.org/authors/rfc9548.txt
>>>>>> https://www.rfc-editor.org/authors/rfc9548.pdf
>>>>>> https://www.rfc-editor.org/authors/rfc9548.html
>>>>>> https://www.rfc-editor.org/authors/rfc9548.xml
>>>>>> https://www.rfc-editor.org/authors/rfc9548-diff.html
>>>>>> https://www.rfc-editor.org/authors/rfc9548-rfcdiff.html
>>>>>> https://www.rfc-editor.org/authors/rfc9548-auth48diff.html
>>>>>> https://www.rfc-editor.org/authors/rfc9548-lastdiff.html
>>>>>> https://www.rfc-editor.org/authors/rfc9548-lastrfcdiff.html
>>>>>>
>>>>>> https://www.rfc-editor.org/authors/rfc9548-xmldiff1.html
>>>>>> https://www.rfc-editor.org/authors/rfc9548-xmldiff2.html
>>>>>>
>>>>>> Please review the latest updates carefully -- particularly those in the list in Section 3 and in the "Let the key K be n bits in length; then, the sequence I is ..." paragraph -- and let us know if anything is incorrect.
>>>>>>
>>>>>> Thank you!
>>>>>>
>>>>>> RFC Editor/lb
>>>>>>
>>>>>>
>>>>>>> On Mar 11, 2024, at 12:25 PM, Independent Submissions Editor (Eliot Lear) <[e-mail]> wrote:
>>>>>>>
>>>>>>> Just on this point:
>>>>>>> On 11.03.2024 20:09, Karelina Ekaterina wrote:
>>>>>>>>>> Original:
>>>>>>>>>> FROM GostR3410–2012-PKISyntax
>>>>>>>>>> {
>>>>>>>>>> iso(1) member-body(2) ru(643) rosstandart(7) tc26(1)
>>>>>>>>>> modules(0) gostR3410–2012-PKISyntax(2) };
>>>>>>>>>>
>>>>>>>>>> We see the following on
>>>>>>>>>> <http://www.oid-info.com/cgi-bin/display?oid=1.2.643.7.1.0.2&a=display>:
>>>>>>>>>>
>>>>>>>>>> gostR3411-2012-PKISyntax(2)
>>>>>>>>>>
>>>>>>>>>> Is the "3410" entry an unregistered entry? We also see
>>>>>>>>>> gostR3410-2012-PKISyntax(2) at the beginning of Appendix A of RFC
>>>>>>>>>> 9215. -->
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>> Yes, "3410" is an unregistered entry.
>>>>>>>>
>>>>>>>>
>>>>>>> But it can't remain unregistered.  Are you in a position to request its registration?
>>>>>>> Eliot
>>>>>>
>>>>>>> On Mar 11, 2024, at 12:09 PM, Karelina Ekaterina <[e-mail]> wrote:
>>>>>>>
>>>>>>> Hi,
>>>>>>>
>>>>>>> Below are comments on some of the questions.
>>>>>>> I will write about the remaining questions later.
>>>>>>>
>>>>>>>>> 6) Change sentence, please:
>>>>>>>>> | A||C     | a concatenation of two strings A, C from V^(*), i.e., a |
>>>>>>>>> |          | vector from V_(|A|+|C|), where the left subvector  |
>>>>>>>>> |          | from V_(|A|) is equal to the vector A and the      |
>>>>>>>>> |          | right subvector from V_(|C|) is equal to the       |
>>>>>>>>> |          | vector C: A = (a_(n_1),...,a_1) in V_(n_1) and C = |
>>>>>>>>> |          | (c_(n_2),..., c_1) in V_(n_2), res =               |
>>>>>>>>> |          | (a_(n_1),...,a_1,c_(n_2),..., c_1) in V_(n_1+n_2)) | -->
>>>>>>>>> I think there is confusion, and perhaps it is on my part.  I don't think the confusion is over "octet strings" versus "strings" but rather a matter of punctuation?
>>>>>>>>> However, Kate, I think your change from octet strings to strings may be okay raises one question.  I would like you to go through the document and review each instance of either octet or string.  Unicode makes this a royal pain to be sure.
>>>>>>> Please, change the following sentences (xml-doc):
>>>>>>> OLD:
>>>>>>>          <dt>V<sup>*</sup></dt>
>>>>>>>          <dd>the set of all binary row vectors of finite length (hereinafter referred to as vectors), including an empty string</dd>
>>>>>>>          <dt>V<sub>s</sub></dt>
>>>>>>>          <dd>the set of all binary row vectors of length s, where s &gt;= 0; if s = 0, then the set V<sub>s</sub> consists of an empty string of length 0</dd>
>>>>>>>
>>>>>>> NEW (delete V<sup>*</sup>) :
>>>>>>>          <dt>V<sub>s</sub></dt>
>>>>>>>          <dd>the set of byte strings of length s, where s &gt;= 0; the string 𝑏 = (b<sub>1</sub>,…,b<sub>s</sub>) belongs to the set V<sub>s</sub> if b<sub>1</sub>,…,b<sub>s</sub>∈{0,…,255}</dd>
>>>>>>>
>>>>>>> OLD:
>>>>>>>          <dt>A||C</dt>
>>>>>>>          <dd>a concatenation of two strings A, C from V<sup>*</sup>, i.e.,
>>>>>>>          a vector from V<sub>|A|+|C|</sub>, where the left subvector from V<sub>|A|</sub>
>>>>>>>          is equal to the vector A and the right subvector from V<sub>|C|</sub> is
>>>>>>>          equal to the vector C: A = (a<sub>n<sub>1</sub></sub>,...,a<sub>1</sub>) in V<sub>n<sub>1</sub></sub> and C =
>>>>>>>          (c<sub>n<sub>2</sub></sub>,...,c<sub>1</sub>) in V<sub>n<sub>2</sub></sub>, res = (a<sub>n<sub>1</sub></sub>,...,a<sub>1</sub>,c<sub>n<sub>2</sub></sub>,...,c<sub>1</sub>) in V<sub>n<sub>1</sub>+n<sub>2</sub></sub>)</dd>
>>>>>>> NEW:
>>>>>>>          <dt>A||C</dt>
>>>>>>>          <dd>a concatenation of two byte strings A, C from V<sub>s</sub>, i.e.,
>>>>>>>          a string from V<sub>|A|+|C|</sub>, where the left substring from V<sub>|A|</sub>
>>>>>>>          is equal to the string A and the right substring from V<sub>|C|</sub> is
>>>>>>>          equal to the string C: A = (a<sub>n<sub>1</sub></sub>,...,a<sub>1</sub>) in V<sub>n<sub>1</sub></sub> and C =
>>>>>>>          (c<sub>n<sub>2</sub></sub>,...,c<sub>1</sub>) in V<sub>n<sub>2</sub></sub>, res = (a<sub>n<sub>1</sub></sub>,...,a<sub>1</sub>,c<sub>n<sub>2</sub></sub>,...,c<sub>1</sub>) in V<sub>n<sub>1</sub>+n<sub>2</sub></sub>)</dd>
>>>>>>>
>>>>>>> Please add in this section new definition:
>>>>>>>
>>>>>>> <dt>INT(b)</dt>
>>>>>>> <dd>integer INT(b) = b_1+b_2∙256+⋯+b_s∙ 256^(s-1), where b∈ V<sub>s</sub></dd>
>>>>>>>
>>>>>>> And please change the following sentence:
>>>>>>>
>>>>>>> OLD:
>>>>>>> The masking operation is the multiplication of the key by the inverse of the mask: K<sub>M</sub> = K * M<sup>-1</sup> mod Q, where the Q value is taken from the key parameters.
>>>>>>> The operation of removing the mask is the multiplication of the masked key by the mask: K = K<sub>M</sub> * M mod Q.
>>>>>>>
>>>>>>> NEW:
>>>>>>> For GOST R 34.10-2012 keys the masking operation is the multiplication of the key by the inverse of the mask: INT(K<sub>M</sub>) = INT(K) * INT(M)<sup>-1</sup> mod Q, where the Q value is taken from the key parameters.
>>>>>>> The operation of removing the mask is the multiplication of the masked key by the mask: INT(K) = INT(K<sub>M</sub>) * INT(M) mod Q.
>>>>>>>
>>>>>>>
>>>>>>> 16) <!-- [rfced] Section 7:
>>>>>>>>> <http://www.oid-info.com/cgi-bin/display?oid=1.2.643.7.1.1.2.3&a=display> shows "gost3411-12-512(3)".  Should "2012" be "12" per the OID
>>>>>>>>> repository, or is the repository incorrect?
>>>>>>>>>
>>>>>>>>> Original:
>>>>>>>>> id-tc26-gost3411-12-512 :: =
>>>>>>>>> {
>>>>>>>>>   iso(1) member-body(2) ru(643) rosstandart(7) tc26(1)
>>>>>>>>>   algorithms (1) digest(2) gost3411–2012-512(3)  } -->
>>>>>>> NEW:
>>>>>>> id-tc26-gost3411-12-512 :: =
>>>>>>> {
>>>>>>>    iso(1) member-body(2) ru(643) rosstandart(7) tc26(1)
>>>>>>>    algorithms (1) digest(2) gost3411–12-512(3)  }
>>>>>>>
>>>>>>>
>>>>>>> 17) <!-- [rfced] Section 10:
>>>>>>>>> a) We could not get output for "pkcs-12ruSyntax(5)" on the OID
>>>>>>>>> repository (http://www.oid-info.com/index.htm).
>>>>>>>>> 1.2.643.7.1.0.5 yields an error, as seen on
>>>>>>>>> <http://www.oid-info.com/cgi-bin/display?oid=1.2.643.7.1.0.5&a=display>.
>>>>>>>>>
>>>>>>>>> Original:
>>>>>>>>> PKCS-12RU
>>>>>>>>> {
>>>>>>>>>   iso(1) member-body(2) ru(643) rosstandart(7)
>>>>>>>>>   tc26(1) modules(0) pkcs-12ruSyntax(5)  }
>>>>>>>>>
>>>>>>>>> Backing out one level, we see the following on
>>>>>>>>> <http://www.oid-info.com/cgi-bin/display?oid=1.2.643.7.1.0&action=display>:
>>>>>>>>>
>>>>>>>>> modules(0)
>>>>>>>>> child OIDs:
>>>>>>>>> gostR3411-2012-PKISyntax(2)
>>>>>>>>> ruStrongCertsSyntax(6)
>>>>>>>>>
>>>>>>>>> Please let us know if any updates are needed.  Is "pkcs-12ruSyntax(5)"
>>>>>>>>> an unregistered entry?
>>>>>>> Yes, "pkcs-12ruSyntax(5)" is an unregistered entry.
>>>>>>>
>>>>>>>
>>>>>>>>> b) We did not find a match for "gostR3410-2012-PKISyntax(2)" on
>>>>>>>>> <http://www.oid-info.com/index.htm>.
>>>>>>>>>
>>>>>>>>> Original:
>>>>>>>>> FROM GostR3410–2012-PKISyntax
>>>>>>>>> {
>>>>>>>>>   iso(1) member-body(2) ru(643) rosstandart(7) tc26(1)
>>>>>>>>>   modules(0) gostR3410–2012-PKISyntax(2)  };
>>>>>>>>>
>>>>>>>>> We see the following on
>>>>>>>>> <http://www.oid-info.com/cgi-bin/display?oid=1.2.643.7.1.0.2&a=display>:
>>>>>>>>>
>>>>>>>>> gostR3411-2012-PKISyntax(2)
>>>>>>>>>
>>>>>>>>> Is the "3410" entry an unregistered entry?  We also see
>>>>>>>>> gostR3410-2012-PKISyntax(2) at the beginning of Appendix A of RFC
>>>>>>>>> 9215. -->
>>>>>>>>>
>>>>>>>>>
>>>>>>> Yes, "3410" is an unregistered entry.
>>>>>>>
>>>>>>>
>>>>>>> 9) >>It appears that we should not make any changes to sourcecode type.  Please either (1) confirm or (2) specify where changes are needed.
>>>>>>>
>>>>>>> 2
>>>>>>> Through the xml-text:
>>>>>>>
>>>>>>> OLD:
>>>>>>> <sourcecode type="asn.1"><![CDATA[
>>>>>>> MIICLjCCAdugAwIBAgIEAYy6hDAKBggqhQMHAQEDAjA4MQ0wCwYDVQQKEwRUSzI2
>>>>>>> MScwJQYDVQQDEx5DQSBUSzI2OiBHT1NUIDM0LjEwLTEyIDI1Ni1iaXQwHhcNMDEw
>>>>>>> MTAxMDAwMDAwWhcNNDkxMjMxMDAwMDAwWjA7MQ0wCwYDVQQKEwRUSzI2MSowKAYD
>>>>>>> VQQDEyFPUklHSU5BVE9SOiBHT1NUIDM0LjEwLTEyIDUxMi1iaXQwgaAwFwYIKoUD
>>>>>>> BwEBAQIwCwYJKoUDBwECAQIBA4GEAASBgLSLt1q8KQ4YZVxioU+1LV9QhE7MHR9g
>>>>>>> BEh7S1yVNGlqt7+rNG5VFqmrPM74rbUsOlhV8M+zZKprXdk35Oz8lSW/n2oIUHZx
>>>>>>> ikXIH/SSHj4rv3K/Puvz7hYTQSZl/xPdp78nUmjrEa6d5wfX8biEy2z0dgufFvAk
>>>>>>> Mw1Ua4gdXqDOo4GHMIGEMGMGA1UdIwRcMFqAFKxsDkxEZqJCluKfCTslZvPLpFMq
>>>>>>> oTykOjA4MQ0wCwYDVQQKEwRUSzI2MScwJQYDVQQDEx5DQSBUSzI2OiBHT1NUIDM0
>>>>>>> LjEwLTEyIDI1Ni1iaXSCBAGMuoEwHQYDVR0OBBYEFH4GVwmYDK1rCKhX7nkAWDrJ
>>>>>>> 16CkMAoGCCqFAwcBAQMCA0EACl6p8dAbpi9Hk+3mgMyI0WIh17IrlrSp/mB0F7Zz
>>>>>>> Mt8XUD1Dwz3JrrnxeXnfMvOA5BdUJ9hCyDgMVAGs/IcEEA==
>>>>>>> ]]></sourcecode>
>>>>>>>
>>>>>>> NEW:
>>>>>>> <sourcecode type=""><![CDATA[
>>>>>>> MIICLjCCAdugAwIBAgIEAYy6hDAKBggqhQMHAQEDAjA4MQ0wCwYDVQQKEwRUSzI2
>>>>>>> MScwJQYDVQQDEx5DQSBUSzI2OiBHT1NUIDM0LjEwLTEyIDI1Ni1iaXQwHhcNMDEw
>>>>>>> MTAxMDAwMDAwWhcNNDkxMjMxMDAwMDAwWjA7MQ0wCwYDVQQKEwRUSzI2MSowKAYD
>>>>>>> VQQDEyFPUklHSU5BVE9SOiBHT1NUIDM0LjEwLTEyIDUxMi1iaXQwgaAwFwYIKoUD
>>>>>>> BwEBAQIwCwYJKoUDBwECAQIBA4GEAASBgLSLt1q8KQ4YZVxioU+1LV9QhE7MHR9g
>>>>>>> BEh7S1yVNGlqt7+rNG5VFqmrPM74rbUsOlhV8M+zZKprXdk35Oz8lSW/n2oIUHZx
>>>>>>> ikXIH/SSHj4rv3K/Puvz7hYTQSZl/xPdp78nUmjrEa6d5wfX8biEy2z0dgufFvAk
>>>>>>> Mw1Ua4gdXqDOo4GHMIGEMGMGA1UdIwRcMFqAFKxsDkxEZqJCluKfCTslZvPLpFMq
>>>>>>> oTykOjA4MQ0wCwYDVQQKEwRUSzI2MScwJQYDVQQDEx5DQSBUSzI2OiBHT1NUIDM0
>>>>>>> LjEwLTEyIDI1Ni1iaXSCBAGMuoEwHQYDVR0OBBYEFH4GVwmYDK1rCKhX7nkAWDrJ
>>>>>>> 16CkMAoGCCqFAwcBAQMCA0EACl6p8dAbpi9Hk+3mgMyI0WIh17IrlrSp/mB0F7Zz
>>>>>>> Mt8XUD1Dwz3JrrnxeXnfMvOA5BdUJ9hCyDgMVAGs/IcEEA==
>>>>>>> ]]></sourcecode>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> OLD:
>>>>>>> <sourcecode type="asn.1"><![CDATA[
>>>>>>> F95A5D44C5245F63F2E7DF8E782C1924EADCB8D06C52D91023179786154CBDB1
>>>>>>> 561B4DF759D69F67EE1FBD5B68800E134BAA12818DA4F3AC75B0E5E6F9256911
>>>>>>> ]]></sourcecode>
>>>>>>>
>>>>>>> NEW:
>>>>>>> <sourcecode type=""><![CDATA[
>>>>>>> F95A5D44C5245F63F2E7DF8E782C1924EADCB8D06C52D91023179786154CBDB1
>>>>>>> 561B4DF759D69F67EE1FBD5B68800E134BAA12818DA4F3AC75B0E5E6F9256911
>>>>>>> ]]></sourcecode>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> OLD:
>>>>>>> <sourcecode type="asn.1"><![CDATA[
>>>>>>> D09FD0B0D180D0BED0BBD18C20D0B4D0BBD18F20504658
>>>>>>> ]]></sourcecode>
>>>>>>>
>>>>>>> NEW:
>>>>>>> <sourcecode type=""><![CDATA[
>>>>>>> D09FD0B0D180D0BED0BBD18C20D0B4D0BBD18F20504658
>>>>>>> ]]></sourcecode>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> OLD:
>>>>>>> <sourcecode type="asn.1"><![CDATA[
>>>>>>> MIIFKwIBAzCCBMQGCSqGSIb3DQEHAaCCBLUEggSxMIIErTCCAswGCSqGSIb3DQEH
>>>>>>> AaCCAr0EggK5MIICtTCCArEGCyqGSIb3DQEMCgEDoIICSjCCAkYGCiqGSIb3DQEJ
>>>>>>> FgGgggI2BIICMjCCAi4wggHboAMCAQICBAGMuoQwCgYIKoUDBwEBAwIwODENMAsG
>>>>>>> A1UEChMEVEsyNjEnMCUGA1UEAxMeQ0EgVEsyNjogR09TVCAzNC4xMC0xMiAyNTYt
>>>>>>> Yml0MB4XDTAxMDEwMTAwMDAwMFoXDTQ5MTIzMTAwMDAwMFowOzENMAsGA1UEChME
>>>>>>> VEsyNjEqMCgGA1UEAxMhT1JJR0lOQVRPUjogR09TVCAzNC4xMC0xMiA1MTItYml0
>>>>>>> MIGgMBcGCCqFAwcBAQECMAsGCSqFAwcBAgECAQOBhAAEgYC0i7davCkOGGVcYqFP
>>>>>>> tS1fUIROzB0fYARIe0tclTRpare/qzRuVRapqzzO+K21LDpYVfDPs2Sqa13ZN+Ts
>>>>>>> /JUlv59qCFB2cYpFyB/0kh4+K79yvz7r8+4WE0EmZf8T3ae/J1Jo6xGunecH1/G4
>>>>>>> hMts9HYLnxbwJDMNVGuIHV6gzqOBhzCBhDBjBgNVHSMEXDBagBSsbA5MRGaiQpbi
>>>>>>> nwk7JWbzy6RTKqE8pDowODENMAsGA1UEChMEVEsyNjEnMCUGA1UEAxMeQ0EgVEsy
>>>>>>> NjogR09TVCAzNC4xMC0xMiAyNTYtYml0ggQBjLqBMB0GA1UdDgQWBBR+BlcJmAyt
>>>>>>> awioV+55AFg6ydegpDAKBggqhQMHAQEDAgNBAApeqfHQG6YvR5Pt5oDMiNFiIdey
>>>>>>> K5a0qf5gdBe2czLfF1A9Q8M9ya658Xl53zLzgOQXVCfYQsg4DFQBrPyHBBAxVDAj
>>>>>>> BgkqhkiG9w0BCRUxFgQUeVV0+dS25MICJChpmGc/8AoUwE0wLQYJKoZIhvcNAQkU
>>>>>>> MSAeHgBwADEAMgBGAHIAaQBlAG4AZABsAHkATgBhAG0AZTCCAdkGCSqGSIb3DQEH
>>>>>>> AaCCAcoEggHGMIIBwjCCAb4GCyqGSIb3DQEMCgECoIIBVzCCAVMwWQYJKoZIhvcN
>>>>>>> AQUNMEwwKQYJKoZIhvcNAQUMMBwECKf4N7NMwugqAgIIADAMBggqhQMHAQEEAgUA
>>>>>>> MB8GCSqFAwcBAQUCAjASBBAlmt2WDfaPJlsAs0mLKglzBIH1DMvEacbbWRNDVSnX
>>>>>>> JLWygYrKoipdOjDA/2HEnBZ34uFOLNheUqiKpCPoFpbR2GBiVYVTVK9ibiczgaca
>>>>>>> EQYzDXtcS0QCZOxpKWfteAlbdJLC/SqPurPYyKi0MVRUPROhbisFASDT38HDH1Dh
>>>>>>> 0dL5f6ga4aPWLrWbbgWERFOoOPyh4DotlPF37AQOwiEjsbyyRHq3HgbWiaxQRuAh
>>>>>>> eqHOn4QVGY92/HFvJ7u3TcnQdLWhTe/lh1RHLNF3RnXtN9if9zC23laDZOiWZplU
>>>>>>> yLrUiTCbHrtn1RppPDmLFNMt9dJ7KKgCkOi7Zm5nhqPChbywX13wcfYxVDAjBgkq
>>>>>>> hkiG9w0BCRUxFgQUeVV0+dS25MICJChpmGc/8AoUwE0wLQYJKoZIhvcNAQkUMSAe
>>>>>>> HgBwADEAMgBGAHIAaQBlAG4AZABsAHkATgBhAG0AZTBeME4wCgYIKoUDBwEBAgME
>>>>>>> QAkBKw4ihn7pSIYTEhu0bcvTPZjI3WgVxCkUVlOsc80G69EKFEOTnObGJGSKJ51U
>>>>>>> KkOsXF0a7+VBZf3BcVVQh9UECIVEtO+VpuskAgIIAA==
>>>>>>> ]]></sourcecode>
>>>>>>>
>>>>>>> NEW:
>>>>>>> <sourcecode type=""><![CDATA[
>>>>>>> MIIFKwIBAzCCBMQGCSqGSIb3DQEHAaCCBLUEggSxMIIErTCCAswGCSqGSIb3DQEH
>>>>>>> AaCCAr0EggK5MIICtTCCArEGCyqGSIb3DQEMCgEDoIICSjCCAkYGCiqGSIb3DQEJ
>>>>>>> FgGgggI2BIICMjCCAi4wggHboAMCAQICBAGMuoQwCgYIKoUDBwEBAwIwODENMAsG
>>>>>>> A1UEChMEVEsyNjEnMCUGA1UEAxMeQ0EgVEsyNjogR09TVCAzNC4xMC0xMiAyNTYt
>>>>>>> Yml0MB4XDTAxMDEwMTAwMDAwMFoXDTQ5MTIzMTAwMDAwMFowOzENMAsGA1UEChME
>>>>>>> VEsyNjEqMCgGA1UEAxMhT1JJR0lOQVRPUjogR09TVCAzNC4xMC0xMiA1MTItYml0
>>>>>>> MIGgMBcGCCqFAwcBAQECMAsGCSqFAwcBAgECAQOBhAAEgYC0i7davCkOGGVcYqFP
>>>>>>> tS1fUIROzB0fYARIe0tclTRpare/qzRuVRapqzzO+K21LDpYVfDPs2Sqa13ZN+Ts
>>>>>>> /JUlv59qCFB2cYpFyB/0kh4+K79yvz7r8+4WE0EmZf8T3ae/J1Jo6xGunecH1/G4
>>>>>>> hMts9HYLnxbwJDMNVGuIHV6gzqOBhzCBhDBjBgNVHSMEXDBagBSsbA5MRGaiQpbi
>>>>>>> nwk7JWbzy6RTKqE8pDowODENMAsGA1UEChMEVEsyNjEnMCUGA1UEAxMeQ0EgVEsy
>>>>>>> NjogR09TVCAzNC4xMC0xMiAyNTYtYml0ggQBjLqBMB0GA1UdDgQWBBR+BlcJmAyt
>>>>>>> awioV+55AFg6ydegpDAKBggqhQMHAQEDAgNBAApeqfHQG6YvR5Pt5oDMiNFiIdey
>>>>>>> K5a0qf5gdBe2czLfF1A9Q8M9ya658Xl53zLzgOQXVCfYQsg4DFQBrPyHBBAxVDAj
>>>>>>> BgkqhkiG9w0BCRUxFgQUeVV0+dS25MICJChpmGc/8AoUwE0wLQYJKoZIhvcNAQkU
>>>>>>> MSAeHgBwADEAMgBGAHIAaQBlAG4AZABsAHkATgBhAG0AZTCCAdkGCSqGSIb3DQEH
>>>>>>> AaCCAcoEggHGMIIBwjCCAb4GCyqGSIb3DQEMCgECoIIBVzCCAVMwWQYJKoZIhvcN
>>>>>>> AQUNMEwwKQYJKoZIhvcNAQUMMBwECKf4N7NMwugqAgIIADAMBggqhQMHAQEEAgUA
>>>>>>> MB8GCSqFAwcBAQUCAjASBBAlmt2WDfaPJlsAs0mLKglzBIH1DMvEacbbWRNDVSnX
>>>>>>> JLWygYrKoipdOjDA/2HEnBZ34uFOLNheUqiKpCPoFpbR2GBiVYVTVK9ibiczgaca
>>>>>>> EQYzDXtcS0QCZOxpKWfteAlbdJLC/SqPurPYyKi0MVRUPROhbisFASDT38HDH1Dh
>>>>>>> 0dL5f6ga4aPWLrWbbgWERFOoOPyh4DotlPF37AQOwiEjsbyyRHq3HgbWiaxQRuAh
>>>>>>> eqHOn4QVGY92/HFvJ7u3TcnQdLWhTe/lh1RHLNF3RnXtN9if9zC23laDZOiWZplU
>>>>>>> yLrUiTCbHrtn1RppPDmLFNMt9dJ7KKgCkOi7Zm5nhqPChbywX13wcfYxVDAjBgkq
>>>>>>> hkiG9w0BCRUxFgQUeVV0+dS25MICJChpmGc/8AoUwE0wLQYJKoZIhvcNAQkUMSAe
>>>>>>> HgBwADEAMgBGAHIAaQBlAG4AZABsAHkATgBhAG0AZTBeME4wCgYIKoUDBwEBAgME
>>>>>>> QAkBKw4ihn7pSIYTEhu0bcvTPZjI3WgVxCkUVlOsc80G69EKFEOTnObGJGSKJ51U
>>>>>>> KkOsXF0a7+VBZf3BcVVQh9UECIVEtO+VpuskAgIIAA==
>>>>>>> ]]></sourcecode>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> OLD:
>>>>>>> <sourcecode type="asn.1"><![CDATA[
>>>>>>> MIHiAgEBMBcGCCqFAwcBAQECMAsGCSqFAwcBAgECAQRAEWkl+eblsHWs86SNgRKq
>>>>>>> SxMOgGhbvR/uZ5/WWfdNG1axvUwVhpcXIxDZUmzQuNzqJBkseI7f5/JjXyTFRF1a
>>>>>>> +YGBgQG0i7davCkOGGVcYqFPtS1fUIROzB0fYARIe0tclTRpare/qzRuVRapqzzO
>>>>>>> +K21LDpYVfDPs2Sqa13ZN+Ts/JUlv59qCFB2cYpFyB/0kh4+K79yvz7r8+4WE0Em
>>>>>>> Zf8T3ae/J1Jo6xGunecH1/G4hMts9HYLnxbwJDMNVGuIHV6gzg==
>>>>>>> ]]></sourcecode>
>>>>>>>
>>>>>>> NEW:
>>>>>>> <sourcecode type=""><![CDATA[
>>>>>>> MIHiAgEBMBcGCCqFAwcBAQECMAsGCSqFAwcBAgECAQRAEWkl+eblsHWs86SNgRKq
>>>>>>> SxMOgGhbvR/uZ5/WWfdNG1axvUwVhpcXIxDZUmzQuNzqJBkseI7f5/JjXyTFRF1a
>>>>>>> +YGBgQG0i7davCkOGGVcYqFPtS1fUIROzB0fYARIe0tclTRpare/qzRuVRapqzzO
>>>>>>> +K21LDpYVfDPs2Sqa13ZN+Ts/JUlv59qCFB2cYpFyB/0kh4+K79yvz7r8+4WE0Em
>>>>>>> Zf8T3ae/J1Jo6xGunecH1/G4hMts9HYLnxbwJDMNVGuIHV6gzg==
>>>>>>> ]]></sourcecode>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> OLD:
>>>>>>> <sourcecode type="asn.1"><![CDATA[
>>>>>>> 0xD09FD0B0D180D0BED0BBD18C20D0B4D0BBD18F20504658
>>>>>>> ]]></sourcecode>
>>>>>>>
>>>>>>> NEW:
>>>>>>> <sourcecode type=""><![CDATA[
>>>>>>> 0xD09FD0B0D180D0BED0BBD18C20D0B4D0BBD18F20504658
>>>>>>> ]]></sourcecode>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> OLD:
>>>>>>> <sourcecode type="asn.1"><![CDATA[
>>>>>>> MIIFjAIBAzCCBSUGCSqGSIb3DQEHAaCCBRYEggUSMIIFDjCCA0EGCSqGSIb3DQEH
>>>>>>> BqCCAzIwggMuAgEAMIIDJwYJKoZIhvcNAQcBMFUGCSqGSIb3DQEFDTBIMCkGCSqG
>>>>>>> SIb3DQEFDDAcBAgUuSVGsSwGjQICCAAwDAYIKoUDBwEBBAIFADAbBgkqhQMHAQEF
>>>>>>> AQIwDgQM9Hk3dagtS48+G/x+gIICwWGPqxxN+sTrKbruRf9R5Ya9cf5AtO1frqMn
>>>>>>> f1eULfmZmTg/BdE51QQ+Vbnh3v1kmspr6h2+e4Wli+ndEeCWG6A6X/G22h/RAHW2
>>>>>>> YrVmf6cCWxW+YrqzT4h/8RQL/9haunD5LmHPLVsYrEai0OwbgXayDSwARVJQLQYq
>>>>>>> sLNmZK5ViN+fRiS5wszVJ3AtVq8EuPt41aQEKwPy2gmH4S6WmnQRC6W7aoqmIifF
>>>>>>> PJENJNn5K2M1J6zNESs6bFtYNKMArNqtvv3rioY6eAaaLy6AV6ljsekmqodHmQjv
>>>>>>> Y4eEioJs0xhpXhZY69PXT+ZBeHv6MSheBhwXqxAd1DqtPTafMjNK8rqKCap9TtPG
>>>>>>> vONvo5W9dgwegxRRQzlum8dzV4m1W9Aq4W7t8/UcxDWRz3k6ijFPlGaA9+8ZMTEO
>>>>>>> RHhBRvM6OY2/VNNxbgxWfGYuPxpSi3YnCZIPmBEe5lU/Xv7KjzFusGM38F8YR61k
>>>>>>> 4/QNpKI1QUv714YKfaUQznshGGzILv1NGID62pl1+JI3vuawi2mDMrmkuM9QFU9v
>>>>>>> /kRP+c2uBHDuOGEUUSNhF08p7+w3vxplatGWXH9fmIsPBdk2f3wkn+rwoqrEuijM
>>>>>>> I/bCAylU/M0DMKhAo9j31UYSZdi4fsfRWYDJMq/8FPn96tuo+oCpbqv3NUwpZM/8
>>>>>>> Li4xqgTHtYw/+fRG0/P6XadNEiII/TYjenLfVHXjAHOVJsVeCu/t3EsMYHQddNCh
>>>>>>> rFk/Ic2PdIQOyB4/enpW0qrKegSbyZNuF1WI4zl4mI89L8dTQBUkhy45yQXZlDD8
>>>>>>> k1ErYdtdEsPtz/4zuSpbnmwCEIRoOuSXtGuJP+tbcWEXRKM2UBgi3qBjpn7DU18M
>>>>>>> tsrRM9pDdadl8mT/Vfh9+B8dZBZVxgQu70lMPEGexbUkYHuFCCnyi9J0V92StbIz
>>>>>>> Elxla1VebjCCAcUGCSqGSIb3DQEHAaCCAbYEggGyMIIBrjCCAaoGCyqGSIb3DQEM
>>>>>>> CgECoIIBQzCCAT8wVQYJKoZIhvcNAQUNMEgwKQYJKoZIhvcNAQUMMBwECP0EQk0O
>>>>>>> 1twvAgIIADAMBggqhQMHAQEEAgUAMBsGCSqFAwcBAQUBATAOBAzwxSqgAAAAAAAA
>>>>>>> AAAEgeUqj9mI3RDfK5hMd0EeYws7foZK/5ANr2wUhP5qnDjAZgn76lExJ+wuvlnS
>>>>>>> 9PChfWVugvdl/9XJgQvvr9Cu4pOh4ICXplchcy0dGk/MzItHRVC5wK2nTxwQ4kKT
>>>>>>> kG9xhLFzoD16dhtqX0+/dQg9G8pE5EzCBIYRXLm1Arcz9k7KVsTJuNMjFrr7EQuu
>>>>>>> Tr80ATSQOtsq50zpFyrpznVPGCrOdIjpymZxNdvw48bZxqTtRVDxCYATOGqz0pwH
>>>>>>> ClWULHD9LIajLMB2GhBKyQw6ujIlltJs0T+WNdX/AT2FLi1LFSS3+Cj9MVQwIwYJ
>>>>>>> KoZIhvcNAQkVMRYEFHlVdPnUtuTCAiQoaZhnP/AKFMBNMC0GCSqGSIb3DQEJFDEg
>>>>>>> Hh4AcAAxADIARgByAGkAZQBuAGQAbAB5AE4AYQBtAGUwXjBOMAoGCCqFAwcBAQID
>>>>>>> BEDp4e22JmXdnvR0xA99yQuzQuJ8pxBeOpsLm2dZQqt3Fje5zqW1uk/7VOcfV5r2
>>>>>>> bKm8nsLOs2rPT8hBOoeAZvOIBAjGIUHw6IjG2QICCAA=
>>>>>>> ]]></sourcecode>
>>>>>>>
>>>>>>> NEW:
>>>>>>> <sourcecode type=""><![CDATA[
>>>>>>> MIIFjAIBAzCCBSUGCSqGSIb3DQEHAaCCBRYEggUSMIIFDjCCA0EGCSqGSIb3DQEH
>>>>>>> BqCCAzIwggMuAgEAMIIDJwYJKoZIhvcNAQcBMFUGCSqGSIb3DQEFDTBIMCkGCSqG
>>>>>>> SIb3DQEFDDAcBAgUuSVGsSwGjQICCAAwDAYIKoUDBwEBBAIFADAbBgkqhQMHAQEF
>>>>>>> AQIwDgQM9Hk3dagtS48+G/x+gIICwWGPqxxN+sTrKbruRf9R5Ya9cf5AtO1frqMn
>>>>>>> f1eULfmZmTg/BdE51QQ+Vbnh3v1kmspr6h2+e4Wli+ndEeCWG6A6X/G22h/RAHW2
>>>>>>> YrVmf6cCWxW+YrqzT4h/8RQL/9haunD5LmHPLVsYrEai0OwbgXayDSwARVJQLQYq
>>>>>>> sLNmZK5ViN+fRiS5wszVJ3AtVq8EuPt41aQEKwPy2gmH4S6WmnQRC6W7aoqmIifF
>>>>>>> PJENJNn5K2M1J6zNESs6bFtYNKMArNqtvv3rioY6eAaaLy6AV6ljsekmqodHmQjv
>>>>>>> Y4eEioJs0xhpXhZY69PXT+ZBeHv6MSheBhwXqxAd1DqtPTafMjNK8rqKCap9TtPG
>>>>>>> vONvo5W9dgwegxRRQzlum8dzV4m1W9Aq4W7t8/UcxDWRz3k6ijFPlGaA9+8ZMTEO
>>>>>>> RHhBRvM6OY2/VNNxbgxWfGYuPxpSi3YnCZIPmBEe5lU/Xv7KjzFusGM38F8YR61k
>>>>>>> 4/QNpKI1QUv714YKfaUQznshGGzILv1NGID62pl1+JI3vuawi2mDMrmkuM9QFU9v
>>>>>>> /kRP+c2uBHDuOGEUUSNhF08p7+w3vxplatGWXH9fmIsPBdk2f3wkn+rwoqrEuijM
>>>>>>> I/bCAylU/M0DMKhAo9j31UYSZdi4fsfRWYDJMq/8FPn96tuo+oCpbqv3NUwpZM/8
>>>>>>> Li4xqgTHtYw/+fRG0/P6XadNEiII/TYjenLfVHXjAHOVJsVeCu/t3EsMYHQddNCh
>>>>>>> rFk/Ic2PdIQOyB4/enpW0qrKegSbyZNuF1WI4zl4mI89L8dTQBUkhy45yQXZlDD8
>>>>>>> k1ErYdtdEsPtz/4zuSpbnmwCEIRoOuSXtGuJP+tbcWEXRKM2UBgi3qBjpn7DU18M
>>>>>>> tsrRM9pDdadl8mT/Vfh9+B8dZBZVxgQu70lMPEGexbUkYHuFCCnyi9J0V92StbIz
>>>>>>> Elxla1VebjCCAcUGCSqGSIb3DQEHAaCCAbYEggGyMIIBrjCCAaoGCyqGSIb3DQEM
>>>>>>> CgECoIIBQzCCAT8wVQYJKoZIhvcNAQUNMEgwKQYJKoZIhvcNAQUMMBwECP0EQk0O
>>>>>>> 1twvAgIIADAMBggqhQMHAQEEAgUAMBsGCSqFAwcBAQUBATAOBAzwxSqgAAAAAAAA
>>>>>>> AAAEgeUqj9mI3RDfK5hMd0EeYws7foZK/5ANr2wUhP5qnDjAZgn76lExJ+wuvlnS
>>>>>>> 9PChfWVugvdl/9XJgQvvr9Cu4pOh4ICXplchcy0dGk/MzItHRVC5wK2nTxwQ4kKT
>>>>>>> kG9xhLFzoD16dhtqX0+/dQg9G8pE5EzCBIYRXLm1Arcz9k7KVsTJuNMjFrr7EQuu
>>>>>>> Tr80ATSQOtsq50zpFyrpznVPGCrOdIjpymZxNdvw48bZxqTtRVDxCYATOGqz0pwH
>>>>>>> ClWULHD9LIajLMB2GhBKyQw6ujIlltJs0T+WNdX/AT2FLi1LFSS3+Cj9MVQwIwYJ
>>>>>>> KoZIhvcNAQkVMRYEFHlVdPnUtuTCAiQoaZhnP/AKFMBNMC0GCSqGSIb3DQEJFDEg
>>>>>>> Hh4AcAAxADIARgByAGkAZQBuAGQAbAB5AE4AYQBtAGUwXjBOMAoGCCqFAwcBAQID
>>>>>>> BEDp4e22JmXdnvR0xA99yQuzQuJ8pxBeOpsLm2dZQqt3Fje5zqW1uk/7VOcfV5r2
>>>>>>> bKm8nsLOs2rPT8hBOoeAZvOIBAjGIUHw6IjG2QICCAA=
>>>>>>> ]]></sourcecode>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> OLD:
>>>>>>> <sourcecode type="test-vectors"><![CDATA[
>>>>>>> MIHiAgEBMBcGCCqFAwcBAQECMAsGCSqFAwcBAgECAQRAEWkl+eblsHWs86SNgRKq
>>>>>>> SxMOgGhbvR/uZ5/WWfdNG1axvUwVhpcXIxDZUmzQuNzqJBkseI7f5/JjXyTFRF1a
>>>>>>> +YGBgQG0i7davCkOGGVcYqFPtS1fUIROzB0fYARIe0tclTRpare/qzRuVRapqzzO
>>>>>>> +K21LDpYVfDPs2Sqa13ZN+Ts/JUlv59qCFB2cYpFyB/0kh4+K79yvz7r8+4WE0Em
>>>>>>> Zf8T3ae/J1Jo6xGunecH1/G4hMts9HYLnxbwJDMNVGuIHV6gzg==
>>>>>>> ]]></sourcecode>
>>>>>>>
>>>>>>> NEW:
>>>>>>> <sourcecode type=""><![CDATA[
>>>>>>> MIHiAgEBMBcGCCqFAwcBAQECMAsGCSqFAwcBAgECAQRAEWkl+eblsHWs86SNgRKq
>>>>>>> SxMOgGhbvR/uZ5/WWfdNG1axvUwVhpcXIxDZUmzQuNzqJBkseI7f5/JjXyTFRF1a
>>>>>>> +YGBgQG0i7davCkOGGVcYqFPtS1fUIROzB0fYARIe0tclTRpare/qzRuVRapqzzO
>>>>>>> +K21LDpYVfDPs2Sqa13ZN+Ts/JUlv59qCFB2cYpFyB/0kh4+K79yvz7r8+4WE0Em
>>>>>>> Zf8T3ae/J1Jo6xGunecH1/G4hMts9HYLnxbwJDMNVGuIHV6gzg==
>>>>>>> ]]></sourcecode>
>>>>>>>
>>>>>>> -----Original Message-----
>>>>>>> From: Lynne Bartholomew <[e-mail]>
>>>>>>> Sent: Wednesday, March 6, 2024 9:16 PM
>>>>>>> To: Karelina Ekaterina <[e-mail]>; Independent Submissions Editor (Eliot Lear) <[e-mail]>
>>>>>>> Cc: [e-mail]; [e-mail]
>>>>>>> Subject: *[ISE] Re: AUTH48: RFC-to-be 9548 <draft-pkcs12-gost-08> for your review
>>>>>>>
>>>>>>> Hi, Kate and Eliot*.
>>>>>>>
>>>>>>> Kate, no worries, and thank you for the email.
>>>>>>>
>>>>>>> * Eliot, as today's update to the "A||C a concatenation of ..." line is technical in nature, please review, and let us know if you approve.
>>>>>>>
>>>>>>> Kate, we have updated this document per your notes below.  We have some follow-up items for you:
>>>>>>>
>>>>>>> Regarding our question 8) and your reply:
>>>>>>>
>>>>>>>>> 8) <!-- [rfced] Section 4:  This sentence as written seems to
>>>>>>>>> indicate that "PFX" means "transport key container".  However, we see
>>>>>>>>> that RFC 7292 says that "PFX" is sometimes expanded as "Personal
>>>>>>>>> Information Exchange".  Are some words missing from this sentence, or
>>>>>>>>> do "PFX", "transport key container", and "Personal Information
>>>>>>>>> Exchange" all mean the same thing?
>>>>>>>>>
>>>>>>>>> Original:
>>>>>>>>> The transport key container (PFX, see [RFC7292]) is designed for
>>>>>>>>> secure storage and data transfer.
>>>>>>>>>
>>>>>>>>> Possibly (if all three terms mean the same thing):
>>>>>>>>> The transport key container (PFX, which is sometimes expanded as
>>>>>>>>> "Personal Information Exchange"; see [RFC7292]) is designed for
>>>>>>>>> secure storage and data transfer. -->
>>>>>>>> 8) all three terms mean the same thing I can remove all mentions
>>>>>>>> "transport key container" in the text and replace it with "RFX" or add definition of "transport key container is PFX".
>>>>>>> We are not sure how/if any updates are needed here.  Please specify the updates, if any, using "OLD" and "NEW" text.
>>>>>>>
>>>>>>> = = = = =
>>>>>>>
>>>>>>> Regarding our question 9) and your reply:
>>>>>>>
>>>>>>>>> 9) <!-- [rfced] Please review the "type" attribute of each sourcecode
>>>>>>>>> element in the XML file to ensure correctness.
>>>>>>>>>
>>>>>>>>> For example, in Appendix A, should some of the sourcecode entries
>>>>>>>>> with type = "asn.1" be type = "test-vectors" instead (possibly the
>>>>>>>>> data that follows "This section contains a test certificate ..." and
>>>>>>>>> "Decrypted key value in BASE64 format")?
>>>>>>>>>
>>>>>>>>> Please see
>>>>>>>>> <https://www.rfc-editor.org/materials/sourcecode-types.txt>.  If the
>>>>>>>>> current list of preferred values for "type" on that page does not
>>>>>>>>> contain an applicable type, please let us know.
>>>>>>>>>
>>>>>>>>> Also, it is acceptable to leave the "type" attribute not set. -->
>>>>>>>> 9) don't set the type of data from A.1, A.2.1, A.2.3, A.3.1, A.3.3
>>>>>>>> sections
>>>>>>> It appears that we should not make any changes to sourcecode type.  Please either (1) confirm or (2) specify where changes are needed.
>>>>>>>
>>>>>>> = = = = =
>>>>>>>
>>>>>>> Regarding our question 10) and your reply:
>>>>>>>
>>>>>>>>> 10) <!-- [rfced] Section 4.2, Section 4.3, and Appendix A:  We do not
>>>>>>>>> see "Data structure" or "EncryptedData structure" in RFC 5652.  Will
>>>>>>>>> these sentences be clear to readers?
>>>>>>>>>
>>>>>>>>> Original:
>>>>>>>>> When password integrity mode is used the data is represented as an
>>>>>>>>> EncryptedData structure ([RFC5652]).
>>>>>>>>> ...
>>>>>>>>> If the certificate is not encrypted, the CertBag structure is placed
>>>>>>>>> in the Data structure (see [RFC5652]).  If the certificate is
>>>>>>>>> encrypted, the CertBag structure is placed in the EncryptedData
>>>>>>>>> structure (see [RFC5652]).
>>>>>>>>> ...
>>>>>>>>> In this example the PKCS8SHroudedKeybag structure is used to store
>>>>>>>>> the key, which is placed in the Data structure.  The certBag
>>>>>>>>> structure is used to store the certificate, which is placed in the
>>>>>>>>> Data structure.
>>>>>>>>> ...
>>>>>>>>> In this example the PKCS8SHroudedKeybag structure is used to store
>>>>>>>>> the key, which is placed in the Data structure (see [RFC5652]).  The
>>>>>>>>> certBag structure is used to store the certificate, which is placed
>>>>>>>>> in the EncryptedData structure (see [RFC5652]). -->
>>>>>>>> 10) "EncryptedData structure" - section 8 in RFC 5652 Data structure -
>>>>>>>> section 4 in RFC 5652
>>>>>>> Although we do not see these capitalized forms in RFC 5652 (for example, we see "signed-data, enveloped-data, digested-data, encrypted-data, or authenticated-data content type" at the end of Section 4 of RFC 5652 and "encrypted-data content type" in Section 8 of RFC 5652), it appears that readers will understand the text.  Thank you for the pointers to the section numbers.
>>>>>>>
>>>>>>> = = = = =
>>>>>>>
>>>>>>> Regarding our question 11) (the bad line break in Section 4.2.2) and your reply ("please insert an appropriate line break"):
>>>>>>>
>>>>>>> Please review the line break we added (please see the .txt, .html, and .pdf outputs), and let us know if it should be placed somewhere else.
>>>>>>>
>>>>>>> = = = = =
>>>>>>>
>>>>>>> The latest files are posted here.  Please refresh your browser:
>>>>>>>
>>>>>>> https://www.rfc-editor.org/authors/rfc9548.txt
>>>>>>> https://www.rfc-editor.org/authors/rfc9548.pdf
>>>>>>> https://www.rfc-editor.org/authors/rfc9548.html
>>>>>>> https://www.rfc-editor.org/authors/rfc9548.xml
>>>>>>> https://www.rfc-editor.org/authors/rfc9548-diff.html
>>>>>>> https://www.rfc-editor.org/authors/rfc9548-rfcdiff.html
>>>>>>> https://www.rfc-editor.org/authors/rfc9548-auth48diff.html
>>>>>>>
>>>>>>> https://www.rfc-editor.org/authors/rfc9548-xmldiff1.html
>>>>>>> https://www.rfc-editor.org/authors/rfc9548-xmldiff2.html
>>>>>>>
>>>>>>> Thanks again!
>>>>>>>
>>>>>>> RFC Editor/lb
>>>>>>>
>>>>>>>
>>>>>>>> On Mar 5, 2024, at 2:16 PM, Karelina Ekaterina <Ekaterina.Karelina=[e-mail]> wrote:
>>>>>>>>
>>>>>>>> Hi,
>>>>>>>> I'm sorry for the long wait
>>>>>>>>
>>>>>>>> 1) no objections
>>>>>>>> 2) ok
>>>>>>>> 3) Change sentence, please: This memo describes the creation of transport key containers for keys  and certificates using GOST R 34.10–2012 algorithm.
>>>>>>>> 4) no objections
>>>>>>>> 5) (1) "all binary row vectors of finite length (hereinafter referred to as vectors), including an empty string"
>>>>>>>> 6) Change sentence, please:
>>>>>>>> | A||C     | a concatenation of two strings A, C from V^(*), i.e., a |
>>>>>>>> |          | vector from V_(|A|+|C|), where the left subvector  |
>>>>>>>> |          | from V_(|A|) is equal to the vector A and the      |
>>>>>>>> |          | right subvector from V_(|C|) is equal to the       |
>>>>>>>> |          | vector C: A = (a_(n_1),...,a_1) in V_(n_1) and C = |
>>>>>>>> |          | (c_(n_2),..., c_1) in V_(n_2), res =               |
>>>>>>>> |          | (a_(n_1),...,a_1,c_(n_2),..., c_1) in V_(n_1+n_2)) | -->
>>>>>>>>
>>>>>>>> 7) It is the correct reference
>>>>>>>> 8) all three terms mean the same thing I can remove all mentions
>>>>>>>> "transport key container" in the text and replace it with "RFX" or add definition of "transport key container is PFX".
>>>>>>>>
>>>>>>>> 9) don't set the type of data from A.1, A.2.1, A.2.3, A.3.1, A.3.3
>>>>>>>> sections
>>>>>>>>
>>>>>>>> 10) "EncryptedData structure" - section 8 in RFC 5652 Data structure -
>>>>>>>> section 4 in RFC 5652
>>>>>>>>
>>>>>>>> 11) ok, please insert an appropriate line break
>>>>>>>>
>>>>>>>> 12) ok, it's correct
>>>>>>>>
>>>>>>>> 13) don't remove, dots indicate closing parentheses
>>>>>>>>
>>>>>>>> 14) please set " ::= "
>>>>>>>>
>>>>>>>> 15) ok
>>>>>>>>
>>>>>>>> 16)-17) I’ll clarify, I’ll answer a little later
>>>>>>>>
>>>>>>>> 18) ok
>>>>>>>>
>>>>>>>> 19) ok
>>>>>>>>
>>>>>>>> 20) please, remove this reference
>>>>>>>>
>>>>>>>> 21) Should be "test key bytes"
>>>>>>>>
>>>>>>>> 22) ok
>>>>>>>>
>>>>>>>> 23)  I’ll clarify, I’ll answer a little later
>>>>>>>>
>>>>>>>> 24) please, change the sentence in Acknowledgments:
>>>>>>>>
>>>>>>>> The author thanks Alexander Potashnikov, Semen Pianov, and Valery Smyslov
>>>>>>>> for their careful readings and useful comments.
>>>>>>>>
>>>>>>>> * We have "E. Karelina, Ed." in our database records for RFC 9337 and
>>>>>>>> this document.  Is this correct? - it's correct
>>>>>>>>
>>>>>>>> 25) ok
>>>>>>>>
>>>>>>>> 26) a) don’t change
>>>>>>>> b) >>Should spacing be made consistent for the following?
>>>>>>>> Yes, please
>>>>>>>>
>>>>>>>>
>>>>>>>> Best regards,
>>>>>>>> Kate
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> -----Original Message-----
>>>>>>>> From: Independent Submissions Editor (Eliot Lear)
>>>>>>>> <[e-mail]>
>>>>>>>> Sent: Monday, March 4, 2024 1:36 PM
>>>>>>>> To: [e-mail]; Karelina Ekaterina
>>>>>>>> <[e-mail]>
>>>>>>>> Cc: [e-mail]
>>>>>>>> Subject: Re: AUTH48: RFC-to-be 9548 <draft-pkcs12-gost-08> for your
>>>>>>>> review
>>>>>>>>
>>>>>>>> Hi Kate,
>>>>>>>>
>>>>>>>> Please answer the RFC Editor's questions.  If you have questions, please ask.
>>>>>>>>
>>>>>>>> Eliot
>>>>>>>>
>>>>>>>> On 28.02.2024 21:44, [e-mail] wrote:
>>>>>>>>> Ekaterina,
>>>>>>>>>
>>>>>>>>> While reviewing this document during AUTH48, please resolve (as necessary) the following questions, which are also in the XML file.
>>>>>>>>>
>>>>>>>>> 1) <!-- [rfced] We updated the front-page title and the running title
>>>>>>>>> (PDF file) as follows.  Please let us know any objections.
>>>>>>>>>
>>>>>>>>> Original:
>>>>>>>>> Generating the Transport Key Containers Using the GOST Algorithms
>>>>>>>>>
>>>>>>>>> GOST usage in password-based pkcs12
>>>>>>>>>
>>>>>>>>> Currently:
>>>>>>>>> Generating Transport Key Containers Using the GOST Algorithms
>>>>>>>>>
>>>>>>>>> GOST Usage in Password-Based PKCS #12 -->
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> 2) <!-- [rfced] Sections 1 and subsequent:  When viewing the "diff"
>>>>>>>>> files, please note that in addition to our other updates, per our
>>>>>>>>> current process, we changed non-ASCII hyphens in such entries as
>>>>>>>>> "34.10-2012", "q > 3 – prime", and "GostR3410–2012-256-PublicKey".
>>>>>>>>> Please review, and let us know any concerns. -->
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> 3) <!-- [rfced] Section 1:  To what does "which" refer in this
>>>>>>>>> sentence - the containers or the verification keys?  If neither
>>>>>>>>> suggestion below is correct, please clarify the text.
>>>>>>>>>
>>>>>>>>> Original:
>>>>>>>>> This memo describes the creating of transport key containers for
>>>>>>>>> keys  and certificates of electronic signature verification keys
>>>>>>>>> which are  created in accordance with GOST R 34.10–2012 algorithm.
>>>>>>>>>
>>>>>>>>> Suggestion #1 (the containers):
>>>>>>>>> This memo describes the creation of transport key containers for
>>>>>>>>> keys  and certificates of electronic signature verification keys.
>>>>>>>>> These  transport key containers are created in accordance with the
>>>>>>>>> GOST  R 34.10-2012 algorithm.
>>>>>>>>>
>>>>>>>>> Suggestion #2 (the verification keys):
>>>>>>>>> This memo describes the creation of transport key containers for
>>>>>>>>> keys  and certificates of electronic signature verification keys.
>>>>>>>>> The  signature verification keys are created in accordance with the
>>>>>>>>> GOST R 34.10-2012 algorithm. -->
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> 4) <!-- [rfced] Section 3:  Please note that because Tables 1 and 2
>>>>>>>>> are lists of definitions, we converted them to definition lists.  The
>>>>>>>>> superscripting and subscripting are preserved in the HTML and PDF
>>>>>>>>> output files.  Please review, and let us know any objections. -->
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> 5) <!-- [rfced] Section 3:  Does "all binary row vectors of finite
>>>>>>>>> length (hereinafter referred to as vectors) including empty string"
>>>>>>>>> mean (1) "all binary row vectors of finite length (hereinafter
>>>>>>>>> referred to as vectors), including an empty string" (or "including
>>>>>>>>> empty strings"), (2) "all binary row vectors of finite length
>>>>>>>>> (hereinafter referred to as vectors) that include an empty string"
>>>>>>>>> (or "that include empty strings"), or (3) something else?
>>>>>>>>> Please clarify.
>>>>>>>>>
>>>>>>>>> Original:
>>>>>>>>> | V^(*)    | the set of all binary row vectors of finite length |
>>>>>>>>> |          | (hereinafter referred to as vectors) including     |
>>>>>>>>> |          | empty string                                       | -->
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> 6) <!-- [rfced] Section 3:  Please confirm that "two octet strings A, C"
>>>>>>>>> will be clear to readers.  We also see this text in RFC 9337, but
>>>>>>>>> this document provides an opportunity to clarify the text, if needed.
>>>>>>>>> (For example, does it mean "two octet strings, A and C"?)
>>>>>>>>>
>>>>>>>>> Original:
>>>>>>>>> | A||C     | a concatenation of two octet strings A, C, i.e., a |
>>>>>>>>> |          | vector from V_(|A|+|C|), where the left subvector  |
>>>>>>>>> |          | from V_(|A|) is equal to the vector A and the      |
>>>>>>>>> |          | right subvector from V_(|C|) is equal to the       |
>>>>>>>>> |          | vector C: A = (a_(n_1),...,a_1) in V_(n_1) and C = |
>>>>>>>>> |          | (c_(n_2),..., c_1) in V_(n_2), res =               |
>>>>>>>>> |          | (a_(n_1),...,a_1,c_(n_2),..., c_1) in V_(n_1+n_2)) | -->
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> 7) <!--[rfced] Section 3: In RFC 2104, we do not see specific mention
>>>>>>>>> of "512-bit output". Please confirm if this is the correct reference
>>>>>>>>> or if an update is needed.
>>>>>>>>>
>>>>>>>>> Original:
>>>>>>>>> HMAC_GOSTR3411  Hashed-Based Message Authentication Code.  A function
>>>>>>>>>    for calculating a Message Authentication Code (MAC) based on the
>>>>>>>>>    GOST R 34.11-2012 hash function (see [RFC6986]) with 512-bit
>>>>>>>>>    output in accordance with [RFC2104].
>>>>>>>>> -->
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> 8) <!-- [rfced] Section 4:  This sentence as written seems to
>>>>>>>>> indicate that "PFX" means "transport key container".  However, we see
>>>>>>>>> that RFC
>>>>>>>>> 7292 says that "PFX" is sometimes expanded as "Personal Information
>>>>>>>>> Exchange".  Are some words missing from this sentence, or do "PFX",
>>>>>>>>> "transport key container", and "Personal Information Exchange" all
>>>>>>>>> mean the same thing?
>>>>>>>>>
>>>>>>>>> Original:
>>>>>>>>> The transport key container (PFX, see [RFC7292]) is designed for
>>>>>>>>> secure storage and data transfer.
>>>>>>>>>
>>>>>>>>> Possibly (if all three terms mean the same thing):
>>>>>>>>> The transport key container (PFX, which is sometimes expanded as
>>>>>>>>> "Personal Information Exchange"; see [RFC7292]) is designed for
>>>>>>>>> secure storage and data transfer. -->
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> 9) <!-- [rfced] Please review the "type" attribute of each sourcecode
>>>>>>>>> element in the XML file to ensure correctness.
>>>>>>>>>
>>>>>>>>> For example, in Appendix A, should some of the sourcecode entries
>>>>>>>>> with type = "asn.1" be type = "test-vectors" instead (possibly the
>>>>>>>>> data that follows "This section contains a test certificate ..." and
>>>>>>>>> "Decrypted key value in BASE64 format")?
>>>>>>>>>
>>>>>>>>> Please see
>>>>>>>>> <https://www.rfc-editor.org/materials/sourcecode-types.txt>.  If the
>>>>>>>>> current list of preferred values for "type" on that page does not
>>>>>>>>> contain an applicable type, please let us know.
>>>>>>>>>
>>>>>>>>> Also, it is acceptable to leave the "type" attribute not set. -->
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> 10) <!-- [rfced] Section 4.2, Section 4.3, and Appendix A:  We do not
>>>>>>>>> see "Data structure" or "EncryptedData structure" in RFC 5652.  Will
>>>>>>>>> these sentences be clear to readers?
>>>>>>>>>
>>>>>>>>> Original:
>>>>>>>>> When password integrity mode is used the data is represented as an
>>>>>>>>> EncryptedData structure ([RFC5652]).
>>>>>>>>> ...
>>>>>>>>> If the certificate is not encrypted, the CertBag structure is placed
>>>>>>>>> in the Data structure (see [RFC5652]).  If the certificate is
>>>>>>>>> encrypted, the CertBag structure is placed in the EncryptedData
>>>>>>>>> structure (see [RFC5652]).
>>>>>>>>> ...
>>>>>>>>> In this example the PKCS8SHroudedKeybag structure is used to store
>>>>>>>>> the key, which is placed in the Data structure.  The certBag
>>>>>>>>> structure is used to store the certificate, which is placed in the
>>>>>>>>> Data structure.
>>>>>>>>> ...
>>>>>>>>> In this example the PKCS8SHroudedKeybag structure is used to store
>>>>>>>>> the key, which is placed in the Data structure (see [RFC5652]).  The
>>>>>>>>> certBag structure is used to store the certificate, which is placed
>>>>>>>>> in the EncryptedData structure (see [RFC5652]). -->
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> 11) <!-- [rfced] Section 4.2.2:  This field name is too long to fit
>>>>>>>>> on one line.  Would you like to insert an appropriate line break and
>>>>>>>>> add a note for the reader that the line break is used for readability?
>>>>>>>>>
>>>>>>>>> Please note that the line break is bad in the HTML output file but is
>>>>>>>>> OK in the text and PDF output files.
>>>>>>>>>
>>>>>>>>> Original:
>>>>>>>>> The following identifier MUST be specified  in
>>>>>>>>> EncryptedData.EncryptedContentInfo.contentEncryptionAlgorithm.encr
>>>>>>>>> yptionAlgorithmOID field:
>>>>>>>>>
>>>>>>>>> Currently:
>>>>>>>>> The following identifier MUST be
>>>>>>>>> specified in the
>>>>>>>>> EncryptedData.EncryptedContentInfo.contentEncryption
>>>>>>>>> Algorithm.encryptionAlgorithmOID field: -->
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> 12) <!-- [rfced] Section 4.3:  As it appears that "it" refers to the
>>>>>>>>> key and not to the bagValue field, we updated this sentence accordingly.
>>>>>>>>> If this is incorrect, please provide clarifying text.
>>>>>>>>>
>>>>>>>>> Original:
>>>>>>>>> The bagValue field contains the key and information about it in the
>>>>>>>>> encrypted form in the EncryptedPrivateKeyInfo structure.
>>>>>>>>>
>>>>>>>>> Currently:
>>>>>>>>> The bagValue field contains the key and information about the key,
>>>>>>>>> in  encrypted form, in the EncryptedPrivateKeyInfo structure. -->
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> 13) <!-- [rfced] Section 5.1:  Are the periods at the end of these
>>>>>>>>> standalone equations part of the equations, or should they be removed?
>>>>>>>>>
>>>>>>>>> Original:
>>>>>>>>> K_M = M_k (...(M_2(M_1(K)...).
>>>>>>>>>
>>>>>>>>> K = M_1^-1(...(M_(k-1)^-1(M_k^-1(K_M))...).
>>>>>>>>>
>>>>>>>>> I = K_M||M_1||M_2||...||M_k. -->
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> 14) <!-- [rfced] Section 5.2:  Should the two " := " entries be " ::=
>>>>>>>>> "?
>>>>>>>>>
>>>>>>>>> Original:
>>>>>>>>> KeyBag := PrivateKeyInfo
>>>>>>>>> ...
>>>>>>>>> PrivateKeyInfo := OneAsymmetricKey -->
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> 15) <!-- [rfced] Section 7:  We changed "using different random
>>>>>>>>> initializing value S" to "using a different random initializing value
>>>>>>>>> S".  If this is incorrect, please clarify the text (for example, was
>>>>>>>>> "different random initializing values for S"
>>>>>>>>> intended?).
>>>>>>>>>
>>>>>>>>> Original:
>>>>>>>>> The same password P is used to encrypt different sections of the PFX
>>>>>>>>> using different random initializing value S with a length of 8 to 32
>>>>>>>>> bytes, where S and P are the input parameters of the PBKDF2 function.
>>>>>>>>>
>>>>>>>>> Currently:
>>>>>>>>> The same password P is used to encrypt different sections of the PFX
>>>>>>>>> using a different random initializing value S with a length of 8 to
>>>>>>>>> 32 bytes, where S and P are the input parameters of the PBKDF2
>>>>>>>>> function. -->
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> 16) <!-- [rfced] Section 7:
>>>>>>>>> <http://www.oid-info.com/cgi-bin/display?oid=1.2.643.7.1.1.2.3&a=disp
>>>>>>>>> l
>>>>>>>>> ay> shows "gost3411-12-512(3)".  Should "2012" be "12" per the OID
>>>>>>>>> repository, or is the repository incorrect?
>>>>>>>>>
>>>>>>>>> Original:
>>>>>>>>> id-tc26-gost3411-12-512 :: =
>>>>>>>>> {
>>>>>>>>>   iso(1) member-body(2) ru(643) rosstandart(7) tc26(1)
>>>>>>>>>   algorithms (1) digest(2) gost3411–2012-512(3)  } -->
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> 17) <!-- [rfced] Section 10:
>>>>>>>>>
>>>>>>>>> a) We could not get output for "pkcs-12ruSyntax(5)" on the OID
>>>>>>>>> repository (http://www.oid-info.com/index.htm).
>>>>>>>>> 1.2.643.7.1.0.5 yields an error, as seen on
>>>>>>>>> <http://www.oid-info.com/cgi-bin/display?oid=1.2.643.7.1.0.5&a=display>.
>>>>>>>>>
>>>>>>>>> Original:
>>>>>>>>> PKCS-12RU
>>>>>>>>> {
>>>>>>>>>   iso(1) member-body(2) ru(643) rosstandart(7)
>>>>>>>>>   tc26(1) modules(0) pkcs-12ruSyntax(5)  }
>>>>>>>>>
>>>>>>>>> Backing out one level, we see the following on
>>>>>>>>> <http://www.oid-info.com/cgi-bin/display?oid=1.2.643.7.1.0&action=display>:
>>>>>>>>>
>>>>>>>>> modules(0)
>>>>>>>>> child OIDs:
>>>>>>>>> gostR3411-2012-PKISyntax(2)
>>>>>>>>> ruStrongCertsSyntax(6)
>>>>>>>>>
>>>>>>>>> Please let us know if any updates are needed.  Is "pkcs-12ruSyntax(5)"
>>>>>>>>> an unregistered entry?
>>>>>>>>>
>>>>>>>>> b) We did not find a match for "gostR3410-2012-PKISyntax(2)" on
>>>>>>>>> <http://www.oid-info.com/index.htm>.
>>>>>>>>>
>>>>>>>>> Original:
>>>>>>>>> FROM GostR3410–2012-PKISyntax
>>>>>>>>> {
>>>>>>>>>   iso(1) member-body(2) ru(643) rosstandart(7) tc26(1)
>>>>>>>>>   modules(0) gostR3410–2012-PKISyntax(2)  };
>>>>>>>>>
>>>>>>>>> We see the following on
>>>>>>>>> <http://www.oid-info.com/cgi-bin/display?oid=1.2.643.7.1.0.2&a=display>:
>>>>>>>>>
>>>>>>>>> gostR3411-2012-PKISyntax(2)
>>>>>>>>>
>>>>>>>>> Is the "3410" entry an unregistered entry?  We also see
>>>>>>>>> gostR3410-2012-PKISyntax(2) at the beginning of Appendix A of RFC
>>>>>>>>> 9215. -->
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> 18) <!-- [rfced] [X.680]:  ISO/IEC 8824-1:2002 has been withdrawn, as
>>>>>>>>> have the 2008 and 2015 versions.  We have updated this listing as
>>>>>>>>> follows.  Please let us know any concerns.
>>>>>>>>>
>>>>>>>>> Original:
>>>>>>>>> [X.680]    ITU-T, "Information Technology - Abstract Syntax Notation
>>>>>>>>>          One: Specification of Basic Notation.", ITU-T,
>>>>>>>>>          Recommendation X.680, ISO/IEC 8824-1:2002, 2002.
>>>>>>>>>
>>>>>>>>> Currently:
>>>>>>>>> [X.680]    ITU-T, "Information Technology - Abstract Syntax Notation
>>>>>>>>>          One (ASN.1): Specification of basic notation", ITU-T
>>>>>>>>>          Recommendation X.680, ISO/IEC 8824-1:2021, February 2021,
>>>>>>>>>          <https://www.itu.int/rec/T-REC-X.680>. -->
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> 19) <!-- [rfced] [X.690]:  ISO/IEC 8825-1:2008 has been withdrawn, as
>>>>>>>>> has the 2015 version.  We have updated this listing as follows.
>>>>>>>>> Please let us know any concerns.
>>>>>>>>>
>>>>>>>>> Original:
>>>>>>>>> [X.690]    ITU-T, "Information technology - ASN.1 encoding rules:
>>>>>>>>>          Specification of Basic Encoding Rules (BER), Canonical
>>>>>>>>>          Encoding Rules (CER) and Distinguished Encoding Rules
>>>>>>>>>          (DER).", ITU-T, Recommendation X.690, ISO/IEC
>>>>>>>>>          International Standard 8825-1:2008, November 2008.
>>>>>>>>>
>>>>>>>>> Currently:
>>>>>>>>> [X.690]    ITU-T, "Information technology - ASN.1 encoding rules:
>>>>>>>>>          Specification of Basic Encoding Rules (BER), Canonical
>>>>>>>>>          Encoding Rules (CER) and Distinguished Encoding Rules
>>>>>>>>>          (DER)", ITU-T Recommendation X.690, ISO/IEC International
>>>>>>>>>          Standard 8825-1:2021, February 2021,
>>>>>>>>>          <https://www.itu.int/rec/T-REC-X.690>. -->
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> 20) <!-- [rfced] Informative References:  [GostPkcs12] does not have
>>>>>>>>> a corresponding citation in this document.  Please let us know where
>>>>>>>>> it should be cited; otherwise, the reference listing will be removed.
>>>>>>>>>
>>>>>>>>> Original:
>>>>>>>>> [GostPkcs12]
>>>>>>>>>          Potashnikov, A., Karelina, E., Pianov, S., and A.
>>>>>>>>>          Naumenko, "Information technology. Cryptographic Data
>>>>>>>>>          Security. The transport key containers.", R
>>>>>>>>>          1323565.1.041-2022. Federal Agency on Technical Regulating
>>>>>>>>>          and Metrology (In Russian). -->
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> 21) <!-- [rfced] Appendix A.1.2:  Should "a test key bytes" be "test
>>>>>>>>> key bytes" or something else?  Are some words missing from this sentence?
>>>>>>>>>
>>>>>>>>> Original:
>>>>>>>>> This section contains a test key bytes in hexadecimal. -->
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> 22) <!-- [rfced] Appendices A.2 and A.3:  As it appears that "A
>>>>>>>>> following password" means "The following password", we updated these
>>>>>>>>> sentences accordingly.  If these updates are incorrect, please
>>>>>>>>> provide clarifying text.
>>>>>>>>>
>>>>>>>>> Original:
>>>>>>>>> A following password is used to encrypt the key and  control the
>>>>>>>>> integrity:
>>>>>>>>> ...
>>>>>>>>> A following password
>>>>>>>>> is used to encrypt the key and control the integrity.
>>>>>>>>>
>>>>>>>>> Currently:
>>>>>>>>> The following password is used to encrypt the key  and provide
>>>>>>>>> integrity control:
>>>>>>>>> ...
>>>>>>>>> The following
>>>>>>>>> password is used to encrypt the key and provide integrity control.
>>>>>>>>> -->
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> 23) <!-- [rfced] Appendices A.2.2 and subsequent:  Please note that
>>>>>>>>> when creating the output files, we receive quite a few "Too long line"
>>>>>>>>> warnings.  Entries that are 1, 2, or 3 characters too long can be
>>>>>>>>> left as is, but anything that is 4 or more characters too long -
>>>>>>>>> approx. 22 entries, by our count - will need to have line breaks inserted.
>>>>>>>>> Please review the list of warnings below, and let us know where
>>>>>>>>> proper line breaks can be placed (e.g., perhaps between strings and
>>>>>>>>> corresponding bracketed numbers or after colons (":"), as has already
>>>>>>>>> been done on some lines, such as lines containing "OBJECT IDENTIFIER:"
>>>>>>>>> and "OCTET STRING:"; also, the octet strings
>>>>>>>>> following Lines "1010  229" and "1344   64" in Appendix A.3.2
>>>>>>>>> create lines that are too long).
>>>>>>>>>
>>>>>>>>> draft-pkcs12-gost-08.xml(735): Warning: Too long line found (L796), 3 characters longer than 72 characters:
>>>>>>>>>          :                            authorityKeyIdentifier [2.5.29.35]
>>>>>>>>> draft-pkcs12-gost-08.xml(735): Warning: Too long line found (L810), 2 characters longer than 72 characters:
>>>>>>>>> 505    4:                                      PRINTABLE STRING:'TK26'
>>>>>>>>> draft-pkcs12-gost-08.xml(735): Warning: Too long line found (L814), 1 characters longer than 72 characters:
>>>>>>>>>          :                                        commonName [2.5.4.3]
>>>>>>>>> draft-pkcs12-gost-08.xml(735): Warning: Too long line found (L822), 2 characters longer than 72 characters:
>>>>>>>>>          :                             subjectKeyIdentifier [2.5.29.14]
>>>>>>>>> draft-pkcs12-gost-08.xml(735): Warning: Too long line found (L828), 1 characters longer than 72 characters:
>>>>>>>>> 591    8:                       OBJECT IDENTIFIER:[1.2.643.7.1.1.3.2]
>>>>>>>>> draft-pkcs12-gost-08.xml(735): Warning: Too long line found (L853), 1 characters longer than 72 characters:
>>>>>>>>> 785   11:              OBJECT IDENTIFIER:pkcs-12-pkcs-8ShroudedKeyBag
>>>>>>>>> draft-pkcs12-gost-08.xml(735): Warning: Too long line found (L858), 1 characters longer than 72 characters:
>>>>>>>>> 808    9:                   OBJECT IDENTIFIER:[1.2.840.113549.1.5.13]
>>>>>>>>> draft-pkcs12-gost-08.xml(735): Warning: Too long line found (L871), 2 characters longer than 72 characters:
>>>>>>>>> 866    9:                      OBJECT IDENTIFIER:[1.2.643.7.1.1.5.2.2]
>>>>>>>>> draft-pkcs12-gost-08.xml(735): Warning: Too long line found (L898), 1 characters longer than 72 characters:
>>>>>>>>>          :                    795574F9D4B6E4C20224286998673FF00A14C04D
>>>>>>>>> draft-pkcs12-gost-08.xml(1024): Warning: Too long line found (L1006), 4 characters longer than 72 characters:
>>>>>>>>>   38    9:         OBJECT IDENTIFIER:encryptedData [1.2.840.113549.1.7.6]
>>>>>>>>> draft-pkcs12-gost-08.xml(1024): Warning: Too long line found (L1076), 31 characters longer than 72 characters:
>>>>>>>>> 902   11:               OBJECT IDENTIFIER:pkcs-12-pkcs-8ShroudedKeyBag [1.2.840.113549.1.12.10.1.2]
>>>>>>>>> draft-pkcs12-gost-08.xml(1024): Warning: Too long line found (L1080), 2 characters longer than 72 characters:
>>>>>>>>> 925    9:                    OBJECT IDENTIFIER:[1.2.840.113549.1.5.13]
>>>>>>>>> draft-pkcs12-gost-08.xml(1024): Warning: Too long line found (L1083), 5 characters longer than 72 characters:
>>>>>>>>> 940    9:                       OBJECT IDENTIFIER:[1.2.840.113549.1.5.12]
>>>>>>>>> draft-pkcs12-gost-08.xml(1024): Warning: Too long line found (L1089), 4 characters longer than 72 characters:
>>>>>>>>> 969    8:                          OBJECT IDENTIFIER:[1.2.643.7.1.1.4.2]
>>>>>>>>> draft-pkcs12-gost-08.xml(1024): Warning: Too long line found (L1092), 3 characters longer than 72 characters:
>>>>>>>>> 983    9:                       OBJECT IDENTIFIER:[1.2.643.7.1.1.5.1.1]
>>>>>>>>> draft-pkcs12-gost-08.xml(1024): Warning: Too long line found (L1097), 22 characters longer than 72 characters:
>>>>>>>>>          :                    2A8FD988DD10DF2B984C77411E630B3B7E864AFF900DAF6C1484FE6A9C38C
>>>>>>>>> draft-pkcs12-gost-08.xml(1024): Warning: Too long line found (L1098), 22 characters longer than 72 characters:
>>>>>>>>>          :                    06609FBEA513127EC2EBE59D2F4F0A17D656E82F765FFD5C9810BEFAFD0AE
>>>>>>>>> draft-pkcs12-gost-08.xml(1024): Warning: Too long line found (L1099), 22 characters longer than 72 characters:
>>>>>>>>>          :                    E293A1E08097A65721732D1D1A4FCCCC8B474550B9C0ADA74F1C10E242939
>>>>>>>>> draft-pkcs12-gost-08.xml(1024): Warning: Too long line found (L1100), 22 characters longer than 72 characters:
>>>>>>>>>          :                    06F7184B173A03D7A761B6A5F4FBF75083D1BCA44E44CC20486115CB9B502
>>>>>>>>> draft-pkcs12-gost-08.xml(1024): Warning: Too long line found (L1101), 22 characters longer than 72 characters:
>>>>>>>>>          :                    B733F64ECA56C4C9B8D32316BAFB110BAE4EBF340134903ADB2AE74CE9172
>>>>>>>>> draft-pkcs12-gost-08.xml(1024): Warning: Too long line found (L1102), 22 characters longer than 72 characters:
>>>>>>>>>          :                    AE9CE754F182ACE7488E9CA667135DBF0E3C6D9C6A4ED4550F1098013386A
>>>>>>>>> draft-pkcs12-gost-08.xml(1024): Warning: Too long line found (L1103), 22 characters longer than 72 characters:
>>>>>>>>>          :                    B3D29C070A55942C70FD2C86A32CC0761A104AC90C3ABA322596D26CD13F9
>>>>>>>>> draft-pkcs12-gost-08.xml(1024): Warning: Too long line found (L1107), 11 characters longer than 72 characters:
>>>>>>>>> 1246    9:                  OBJECT IDENTIFIER:localKeyID [1.2.840.113549.1.9.21]
>>>>>>>>> draft-pkcs12-gost-08.xml(1024): Warning: Too long line found (L1110), 2 characters longer than 72 characters:
>>>>>>>>>          :                     795574F9D4B6E4C20224286998673FF00A14C04D
>>>>>>>>> draft-pkcs12-gost-08.xml(1024): Warning: Too long line found (L1112), 13 characters longer than 72 characters:
>>>>>>>>> 1283    9:                  OBJECT IDENTIFIER:friendlyName [1.2.840.113549.1.9.20]
>>>>>>>>> draft-pkcs12-gost-08.xml(1024): Warning: Too long line found (L1120), 35 characters longer than 72 characters:
>>>>>>>>>          :      E9E1EDB62665DD9EF474C40F7DC90BB342E27CA7105E3A9B0B9B675942AB771637B9CEA5B5BA4FFB54E71F57 -->
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> 24) <!-- [rfced] Acknowledgments and Author's Address section:
>>>>>>>>> Please advise regarding the following:
>>>>>>>>>
>>>>>>>>> * Are the names listed in the Acknowledgments section shown as last
>>>>>>>>> name followed by first name?
>>>>>>>>> * For example, we ask these questions because we see "Semen Pianov"
>>>>>>>>> in RFC 9215 but "Pianov Semen" in RFC 9337 and this document.
>>>>>>>>> Will one way of writing the names be preferred in this document and
>>>>>>>>> subsequent RFCs, or are both ways OK?
>>>>>>>>> * We have "E. Karelina, Ed." in our database records for RFC 9337 and
>>>>>>>>> this document.  Is this correct? -->
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> 25) <!-- [rfced] Please review the "Inclusive Language" portion of
>>>>>>>>> the online Style Guide at
>>>>>>>>> <https://www.rfc-editor.org/styleguide/part2/#inclusive_language>,
>>>>>>>>> and let us know if any changes are needed.
>>>>>>>>>
>>>>>>>>> Note that our script did not flag any words in particular, but this
>>>>>>>>> should still be reviewed as a best practice. -->
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> 26) <!-- [rfced] Please let us know if any changes are needed for the
>>>>>>>>> following:
>>>>>>>>>
>>>>>>>>> a) The following terms appear to be used inconsistently in this
>>>>>>>>> document.  Please let us know which form is preferred.
>>>>>>>>>
>>>>>>>>> certBag / CertBag ("A certBag contains", "a CertBag is defined",
>>>>>>>>> "the CertBag structure", "The certBag structure")
>>>>>>>>>
>>>>>>>>> octet string / OCTET STRING ("an octet string", "an OCTET STRING")
>>>>>>>>>
>>>>>>>>> PKCS8ShroudedKeyBag (3 instances) /
>>>>>>>>> PKCS8SHroudedKeybag (2 instances in Appendix A)
>>>>>>>>> (We see "8ShroudedKeyBag" on
>>>>>>>>> <http://www.oid-info.com/cgi-bin/
>>>>>>>>> display?oid=1.2.840.113549.1.12.10.1.2&a=display> and in
>>>>>>>>> RFC 7292.)
>>>>>>>>>
>>>>>>>>> b) Should spacing be made consistent for the following?
>>>>>>>>>
>>>>>>>>> We see spaces before the colons in the "SEQUENCE", "INTEGER", "OBJECT
>>>>>>>>> IDENTIFIER", "OCTET STRING", and "CONTEXT SPECIFIC"
>>>>>>>>> entries in Appendices A.2.4 and A.3.4 but not in the other appendices.
>>>>>>>>> Is the different spacing as intended (i.e., OK in the case of
>>>>>>>>> "Decrypted Key Value in ASN.1 Format" entries)?
>>>>>>>>>
>>>>>>>>> ,...,a_1 vs. ,..., c_1 -->
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Thank you.
>>>>>>>>>
>>>>>>>>> RFC Editor/lb/kc
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Feb 28, 2024, at 12:41 PM, [e-mail] wrote:
>>>>>>>>>
>>>>>>>>> *****IMPORTANT*****
>>>>>>>>>
>>>>>>>>> Updated 2024/02/28
>>>>>>>>>
>>>>>>>>> RFC Author(s):
>>>>>>>>> --------------
>>>>>>>>>
>>>>>>>>> Instructions for Completing AUTH48
>>>>>>>>>
>>>>>>>>> Your document has now entered AUTH48.  Once it has been reviewed and
>>>>>>>>> approved by you and all coauthors, it will be published as an RFC.
>>>>>>>>> If an author is no longer available, there are several remedies
>>>>>>>>> available as listed in the FAQ (https://www.rfc-editor.org/faq/).
>>>>>>>>>
>>>>>>>>> You and you coauthors are responsible for engaging other parties
>>>>>>>>> (e.g., Contributors or Working Group) as necessary before providing
>>>>>>>>> your approval.
>>>>>>>>>
>>>>>>>>> Planning your review
>>>>>>>>> ---------------------
>>>>>>>>>
>>>>>>>>> Please review the following aspects of your document:
>>>>>>>>>
>>>>>>>>> *  RFC Editor questions
>>>>>>>>>
>>>>>>>>> Please review and resolve any questions raised by the RFC Editor
>>>>>>>>> that have been included in the XML file as comments marked as
>>>>>>>>> follows:
>>>>>>>>>
>>>>>>>>> <!-- [rfced] ... -->
>>>>>>>>>
>>>>>>>>> These questions will also be sent in a subsequent email.
>>>>>>>>>
>>>>>>>>> *  Changes submitted by coauthors
>>>>>>>>>
>>>>>>>>> Please ensure that you review any changes submitted by your
>>>>>>>>> coauthors.  We assume that if you do not speak up that you
>>>>>>>>> agree to changes submitted by your coauthors.
>>>>>>>>>
>>>>>>>>> *  Content
>>>>>>>>>
>>>>>>>>> Please review the full content of the document, as this cannot
>>>>>>>>> change once the RFC is published.  Please pay particular attention to:
>>>>>>>>> - IANA considerations updates (if applicable)
>>>>>>>>> - contact information
>>>>>>>>> - references
>>>>>>>>>
>>>>>>>>> *  Copyright notices and legends
>>>>>>>>>
>>>>>>>>> Please review the copyright notice and legends as defined in
>>>>>>>>> RFC 5378 and the Trust Legal Provisions
>>>>>>>>> (TLP – https://trustee.ietf.org/license-info/).
>>>>>>>>>
>>>>>>>>> *  Semantic markup
>>>>>>>>>
>>>>>>>>> Please review the markup in the XML file to ensure that elements of
>>>>>>>>> content are correctly tagged.  For example, ensure that <sourcecode>
>>>>>>>>> and <artwork> are set correctly.  See details at
>>>>>>>>> <https://authors.ietf.org/rfcxml-vocabulary>.
>>>>>>>>>
>>>>>>>>> *  Formatted output
>>>>>>>>>
>>>>>>>>> Please review the PDF, HTML, and TXT files to ensure that the
>>>>>>>>> formatted output, as generated from the markup in the XML file, is
>>>>>>>>> reasonable.  Please note that the TXT will have formatting
>>>>>>>>> limitations compared to the PDF and HTML.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Submitting changes
>>>>>>>>> ------------------
>>>>>>>>>
>>>>>>>>> To submit changes, please reply to this email using ‘REPLY ALL’ as
>>>>>>>>> all the parties CCed on this message need to see your changes. The
>>>>>>>>> parties
>>>>>>>>> include:
>>>>>>>>>
>>>>>>>>> *  your coauthors
>>>>>>>>>
>>>>>>>>> *  [e-mail] (the RPC team)
>>>>>>>>>
>>>>>>>>> *  other document participants, depending on the stream (e.g.,
>>>>>>>>>   IETF Stream participants are your working group chairs, the
>>>>>>>>>   responsible ADs, and the document shepherd).
>>>>>>>>>
>>>>>>>>> *  [e-mail], which is a new archival mailing list
>>>>>>>>>   to preserve AUTH48 conversations; it is not an active discussion
>>>>>>>>>   list:
>>>>>>>>>
>>>>>>>>> *  More info:
>>>>>>>>>
>>>>>>>>> https://mailarchive.ietf.org/arch/msg/ietf-announce/yb6lpIGh-4Q9l2USx
>>>>>>>>> I
>>>>>>>>> Ae6P8O4Zc
>>>>>>>>>
>>>>>>>>> *  The archive itself:
>>>>>>>>>     https://mailarchive.ietf.org/arch/browse/auth48archive/
>>>>>>>>>
>>>>>>>>> *  Note: If only absolutely necessary, you may temporarily opt out
>>>>>>>>>     of the archiving of messages (e.g., to discuss a sensitive matter).
>>>>>>>>>     If needed, please add a note at the top of the message that you
>>>>>>>>>     have dropped the address. When the discussion is concluded,
>>>>>>>>>     [e-mail] will be re-added to the CC list and
>>>>>>>>>     its addition will be noted at the top of the message.
>>>>>>>>>
>>>>>>>>> You may submit your changes in one of two ways:
>>>>>>>>>
>>>>>>>>> An update to the provided XML file
>>>>>>>>> — OR —
>>>>>>>>> An explicit list of changes in this format
>>>>>>>>>
>>>>>>>>> Section # (or indicate Global)
>>>>>>>>>
>>>>>>>>> OLD:
>>>>>>>>> old text
>>>>>>>>>
>>>>>>>>> NEW:
>>>>>>>>> new text
>>>>>>>>>
>>>>>>>>> You do not need to reply with both an updated XML file and an
>>>>>>>>> explicit list of changes, as either form is sufficient.
>>>>>>>>>
>>>>>>>>> We will ask a stream manager to review and approve any changes that
>>>>>>>>> seem beyond editorial in nature, e.g., addition of new text, deletion
>>>>>>>>> of text, and technical changes.  Information about stream managers
>>>>>>>>> can be found in the FAQ.  Editorial changes do not require approval from a stream manager.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Approving for publication
>>>>>>>>> --------------------------
>>>>>>>>>
>>>>>>>>> To approve your RFC for publication, please reply to this email
>>>>>>>>> stating that you approve this RFC for publication.  Please use ‘REPLY
>>>>>>>>> ALL’, as all the parties CCed on this message need to see your approval.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Files
>>>>>>>>> -----
>>>>>>>>>
>>>>>>>>> The files are available here:
>>>>>>>>> https://www.rfc-editor.org/authors/rfc9548.xml
>>>>>>>>> https://www.rfc-editor.org/authors/rfc9548.html
>>>>>>>>> https://www.rfc-editor.org/authors/rfc9548.pdf
>>>>>>>>> https://www.rfc-editor.org/authors/rfc9548.txt
>>>>>>>>>
>>>>>>>>> Diff file of the text:
>>>>>>>>> https://www.rfc-editor.org/authors/rfc9548-diff.html
>>>>>>>>> https://www.rfc-editor.org/authors/rfc9548-rfcdiff.html (side by
>>>>>>>>> side)
>>>>>>>>>
>>>>>>>>> Diff of the XML:
>>>>>>>>> https://www.rfc-editor.org/authors/rfc9548-xmldiff1.html
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Tracking progress
>>>>>>>>> -----------------
>>>>>>>>>
>>>>>>>>> The details of the AUTH48 status of your document are here:
>>>>>>>>> https://www.rfc-editor.org/auth48/rfc9548
>>>>>>>>>
>>>>>>>>> Please let us know if you have any questions.
>>>>>>>>>
>>>>>>>>> Thank you for your cooperation,
>>>>>>>>>
>>>>>>>>> RFC Editor
>>>>>>>>>
>>>>>>>>> --------------------------------------
>>>>>>>>> RFC9548 (draft-pkcs12-gost-08)
>>>>>>>>>
>>>>>>>>> Title            : Generating the Transport Key Containers Using the GOST Algorithms
>>>>>>>>> Author(s)        : E. Karelina, Ed.
>>>>>>>>> WG Chair(s)      :
>>>>>>>>> Area Director(s) :
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>