[Spasm] Document Updates

Jim Schaad <ietf@augustcellars.com> Mon, 13 March 2017 19:51 UTC

Return-Path: <ietf@augustcellars.com>
X-Original-To: spasm@ietfa.amsl.com
Delivered-To: spasm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 42803129481 for <spasm@ietfa.amsl.com>; Mon, 13 Mar 2017 12:51:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.002
X-Spam-Level:
X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=augustcellars.com
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 WPc0yDXXnSLs for <spasm@ietfa.amsl.com>; Mon, 13 Mar 2017 12:51:00 -0700 (PDT)
Received: from mail4.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 400F2129A92 for <spasm@ietf.org>; Mon, 13 Mar 2017 12:40:48 -0700 (PDT)
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Content-Language: en-us
DKIM-Signature: v=1; a=rsa-sha256; d=augustcellars.com; s=winery; c=simple/simple; t=1489434045; h=from:subject:to:date:message-id; bh=VfCz/YhrHH2Yz+mScpXvx9LD37yPvG/LQyb2QI2sJBA=; b=NkAGQ0BWP/vHbwC9SzfT0TRkwkos/h10b7mAlKUPvhyGVCpppp6n023CTlG5SDE3+FivS2tKyzS /YiBDPNIIxBfzJgV+4ARga7v9hvmbBHdNki0LifhsVFWSUiexKxNgEcbzb4nAE1KV1FULE+PEtke7 kJt3oOYuNxMzCkvDM9kAdjIUSMl1194wGNNQCDttI4lzWUG3yksH8apQkrbMcRGyMcSxCdJqKk/8k MIbLZBmZ4m4vbQTF1vX8hblXx4DgD4q5E7iWSYo5+7INAsK4ORcOWN3ZiEL6P5f3vl6bLr7kwyrtQ yCO6TZ8j8nUgs/OKxBQPWdSOm6Cza+jR54Vw==
Received: from mail2.augustcellars.com (192.168.1.201) by mail4.augustcellars.com (192.168.1.153) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Mon, 13 Mar 2017 12:40:44 -0700
Received: from hebrews (24.21.96.37) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Mon, 13 Mar 2017 12:38:26 -0700
From: Jim Schaad <ietf@augustcellars.com>
To: 'SPASM' <spasm@ietf.org>
Date: Mon, 13 Mar 2017 12:40:41 -0700
Message-ID: <0bea01d29c31$b4930430$1db90c90$@augustcellars.com>
MIME-Version: 1.0
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AdKcMO0yswrR1gmNTpyE1sH3gy3XdQ==
X-Originating-IP: [24.21.96.37]
Archived-At: <https://mailarchive.ietf.org/arch/msg/spasm/4WZlWOty3cPcV0iRojHdDg-dGi8>
Subject: [Spasm] Document Updates
X-BeenThere: spasm@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." <spasm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/spasm>, <mailto:spasm-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/spasm/>
List-Post: <mailto:spasm@ietf.org>
List-Help: <mailto:spasm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/spasm>, <mailto:spasm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 13 Mar 2017 19:51:02 -0000

I have released new versions of the two S/MIME documents to address all last
call comments received.

I have not dealt with one comment which has to do with the first default
algorithm to be used for encryption when there is no knowledge of what the
recipient of the message is capable of.  This has traditionally always been
the "best possible recommendation" that we can provide.  For this reason, I
have set it to AES-128 GCM.  

Russ has requested that this be changed to AES-256 CBC because we are
introducing not only a new algorithm but a new CMS structure at the same
time.  This means that not only would a down client be unable to decrypt the
message but would not recognize it as being an encrypted message. 

I do not really think that I care about this possible problem as it should
be dealt with cleanly, an ASN.1 decode error needs to be coped with.  For
this reason I do not think there is going to be a significant behavior
difference between an ASN.1 decode/message type recognition problem and a
cannot decrypt because the algorithm is unknown.

Jim