Subject: [smime] [Technical Errata Reported] RFC5652 (5331)

From: RFC Errata System <[email-masked]>
Date: Mon, 23 Apr 2018 07:39:20 -0700 (PDT)

The following errata report has been submitted for RFC5652,
"Cryptographic Message Syntax (CMS)".

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata/eid5331

--------------------------------------
Type: Technical
Reported by: Thomas Stimm <[email-masked]>

Section: 6.1 and 8

Original Text
-------------
EncryptedData ::= SEQUENCE {
   version CMSVersion,
   encryptedContentInfo EncryptedContentInfo,
   unprotectedAttrs [1] IMPLICIT UnprotectedAttributes OPTIONAL }

EncryptedContentInfo ::= SEQUENCE {
   contentType ContentType,
   contentEncryptionAlgorithm ContentEncryptionAlgorithmIdentifier,
   encryptedContent [0] IMPLICIT EncryptedContent OPTIONAL }

Corrected Text
--------------
EncryptedData ::= SEQUENCE {
   version CMSVersion,
   encryptedContentInfo EncryptedContentInfo,
   encryptedContent [0] IMPLICIT EncryptedContent OPTIONAL,
   unprotectedAttrs [1] IMPLICIT UnprotectedAttributes OPTIONAL }

EncryptedContentInfo ::= SEQUENCE {
   contentType ContentType,
   contentEncryptionAlgorithm ContentEncryptionAlgorithmIdentifier }

Notes
-----
- Wrong enumeration of UnprotectedAttributes OPTIONAL [1] instead of [0]. 
- ‘UnprotectedAttributes OPTIONAL’ makes only sense, if ‘EncryptedContent OPTIONAL’ is available.
- It seems that OpenSSL and wolfSSL are using the suggested wrapping and are not following the RFC, here.

Instructions:
-------------
This erratum is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party  
can log in to change the status and edit the report, if necessary. 

--------------------------------------
RFC5652 (draft-ietf-smime-rfc3852bis-00)
--------------------------------------
Title               : Cryptographic Message Syntax (CMS)
Publication Date    : September 2009
Author(s)           : R. Housley
Category            : DRAFT STANDARD
Source              : S/MIME Mail Security
Area                : Security
Stream              : IETF
Verifying Party     : IESG

---

From: Russ Housley <[email-masked]>
Date: Mon, 23 Apr 2018 11:58:25 -0400

Thomas:

The original syntax for EncryptedData in your errata matches the syntax in RFC 2630 and its successors.  This matches many implementations.  Please explain more about the ratinonal for your proposed change.

Russ

---

From: Russ Housley <[email-masked]>
Date: Wed, 25 Apr 2018 17:40:49 -0400

Thomas:

You seem to believe that a specification cannot have a tag of 1 unless it has previously had a tag of 0.  That is not correct.

EncryptedData is quite purposefully a reduced form of EnvelopedData, where the fields related to key management have been omitted.  Both EncryptedData and EnvelopedData make use of EncryptedContentInfo.

Russ

> On Apr 24, 2018, at 3:56 AM, Stimm Thomas (ETAS-SEC/ECT-Bo) <[email-masked]> wrote:
> 
> Hi Russ,
> 
> as mentioned in Errata notes, wolfSSL [1] and OpenSSL [2] implementations for example does not follow the RFC, but my suggestion (screenshot and files attached to this mail).
> 
> Due to the type naming, it makes much more sense to have the EncryptedContent (aka chiphertext) as part of EncrytedData type instead as part of EncryptedContentInfo type.
> 
> Currently, EncryptedDate provides unprotectedAttrs [1] but there is not any [0] parameter. Thus, if EncryptedContent would NOT be moved from EncryptedContentInfo to EncryptedData (as suggested), at least 
> should be adjusted to
> 	unprotectedAttrs [0] IMPLICIT UnprotectedAttributes OPTIONAL }.
> 
> Finally, to my understanding: If EncryptedContent is not presented, no encryption was performed and thus no UnprotectedAttributes should be presented. So UnprotectedAttributes should never occur alone, which just highlights the dependency.
> 
> Best regards,
> Thomas
> 
> 
> [1] https://lapo.it/asn1js/#305006092A864886F70D010706A0433041020100303C06092A864886F70D010701301D060960864801650304012A041034E040E6395A1DF7FD2480D968DF2575801009EC30FC7074DE97D589529F2EBE2945
> [2] https://lapo.it/asn1js/#3081A306092A864886F70D010706A0819530819202010030818C06092A864886F70D010701301D060960864801650304012A041093F44C28362588B863DB4AD465872097806067639EAE0CE52B7BDB11D0CFEDC1A5CBB67E13D3E5183C4E82C47F797250CEEFE6ED5AE60CC5AB91FBBE992F311C39979382FF1EA2E8566D0FFB1E4231A8625581B129F53768C56425F7AEF8A67480BBCAEFE2E2AC2FE1F93562A5F3F1E4FA13
> 
> 
> 
> 
> -----Ursprüngliche Nachricht-----
> Von: Russ Housley [mailto:[email-masked]] 
> Gesendet: Montag, 23. April 2018 17:58
> An: Stimm Thomas (ETAS-SEC/ECT-Bo) <[email-masked]>
> Cc: Ben Kaduk <[email-masked]>; Eric Rescorla <[email-masked]>; Paul Hoffman <[email-masked]>; Blake Ramsdell <[email-masked]>; IETF SMIME <[email-masked]>
> Betreff: Re: [Technical Errata Reported] RFC5652 (5331)
> 
> Thomas:
> 
> <wolfSSL.enc><OpenSSL.enc>