Hi Russ, Thanks for verifying — we have noted your approval and will continue with publication shortly.
Thank you, RFC Editor/sg > On Jan 9, 2025, at 11:04 AM, Russ Housley <hous...@vigilsec.com> wrote: > > Sandy: > > I have double checked the ASN.1, and it compiles properly, > > Please proceed with publication. > > Russ > >> On Jan 8, 2025, at 8:48 PM, Sandy Ginoza <sgin...@staff.rfc-editor.org> >> wrote: >> >> Hi Russ, >> >> We have updated the document and posted the files here: >> https://www.rfc-editor.org/authors/rfc9709.xml >> https://www.rfc-editor.org/authors/rfc9709.txt >> https://www.rfc-editor.org/authors/rfc9709.pdf >> https://www.rfc-editor.org/authors/rfc9709.html >> >> AUTH48 diff: >> https://www.rfc-editor.org/authors/rfc9709-auth48diff.html >> >> Comprehensive diffs: >> https://www.rfc-editor.org/authors/rfc9709-diff.html >> https://www.rfc-editor.org/authors/rfc9709-rfcdiff.html >> >> Please review the updates, especially the changes to ASN.1, and let us know >> if any additional updates are needed or if you approve the RFC for >> publication. >> >> Thanks, >> RFC Editor/sg >> >> >> >>> On Jan 7, 2025, at 11:29 AM, Russ Housley <hous...@vigilsec.com> wrote: >>> >>> Der RFC Editor: >>> >>>> 1) <!-- [rfced] Please insert any keywords (beyond those that appear in >>>> the title) for use on https://www.rfc-editor.org/search. --> >>> >>> Please add: >>> * content-encryption key >>> * content-authenticated-encryption key >>> >>>> 2) <!-- [rfced] Note that we changed "input key material" to "input keying >>>> material" here because OKM is introduced as "output keying material (OKM)" >>>> and IKM is defined as "input keying material" under Inputs. Please let us >>>> know if this is incorrect. >>>> >>>> Original: >>>> The mitigation uses the HMAC-based Extract-and-Expand Key Derivation >>>> Function (HKDF) [RFC5869] to derive output keying material (OKM) from >>>> input key material (IKM). >>>> --> >>> >>> RFC 5869 uses: >>> * IKM = input keying material >>> * OKM = output keying material >>> >>> So, I think the changes you made are correct. >>> >>>> 3) <!-- [rfced] Section 2: We converted this <artwork> into a <dl> that is >>>> followed by <artwork>. Please review and let us know if this is >>>> incorrect. >>>> >>>> Original XML: >>>> <artwork><![CDATA[ >>>> >>>> Inputs: >>>> IKM input keying material >>>> info DER-encoded AlgoritmIdentifier >>>> >>>> Output: >>>> OKM output keying material (same size as IKM) >>>> >>>> The output OKM is calculated as follows: >>>> >>>> OKM_SIZE = len(IKM) /* length in octets */ >>>> IF OKM_SIZE > 8160 THEN raise error >>>> >>>> salt = "The Cryptographic Message Syntax" >>>> PRK = HKDF-Extract(salt, IKM) >>>> >>>> OKM = HKDF-Expand(PRK, info, OKM_SIZE) >>>> >>>> ]]></artwork> >>>> --> >>> >>> It looks fine to me. >>> >>> >>>> 4) <!-- [rfced] Note that we lowercased the following throughout. Please >>>> let us know if corrections are needed. >>>> >>>> Enveloped-data -> enveloped-data (matches RFC 5652) >>>> Authenticated-Enveloped-Data -> authenticated-enveloped-data (matches RFC >>>> 5083) >>>> --> >>> >>> This works for me. >>> >>> >>>> 5) <!-- [rfced] Because the text is quoted from RFC 5652, we marked it as >>>> a >>>> blockquote and updated it to match RFC 5652 exactly. Note that the HTML >>>> and >>>> PDF are linked to Section 6.3 of RFC 5652. However, the TXT only says >>>> "see >>>> Section 6.3". Please let us know if this causes any concern. >>>> >>>> Original (first sentence included for context): >>>> The fourth step of constructing an Enveloped-data is repeated below >>>> from Section 6 of [RFC5652]: >>>> >>>> 4. The content is encrypted with the content-encryption key. >>>> Content encryption may require that the content be padded to a >>>> multiple of some block size; see Section 6.3 of [RFC5652]. >>>> >>>> Current: >>>> | 4. The content is encrypted with the content-encryption key. >>>> | Content encryption may require that the content be padded to a >>>> | multiple of some block size; see Section 6.3. >>>> >>>> --> >>> >>> This works for me. >>> >>> >>>> 6) <!-- [rfced] Similar to above, we have changed the following to a >>>> blockquote and updated "Section 6.3 of [RFC5652]" to "Section 6.3 of >>>> [CMS]". "6.3" currently links to Section 6.3 of RFC 3852 to accurately >>>> reflect the intent of RFC 5083. In order to link to RFC 3852, we had to >>>> add an informative reference to RFC 3852 and an in-text citation. >>>> Therefore, we included a note to highlight that RFC 3852 >>>> has been obsoleted. Please review and let us know if you have concerns or >>>> have an alternate suggestion. >>>> >>>> Original (the first sentence is included for context): >>>> The fifth step of constructing an Authenticated-Enveloped-Data is >>>> repeated below from Section 2 of [RFC5083]: >>>> >>>> 5. The attributes collected in step 4 are authenticated and the CMS >>>> content is authenticated and encrypted with the content- >>>> authenticated-encryption key. If the authenticated encryption >>>> algorithm requires either the additional authenticated data (AAD) >>>> or the content to be padded to a multiple of some block size, >>>> then the padding is added as described in Section 6.3 of >>>> [RFC5652]. >>>> >>>> Perhaps: >>>> | 5. The attributes collected in step 4 are authenticated and the >>>> | CMS content is authenticated and encrypted with the content- >>>> | authenticated-encryption key. If the authenticated encryption >>>> | algorithm requires either the additional authenticated data >>>> | (AAD) or the content to be padded to a multiple of some block >>>> | size, then the padding is added as described in Section 6.3 of >>>> | [CMS]. >>>> >>>> Note that [CMS] refers to RFC 3852, which has been obsoleted by RFC >>>> 5652, but the text in Section 6.3 was unchanged in RFC 5652. >>>> --> >>> >>> This works for me. >>> >>> >>>> 7) <!-- [rfced] "message content plaintext" reads awkwardly to us. Would >>>> "plaintext message content" also work? It appears twice in the following >>>> text. >>>> >>>> Original: >>>> Mitigation strategies for unwanted message traffic involve analysis >>>> of message content plaintext. When recipients accept unsolicited >>>> encrypted messages, they become even more vulnerable to unwanted >>>> traffic since many mitigation strategies will be unable to access the >>>> message content plaintext. >>>> --> >>> >>> Yes, I am fine with "plaintext message content". >>> >>> >>>> 8) <!-- [rfced] We replaced TBD0 with value 80 in the ASN.1, but we note a >>>> disrepancy in the year: >>>> >>>> Original: >>>> id-mod-CMS-CEK-HKDF-SHA256-2024(TBD0) >>>> >>>> The description in the IANA Considerations section uses 2023: >>>> id-mod-CMS-CEK-HKDF-SHA256-2023 >>>> >>>> Please review and let us know if 2023 or 2024 is correct. >>> >>> Please use "2023" to be consistent with the IANA Considerations. >>> >>> >>>> In addition, are these slight variations in the ASN.1 correct? >>>> >>>> pkcs9(9) vs pkcs-9(9) >>>> id-smime(16) vs smime(16) >>>> >>>> Section 3: >>>> id-alg-cek-hkdf-sha256 OBJECT IDENTIFIER ::= { iso(1) >>>> member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) >>>> smime(16) alg(3) 31 } >>>> >>>> Appendix A: >>>> CMS-CEK-HKDF-SHA256-Module-2024 >>>> { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9) >>>> id-smime(16) id-mod(0) id-mod-CMS-CEK-HKDF-SHA256-2024(TBD0) } >>>> >>>> ... >>>> >>>> id-alg-cek-hkdf-sha256 OBJECT IDENTIFIER ::= { iso(1) member-body(2) >>>> us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) alg(3) 31 } >>>> --> >>> >>> Good catch. Please use these in both places: >>> * pkcs-9(9) >>> * id-smime(16) >>> >>> >>>> 9) <!-- [rfced] The ANS.1 refers to RFC 5911, but it does not mention RFC >>>> 5912. Should RFC 5912 be mentioned? >>>> >>>> Original: >>>> This ASN.1 module builds upon the conventions established in [RFC5911] >>>> and [RFC5912]. >>>> >>>> ... >>>> >>>> FROM AlgorithmInformation-2009 - in [RFC5911] >>>> >>>> (note: double hyphen reduced to a single above so this can be included in >>>> a comment.) >>>> --> >>> >>> It would be fine to drop the reference to RFC 5912. The reference to RFC >>> 5911 is good enough. >>> >>> >>>> 10) <!-- [rfced] In B.1 and B.2, we have changed <artwork> to <sourcecode >>>> type="test-vectors"> because "test-vectors" are a defined sourcecode type >>>> (see https://www.rfc-editor.org/rpc/wiki/doku.php?id=sourcecode-types). >>>> Please review. >>>> --> >>> >>> This works for me. >>> >>> >>>> 11) <!-- [rfced] Please review the "Inclusive Language" portion of the >>>> online Style Guide >>>> <https://www.rfc-editor.org/styleguide/part2/#inclusive_language> >>>> and let us know if any changes are needed. Updates of this nature >>>> typically result in more precise language, which is helpful for readers. >>>> >>>> Note that our script did not flag any words in particular, but this should >>>> still be reviewed as a best practice. >>>> --> >>> >>> I do not see any language that needs to be changed. >>> >>> Russ >>> >> > -- auth48archive mailing list -- auth48archive@rfc-editor.org To unsubscribe send an email to auth48archive-le...@rfc-editor.org
