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
