Search RFCs

RFC Editor

Found 5 records.

Status:Verified (4)

RFC 5008, "Suite B in Secure/Multipurpose Internet Mail Extensions (S/MIME)", September 2007

Note: This RFC has been obsoleted byRFC 6318

Errata ID:1729
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Sean Turner
Date Reported: 2009-03-16
Verifier Name: Russ Housley
Date Verified: 2010-04-08

Section 4.1 says:

      originator MUST be the originatorKey alternative.  The      originatorKey algorithm field MUST contain the id-ecPublicKey      object identifier (see Section 3) with NULL parameters.  The      originatorKey publicKey field MUST contain the message      originator's ephemeral public key, which is a DER-encoded ECPoint      (see Section 3).  The ECPoint SHOULD be represented in      uncompressed form.

It should say:

      originator MUST be the originatorKey alternative.  The       originatorKey algorithm field MUST contain the id-ecPublicKey       object identifier (see Section 3).  The parameters associated       with id-ecPublicKey MUST be absent, ECParameters, or NULL. The       parameters associated with id-ecPublicKey SHOULD be absent or       ECParameters, and NULL is allowed to support legacy implementations.        The originatorKey publicKey field MUST contain the message       originator's ephemeral public key, which is a DER-encoded ECPoint       (see Section 3).  The ECPoint SHOULD be represented in uncompressed       form.

Notes:

This change aligns RFC 5008 with the draft-ietf-smime-3278bis. The correct parameters for id-ecPublicKey is either absent or ECParameters not NULL. Retained NULL for backwards compatibility.

Errata ID:1902
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Sean Turner
Date Reported: 2009-10-05
Verifier Name: Russ Housley
Date Verified: 2010-04-08

Section 4.3 says:

      keyInfo contains the object identifier of the key-encryption      algorithm that will be used to wrap the content-encryption key and      NULL parameters.  In Suite B, Security Level 1, AES-128 Key Wrap      MUST be used, resulting in {id-aes128-wrap, NULL}.  In Suite B,      Security Level 2, AES-256 Key Wrap MUST be used, resulting in      {id-aes256-wrap, NULL}.

It should say:

      keyInfo contains the object identifier of the key-encryption      algorithm that will be used to wrap the content-encryption key and      absent parameters.  In Suite B, Security Level 1, AES-128 Key Wrap      MUST be used, resulting in {id-aes128-wrap}.  In Suite B,      Security Level 2, AES-256 Key Wrap MUST be used, resulting in      {id-aes256-wrap}.

Notes:

Parameters for AES-* Key Wrap MUST be absent according to RFC 3565.

Errata ID:2060
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Sean Turner
Date Reported: 2010-03-03
Verifier Name: Russ Housley
Date Verified: 2010-04-08

Section 2 says:

2.  SHA-256 and SHA-256

It should say:

2.  SHA-256 and SHA-384

Notes:

The title should reflect SHA-384 as the other hash algorithm.

Errata ID:4477
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: poima fuimaono
Date Reported: 2015-09-19
Verifier Name: Stephen Farrell
Date Verified: 2015-09-19

Section 2 says:

SHA-256 and SHA-256

It should say:

SHA-256 and SHA-384

Notes:

SHA-384 as other has algorithm

Status:Rejected (1)

RFC 5008, "Suite B in Secure/Multipurpose Internet Mail Extensions (S/MIME)", September 2007

Note: This RFC has been obsoleted byRFC 6318

Errata ID:1023
Status: Rejected
Type: Technical
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 expansionperformed should better have been accompanied by the insertion of thedefinite 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 / confusionIn Section 4.3, near the bottom of page 9, a new paragraph has beeninserted 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 textfrom 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 toconfusion.As already indicated above, apparently the former text shall describethe [SEC1] KDF in general, and the latter is intended to describe therestricted particular use of that KDF in the context of S/MIME.Therefore, the RFC should perhaps better have stated, in place ofthe 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 aboveclarification (or any proper alternate text of your choice)as an RFC Errata Note.

It should say:

-

Notes:

---VERIFIER NOTE---
Thanks for the careful review. I do not believe that these are worth the effort for an errata.

Report New Errata