IETF Logo Mail Archive

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

Russ Housley <housley@vigilsec.com> Wed, 25 April 2018 21:40 UTC

Return-Path: <housley@vigilsec.com>
X-Original-To: smime@ietfa.amsl.com
Delivered-To: smime@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D422112D7E4 for <smime@ietfa.amsl.com>; Wed, 25 Apr 2018 14:40:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nq4hhjyAC3vt for <smime@ietfa.amsl.com>; Wed, 25 Apr 2018 14:40:53 -0700 (PDT)
Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C989F12D7ED for <smime@ietf.org>; Wed, 25 Apr 2018 14:40:52 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 8CA0C300A32 for <smime@ietf.org>; Wed, 25 Apr 2018 17:40:50 -0400 (EDT)
X-Virus-Scanned: amavisd-new at mail.smeinc.net
Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id nCaS1_9PCJ0M for <smime@ietf.org>; Wed, 25 Apr 2018 17:40:48 -0400 (EDT)
Received: from a860b60074bd.home (pool-108-45-101-150.washdc.fios.verizon.net [108.45.101.150]) by mail.smeinc.net (Postfix) with ESMTPSA id 0A161300463; Wed, 25 Apr 2018 17:40:48 -0400 (EDT)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
From: Russ Housley <housley@vigilsec.com>
In-Reply-To: <e872ab03d8644f318f8aeba419aa7182@escrypt.com>
Date: Wed, 25 Apr 2018 17:40:49 -0400
Cc: Ben Kaduk <kaduk@mit.edu>, Eric Rescorla <ekr@rtfm.com>, Paul Hoffman <paul.hoffman@icann.org>, Blake Ramsdell <blaker@gmail.com>, IETF SMIME <smime@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <A5A55427-B97D-4CA4-88F2-C832F23C4E99@vigilsec.com>
References: <20180423143920.3E868B80E8F@rfc-editor.org> <B11F423E-0650-4EE2-B7C2-A7CB9AC0D556@vigilsec.com> <e872ab03d8644f318f8aeba419aa7182@escrypt.com>
To: "Stimm Thomas (ETAS-SEC/ECT-Bo)" <Thomas.Stimm@escrypt.com>
X-Mailer: Apple Mail (2.3273)
Archived-At: <https://mailarchive.ietf.org/arch/msg/smime/8bIEok_PdhnC0Woh3mToIBEl5mU>
Subject: Re: [smime] [Technical Errata Reported] RFC5652 (5331)
X-BeenThere: smime@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: SMIME Working Group <smime.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/smime>, <mailto:smime-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/smime/>
List-Post: <mailto:smime@ietf.org>
List-Help: <mailto:smime-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/smime>, <mailto:smime-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 25 Apr 2018 21:40:55 -0000

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.Stimm@escrypt.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@vigilsec.com] 
> Gesendet: Montag, 23. April 2018 17:58
> An: Stimm Thomas (ETAS-SEC/ECT-Bo) <Thomas.Stimm@escrypt.com>
> Cc: Ben Kaduk <kaduk@mit.edu>; Eric Rescorla <ekr@rtfm.com>; Paul Hoffman <paul.hoffman@icann.org>; Blake Ramsdell <blaker@gmail.com>; IETF SMIME <smime@ietf.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>

v2.23.0 | Report a Bug | By Email