Yes document it okay approved On Sat, Jan 4, 2025, 3:16 AM RFC Editor via auth48archive < [email protected]> wrote:
> Russ, > > While reviewing this document during AUTH48, please resolve (as necessary) > the following questions, which are also in the XML file. > > 1) <!-- [rfced] Please insert any keywords (beyond those that appear in > the title) for use on https://www.rfc-editor.org/search. --> > > > 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). > --> > > > 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> > --> > > > 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) > --> > > > 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. > > --> > > > 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. > --> > > > 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. > --> > > > 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. > > > 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 } > --> > > > 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.) > --> > > > 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. > --> > > > 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. > --> > > > Thank you. > > RFC Editor > > > On Jan 3, 2025, at 6:08 PM, [email protected] wrote: > > *****IMPORTANT***** > > Updated 2025/01/03 > > 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 > > * [email protected] (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). > > * [email protected], 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-4Q9l2USxIAe6P8O4Zc > > * 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, > [email protected] 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/rfc9709.xml > https://www.rfc-editor.org/authors/rfc9709.html > https://www.rfc-editor.org/authors/rfc9709.pdf > https://www.rfc-editor.org/authors/rfc9709.txt > > Diff file of the text: > https://www.rfc-editor.org/authors/rfc9709-diff.html > https://www.rfc-editor.org/authors/rfc9709-rfcdiff.html (side by side) > > Diff of the XML: > https://www.rfc-editor.org/authors/rfc9709-xmldiff1.html > > > Tracking progress > ----------------- > > The details of the AUTH48 status of your document are here: > https://www.rfc-editor.org/auth48/rfc9709 > > Please let us know if you have any questions. > > Thank you for your cooperation, > > RFC Editor > > -------------------------------------- > RFC9709 (draft-ietf-lamps-cms-cek-hkdf-sha256-05) > > Title : Encryption Key Derivation in the Cryptographic Message > Syntax (CMS) using HKDF with SHA-256 > Author(s) : R. Housley > WG Chair(s) : Russ Housley, Tim Hollebeek > Area Director(s) : Deb Cooley, Paul Wouters > > > -- > auth48archive mailing list -- [email protected] > To unsubscribe send an email to [email protected] >
-- auth48archive mailing list -- [email protected] To unsubscribe send an email to [email protected]
