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, 4 Dec 2014 12:06:37 -0500 (EST)
From: =?UTF-8?Q?Paul_Wouters_=F0=9F=94=93?= <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)