Re: [dane] SMIMEA prototyping

Richard Lamb <richard.lamb@icann.org> Tue, 30 September 2014 18:36 UTC

Return-Path: <richard.lamb@icann.org>
X-Original-To: dane@ietfa.amsl.com
Delivered-To: dane@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D59511A876F for <dane@ietfa.amsl.com>; Tue, 30 Sep 2014 11:36:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.687
X-Spam-Level:
X-Spam-Status: No, score=-2.687 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001] autolearn=ham
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 HlswJV0YVwrW for <dane@ietfa.amsl.com>; Tue, 30 Sep 2014 11:36:17 -0700 (PDT)
Received: from out.west.pexch112.icann.org (pfe112-ca-1.pexch112.icann.org [64.78.40.7]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 89B181A8765 for <dane@ietf.org>; Tue, 30 Sep 2014 11:36:17 -0700 (PDT)
Received: from PMBX112-W1-CA-1.pexch112.icann.org (64.78.40.21) by PMBX112-W1-CA-1.pexch112.icann.org (64.78.40.21) with Microsoft SMTP Server (TLS) id 15.0.847.32; Tue, 30 Sep 2014 11:36:15 -0700
Received: from PMBX112-W1-CA-1.pexch112.icann.org ([64.78.40.21]) by PMBX112-W1-CA-1.PEXCH112.ICANN.ORG ([64.78.40.21]) with mapi id 15.00.0847.030; Tue, 30 Sep 2014 11:36:15 -0700
From: Richard Lamb <richard.lamb@icann.org>
To: "Osterweil, Eric" <eosterweil@verisign.com>, dane WG list <dane@ietf.org>
Thread-Topic: SMIMEA prototyping
Thread-Index: AQHP29q7Y0Wg27e53U2QPZq9K7XNoJwaANlw
Date: Tue, 30 Sep 2014 18:36:14 +0000
Message-ID: <3bd8ffc5c4ce4510ac3c1072c28e5c3a@PMBX112-W1-CA-1.PEXCH112.ICANN.ORG>
References: <ED6F2DCA-C3D9-4B40-A94C-AAF93C4A3882@verisign.com>
In-Reply-To: <ED6F2DCA-C3D9-4B40-A94C-AAF93C4A3882@verisign.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
x-originating-ip: [76.103.0.6]
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg="SHA1"; boundary="----=_NextPart_000_00A2_01CFDCA2.BF0B8690"
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/dane/4VraemPgQB32181-hInRvif2tfM
Subject: Re: [dane] SMIMEA prototyping
X-BeenThere: dane@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: DNS-based Authentication of Named Entities <dane.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dane>, <mailto:dane-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dane/>
List-Post: <mailto:dane@ietf.org>
List-Help: <mailto:dane-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:dane-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 30 Sep 2014 18:36:20 -0000

Very cool.   Ive been waiting for the "killer app" and something better than
Kaminsky's Outlook+DNSSEC/phreebird demo of 2008.  I assume you mean DNSSEC
Workshop @ ICANN 51 usually on Wed.  Is a separate DANE workshop?

Looking forward to seeing the demo...
Rick

-----Original Message-----
From: dane [mailto:dane-bounces@ietf.org] On Behalf Of Osterweil, Eric
Sent: Monday, September 29, 2014 4:45 AM
To: dane WG list
Subject: [dane] SMIMEA prototyping

Hey everyone,

A few of us at Verisign (actually, that would be Lynch Davis) have been
working on a prototype for the SMIMEA draft.  We have written a general
library+API, we have integrated it into Thunderbird, and have begun
integrating into Mail.app.  Our plans are to publish this as open source at
some point after the DANE workshop that will be taking place at ICANN 51
(where we will be demo'ing it).  We ran into numerous interesting wrinkles
and made some specific design choices, but at a high level the S/MIME
prototype:
- can sign
- can encrypt
- can decrypt (without writing clear text to disk)
- can verify
- and supports several features that are enabled through suggested
additions.

With the foresight that zones may need to be delegated to accommodate churn
and scale, some certificates may need to be selectively authenticated or
deauthenticated (perhaps on a per-user basis), and the locations of
certificate information may need to be managed in different places (some in
the DNS, some in external locations), etc. we have made some operational
choices to modify elements of the draft in our prototype.  We intend to
detail these in a follow-on email.

We're hoping to show this off at the upcoming IETF too.

Eric