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
