Re: [dane] use case for naming convention in the DNS for sign/encrypt functionality
Paul Wouters 🔓 <paul@nohats.ca> Thu, 04 December 2014 17:06 UTC
Return-Path: <paul@nohats.ca>
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 7FE831A024C for <dane@ietfa.amsl.com>; Thu, 4 Dec 2014 09:06:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.71
X-Spam-Level:
X-Spam-Status: No, score=-1.71 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MIME_8BIT_HEADER=0.3, T_RP_MATCHES_RCVD=-0.01] autolearn=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 htsPShE25USB for <dane@ietfa.amsl.com>; Thu, 4 Dec 2014 09:06:42 -0800 (PST)
Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7F3E91AD4CD for <dane@ietf.org>; Thu, 4 Dec 2014 09:06:40 -0800 (PST)
Received: from bofh.nohats.ca (bofh.nohats.ca [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id B2563817C1; Thu, 4 Dec 2014 12:06:38 -0500 (EST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1417712798; bh=QDhaH+Ny2iJvkEFVHWyZmHwvWFbCUSGsVmvSQ2NiLY0=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=LeyzEY1bzlZHliNQEzfXqvM2+R0B5SAI9rA6TAzrPJCdwnHqDFITi+ZBr/yqobAKl CgJFNaexF+CDnfdc30xQNDRM2jxURcBLoW4P2MXqexsoLBiqKhQIyA+HpLDX2kyHhR lYaIftWLu4casPfuBpZDdpZVn0HNKHCeU7OK2dh8=
Received: from localhost (paul@localhost) by bofh.nohats.ca (8.14.7/8.14.7/Submit) with ESMTP id sB4H6cjq030109; Thu, 4 Dec 2014 12:06:38 -0500
X-Authentication-Warning: bofh.nohats.ca: paul owned process doing -bs
Date: Thu, 04 Dec 2014 12:06:37 -0500
From: Paul Wouters 🔓 <paul@nohats.ca>
To: "Rose, Scott" <scott.rose@nist.gov>
In-Reply-To: <6A29A54A-14B2-4120-B952-26876E403B08@nist.gov>
Message-ID: <alpine.LFD.2.10.1412041127450.13902@bofh.nohats.ca>
References: <6A29A54A-14B2-4120-B952-26876E403B08@nist.gov>
User-Agent: Alpine 2.10 (LFD 1266 2009-07-14)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset="US-ASCII"; format="flowed"
Archived-At: http://mailarchive.ietf.org/arch/msg/dane/5qlCqkcfJcjh8IfZ2eccSRfXYu0
Cc: dane WG list <dane@ietf.org>
Subject: Re: [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 17:06:43 -0000
On Thu, 4 Dec 2014, Rose, Scott wrote: > 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. But RFC 6698 states: The difference between certificate usage 1 and certificate usage 3 is that certificate usage 1 requires that the certificate pass PKIX validation, but PKIX validation is not tested for certificate usage 3. The Certificate Usage that seems appropriate are the ones specifying it should do "full PKIX validation" (usage 1 or 2, not 3), which would include the EKU's to know whether the certificate is good for signing or encrypting. > 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> What does an SMIMEA DNS record signify? I thought it meant "you can verify signatures on received email" and "you can send encrypted email using this encryption key". I do not think it can mean "this user is allowed to accept encrypted email". Whether or not to encrypt is a local policy of the sender. If and only if the sender wants to encrypt it, it will look for the appropriate encryption key. I would envision an organisation to either allow individual encryption keys, or a global encryption key. If you use a global encryption key, you might still want to have individual signatures of people within the organisation. So I can see that as a use case. That use case _could_ also be solved by having two keys: <user>._smimecert.example.com IN SMIMEA 2 0 1 <blob of local TA (or self) signed cert> <user>._smimecert.example.com IN SMIMEA 2 0 1 <blob of local TA (or self) signed cert> Where one has the signing EKU set and one has the encryption EKU set. This is much more straight forward and prevents situations where the EKU and the DNS _prefix disagree and eliminates a lot of corner cases. > The draft will have to have some text to specify when a client should not rely on the keyUsage field in the cert It should always rely on it for CU=1 and CU=2. And CU=3 should clearly not be used if there is domain policy covering an individual. >, and what to do if the field is not present in the cert at all. I would say PKIX validation determined an SMIME certificate without signing EKU cannot be used to verify signatures. An SMIME certificate without encryption EKU cannot be be used for sending encrypted email. (and if encryption is mandatory according to local policy, no email should be sent in the clear either) > 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. In my experience with X.509 and IKE and various EKU's and interop, many vendors come up with many different EKU's related to the policy of authentication and encryption. I'd really prefer not to see a zillion _prefixes and a new RFC whenever a vendor comes up with a new EKU. Paul (and yes, I have had to do interop tests by adding 20 non-RFC EKU's to see if a certain phone vendor would finally use the damn certificate for IKE)
- [dane] use case for naming convention in the DNS … Rose, Scott
- Re: [dane] use case for naming convention in the … Paul Wouters 🔓
- Re: [dane] use case for naming convention in the … Rose, Scott W.
- Re: [dane] use case for naming convention in the … Paul Hoffman
- Re: [dane] use case for naming convention in the … Viktor Dukhovni