RFC Errata


Errata Search

 
Source of RFC  
Summary Table Full Records

Found 4 records.

Status: Verified (4)

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

Note: This RFC has been obsoleted by RFC 6318

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: sec

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

Report New Errata



Advanced Search