[dane] use case for naming convention in the DNS for sign/encrypt functionality

"Rose, Scott" <scott.rose@nist.gov> Thu, 04 December 2014 16:14 UTC

Return-Path: <scott.rose@nist.gov>
X-Original-To: dane@ietfa.amsl.com
Delivered-To: dane@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com []) by ietfa.amsl.com (Postfix) with ESMTP id D952B1AD478 for <dane@ietfa.amsl.com>; Thu, 4 Dec 2014 08:14:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id Tb7SqEhfrGza for <dane@ietfa.amsl.com>; Thu, 4 Dec 2014 08:14:26 -0800 (PST)
Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0714.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:714]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CBB311AD486 for <dane@ietf.org>; Thu, 4 Dec 2014 08:14:25 -0800 (PST)
Received: from BY1PR09MB0440.namprd09.prod.outlook.com ( by BY1PR09MB0549.namprd09.prod.outlook.com ( with Microsoft SMTP Server (TLS) id; Thu, 4 Dec 2014 16:14:03 +0000
Received: from BY1PR09MB0439.namprd09.prod.outlook.com ( by BY1PR09MB0440.namprd09.prod.outlook.com ( with Microsoft SMTP Server (TLS) id; Thu, 4 Dec 2014 16:14:02 +0000
Received: from BY1PR09MB0439.namprd09.prod.outlook.com ([]) by BY1PR09MB0439.namprd09.prod.outlook.com ([]) with mapi id 15.01.0031.000; Thu, 4 Dec 2014 16:14:02 +0000
From: "Rose, Scott" <scott.rose@nist.gov>
To: dane WG list <dane@ietf.org>
Thread-Topic: use case for naming convention in the DNS for sign/encrypt functionality
Thread-Index: AQHQD91RwJfKriq3gEOhhMn9LNF6xQ==
Date: Thu, 4 Dec 2014 16:14:01 +0000
Message-ID: <6A29A54A-14B2-4120-B952-26876E403B08@nist.gov>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:BY1PR09MB0440;UriScan:;
x-exchange-antispam-report-test: UriScan:;
x-exchange-antispam-report-cfa-test: BCL:0;PCL:0;RULEID:;SRVR:BY1PR09MB0440;
x-forefront-prvs: 041517DFAB
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(979002)(6009001)(199003)(189002)(31966008)(4396001)(50986999)(33656002)(229853001)(82746002)(66066001)(99396003)(450100001)(110136001)(77156002)(20776003)(36756003)(102836002)(64706001)(62966003)(46102003)(15975445006)(19580395003)(106356001)(105586002)(87936001)(120916001)(19580405001)(83716003)(106116001)(92726001)(2656002)(97736003)(68736005)(99286002)(54356999)(101416001)(92566001)(122556002)(107046002)(21056001)(107886001)(40100003)(86362001)(15202345003)(104396002)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:1102; SCL:1; SRVR:BY1PR09MB0440; H:BY1PR09MB0439.namprd09.prod.outlook.com; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; A:1; MX:1; LANG:en;
Content-Type: text/plain; charset="us-ascii"
Content-ID: <259915FCBCFEC748B7B7D19EBC7DEC77@namprd09.prod.outlook.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;SRVR:BY1PR09MB0549;
X-OriginatorOrg: nist.gov
Archived-At: http://mailarchive.ietf.org/arch/msg/dane/dGynFzi1OpCr6pnKaNfsWvjwNes
Subject: [dane] use case for naming convention in the DNS for sign/encrypt functionality
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: Thu, 04 Dec 2014 16:14:29 -0000

>From the interim meeting - 

Using a naming convention for designating sign/encrypt becomes useful when CU=3 is used.  If SMIMEA is going to follow the same interpretation as in TLSA, then the client may not be doing any other checks or use any other parts of the cert such as the keyUsage field.  They may not even be present in the cert - just a bare bones X.509 that may not contain much beyond the public key.  So if an enterprise wants to use certs with CU=3 and separation of roles, this functionality becomes useful.

A varient of that could be an enterprise using a local trust anchor (CU 2) for digital signature certs in a wildcard SMIMEA (to cover all domain users), and generating encryption certs and using CU=3 since clients won't be able to perform full PKIX validation to the local trust anchor if they don't have it stored locally.  In a way, the encryption certs could be views as opportunistic S/MIME.  So you have:

*._sign._smimecert.example.com  IN SMIMEA  2 0 1 <blob of local TA>

and for each user that is allowed to accept encrypted mail:
<user>._encr._smimecert.example.com  IN SMIMEA 3 0 0 <blob of local TA (or self) signed cert>

The draft will have to have some text to specify when a client should not rely on the keyUsage field in the cert, and what to do if the field is not present in the cert at all.  A lot of this can be done without the naming convention, but it allows more flexibility and allows for easier management for some usage scenarios.  


Scott Rose
+1 301-975-8439
Google Voice: +1 571-249-3671