[dane] Discussion on OPENPGP and SMIME record location

Olafur Gudmundsson <ogud@ogud.com> Mon, 20 July 2015 09:09 UTC

Return-Path: <ogud@ogud.com>
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 CF01D1A00FA for <dane@ietfa.amsl.com>; Mon, 20 Jul 2015 02:09:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 f90mC2YDSbUL for <dane@ietfa.amsl.com>; Mon, 20 Jul 2015 02:09:03 -0700 (PDT)
Received: from smtp84.iad3a.emailsrvr.com (smtp84.iad3a.emailsrvr.com [173.203.187.84]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 47EBC1A00E9 for <dane@ietf.org>; Mon, 20 Jul 2015 02:09:03 -0700 (PDT)
Received: from smtp3.relay.iad3a.emailsrvr.com (localhost.localdomain [127.0.0.1]) by smtp3.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id 1626F300289 for <dane@ietf.org>; Mon, 20 Jul 2015 05:09:02 -0400 (EDT)
Received: by smtp3.relay.iad3a.emailsrvr.com (Authenticated sender: ogud-AT-ogud.com) with ESMTPSA id 8671930020D for <dane@ietf.org>; Mon, 20 Jul 2015 05:09:00 -0400 (EDT)
X-Sender-Id: ogud@ogud.com
Received: from dhcp-hotel-wired-1-fb.meeting.ietf.org ([UNAVAILABLE]. [130.129.1.251]) (using TLSv1 with cipher DHE-RSA-AES256-SHA) by 0.0.0.0:587 (trex/5.4.2); Mon, 20 Jul 2015 09:09:02 GMT
From: Olafur Gudmundsson <ogud@ogud.com>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Message-Id: <F28B95F0-E30A-40BD-866B-2389F9D0D591@ogud.com>
Date: Mon, 20 Jul 2015 05:08:58 -0400
To: dane <dane@ietf.org>
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2102\))
X-Mailer: Apple Mail (2.2102)
Archived-At: <http://mailarchive.ietf.org/arch/msg/dane/iBnaWP8Au0bPrDbayXODq8Oe0P4>
Subject: [dane] Discussion on OPENPGP and SMIME record location
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: <https://mailarchive.ietf.org/arch/browse/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: Mon, 20 Jul 2015 09:09:05 -0000

Dear Colleagues 

This note is to stimulate discussion, on higher level design of the these two email protocol, 
discussion on local-part “name” is a separate discussion. 

Right now we have two “active” email sign/encrypt technologies, proposing to store “keying” information in DNS, 
When we want to do a lookup we have two design dimensions, 
— names 
— types 

In the name space OPENPGP and SMIME are proposing two different “zones”/names where keying info is stored this has certain advantages and disadvantages. 
Further more there have been proposals to have different “zones” for sign and encrypt for SMIME. 

Pro: 
	- easy to see if organization "supports" technology 
      - if SMIME is operated by different group than PGP then there are no organizational conflicts

Con:
     - To see if user X supports encrypted mail may require 2x lookups ( i.e. in each Technology X all local part guesses) for organizations that have users that use both PGP and SMIME
     - more DNS data to maintain and sign. 

Antidode: If an organization has to support users with both types of keys, it can publish both in one zone by using DNAME. 

In the type space we have OPENPGPKEY and SIMIMEA types proposed and the idea is that the contnents of the records specify usage rules. 
We can also do this via more types. 

We have seen arguments in the past ranging from “Lets ignore this” to “We MUST support organizational realities including split views” 

Question: 
 a) do we want to merge the zones where EMAIL keying is stored ? 

or  
 b) Do we want to reflect policies in naming? 
 c) do we want to reflect polices in types 
 d) do we want to reflect policies inside records 

or 
 f) we can not answer this, experience will have to guide us. 

Think about how you want to answer these questions and lets have a short discussion in the meeting on Monday but please start discussion on the mailing list if you feel strongly about this 

Olafur & Warren 

PS: if you have a speaking slot in the meeting, now is a good time to send in slides