RFC 5008, "Suite B in Secure/Multipurpose Internet Mail Extensions (S/MIME)", September 2007
Note: This RFC has been obsoleted by RFC 6318Source of RFC: IETF - NON WORKING GROUP
Area Assignment: sec
Errata ID: 1023
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2007-09-18
Rejected by: Russ Housley
Date Rejected: 2007-09-18
(1) Section 3 (nit) In the first sentence of Section 3 (on page 3), the acronym expansion performed should better have been accompanied by the insertion of the definite article. The RFC says: This section specifies the conventions employed by implementations | that support Elliptic Curve Digital Signature Algorithm (ECDSA). The direction set by RFC 3278 [CMSECC] is followed, but additional message digest algorithms and additional elliptic curves are employed. [...] It should perhaps better say: This section specifies the conventions employed by implementations | that support the Elliptic Curve Digital Signature Algorithm (ECDSA). The direction set by RFC 3278 [CMSECC] is followed, but additional message digest algorithms and additional elliptic curves are employed. [...] (2) Section 4.3 -- imprecise text, danger of ambiguity / confusion In Section 4.3, near the bottom of page 9, a new paragraph has been inserted in the part describing the [SEC1] KDF in general: To generate a key-encryption key, one or more KM blocks are generated, incrementing Counter appropriately, until enough material has been generated. The KM blocks are concatenated left to right: KEK = KM ( counter=1 ) || KM ( counter=2 ) ... But near the end of Section 4.3, on mid-page 10, the original text from the draft has been left unchanged: | To generate a key-encryption key, one KM block is generated, with a Counter value of 0x00000001: KEK = KM ( 1 ) = Hash ( Z || Counter=1 || ECC-CMS-SharedInfo ) These two different, but very similar statements might well lead to confusion. As already indicated above, apparently the former text shall describe the [SEC1] KDF in general, and the latter is intended to describe the restricted particular use of that KDF in the context of S/MIME. Therefore, the RFC should perhaps better have stated, in place of the latter text: vvvvvvvvvvvvvvvvvvvvvv | To generate a key-encryption key for Suite B in S/MIME, one KM block is generated, with a Counter value of 0x00000001: KEK = KM ( 1 ) = Hash ( Z || Counter=1 || ECC-CMS-SharedInfo ) ________ Note: It might have been even more suitable to have that text be moved up, making it part of the indented explanation of the 'Counter' element (2nd paragraph on page 10), where it could have been kept shorter: Counter is a 32-bit unsigned number, represented in network byte order. Its initial value MUST be 0x00000001 for any key derivation operation. In Suite B, Security Level 1 and Security Level 2, exactly one iteration is needed; the Counter is not | incremented; i.e., one KM block is generated, with a Counter value | of 0x00000001: | | KEK = KM ( 1 ) = Hash ( Z || Counter=1 || ECC-CMS-SharedInfo ) ________ As a minimally invasive change, I recommend posting the above clarification (or any proper alternate text of your choice) as an RFC Errata Note.
It should say:
Thanks for the careful review. I do not believe that these are worth the effort for an errata.