[Top] [All Lists]

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

2018-04-25 16:41:03

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.


On Apr 24, 2018, at 3:56 AM, Stimm Thomas (ETAS-SEC/ECT-Bo) 
<Thomas(_dot_)Stimm(_at_)escrypt(_dot_)com> 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,


-----Ursprüngliche Nachricht-----
Von: Russ Housley [mailto:housley(_at_)vigilsec(_dot_)com] 
Gesendet: Montag, 23. April 2018 17:58
An: Stimm Thomas (ETAS-SEC/ECT-Bo) <Thomas(_dot_)Stimm(_at_)escrypt(_dot_)com>
Cc: Ben Kaduk <kaduk(_at_)mit(_dot_)edu>; Eric Rescorla 
<ekr(_at_)rtfm(_dot_)com>; Paul Hoffman 
<paul(_dot_)hoffman(_at_)icann(_dot_)org>; Blake Ramsdell 
<blaker(_at_)gmail(_dot_)com>; IETF SMIME <smime(_at_)ietf(_dot_)org>
Betreff: Re: [Technical Errata Reported] RFC5652 (5331)


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.



smime mailing list

<Prev in Thread] Current Thread [Next in Thread>