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)
<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,
Thomas
[1]
https://lapo.it/asn1js/#305006092A864886F70D010706A0433041020100303C06092A864886F70D010701301D060960864801650304012A041034E040E6395A1DF7FD2480D968DF2575801009EC30FC7074DE97D589529F2EBE2945
[2]
https://lapo.it/asn1js/#3081A306092A864886F70D010706A0819530819202010030818C06092A864886F70D010701301D060960864801650304012A041093F44C28362588B863DB4AD465872097806067639EAE0CE52B7BDB11D0CFEDC1A5CBB67E13D3E5183C4E82C47F797250CEEFE6ED5AE60CC5AB91FBBE992F311C39979382FF1EA2E8566D0FFB1E4231A8625581B129F53768C56425F7AEF8A67480BBCAEFE2E2AC2FE1F93562A5F3F1E4FA13
-----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)
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
smime(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/smime