Re: [Technical Errata Reported] RFC5652 (5331)

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 protected]> 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 
> 	unprotectedAttrs [1] IMPLICIT UnprotectedAttributes OPTIONAL }
> 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 protected]] 
> Gesendet: Montag, 23. April 2018 17:58
> An: Stimm Thomas (ETAS-SEC/ECT-Bo) <[email protected]>
> Cc: Ben Kaduk <[email protected]>; Eric Rescorla <[email protected]>; Paul Hoffman <[email protected]>; Blake Ramsdell <[email protected]>; IETF SMIME <[email protected]>
> Betreff: Re: [Technical Errata Reported] RFC5652 (5331)
> 
> 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
> 
> <wolfSSL.enc><OpenSSL.enc><OpenSSL_enc.png>

_______________________________________________
smime mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/smime