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 >> >
signature.asc
Description: Message signed with OpenPGP
-- auth48archive mailing list -- auth48archive@rfc-editor.org To unsubscribe send an email to auth48archive-le...@rfc-editor.org
