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

"Rose, Scott W." <> Fri, 05 December 2014 15:23 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id CACD31A899C for <>; Fri, 5 Dec 2014 07:23:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.21
X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id qU98rj_beQW8 for <>; Fri, 5 Dec 2014 07:23:03 -0800 (PST)
Received: from ( []) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 0B4281A89A8 for <>; Fri, 5 Dec 2014 07:23:03 -0800 (PST)
Received: from ( by ( with Microsoft SMTP Server (TLS) id; Fri, 5 Dec 2014 10:22:52 -0500
Received: from ( by ( with Microsoft SMTP Server (TLS) id 8.3.377.0; Fri, 5 Dec 2014 10:23:01 -0500
Received: from ( []) by (8.13.8/8.13.1) with ESMTP id sB5FMtdP016562 for <>; Fri, 5 Dec 2014 10:22:55 -0500
Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: "Rose, Scott W." <>
In-Reply-To: <>
Date: Fri, 5 Dec 2014 10:22:52 -0500
Content-Transfer-Encoding: quoted-printable
Message-ID: <>
References: <> <>
To: dane WG list <>
X-Mailer: Apple Mail (2.1878.6)
X-Mailman-Approved-At: Fri, 05 Dec 2014 09:34:49 -0800
Subject: Re: [dane] use case for naming convention in the DNS for sign/encrypt functionality
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: DNS-based Authentication of Named Entities <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 05 Dec 2014 15:23:09 -0000

On Dec 4, 2014, at 12:06 PM, Paul Wouters 🔓 <> wrote:

> On Thu, 4 Dec 2014, Rose, Scott wrote:
>> 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:
>> *  IN SMIMEA  2 0 1 <blob of local TA>
>> and for each user that is allowed to accept encrypted mail:
>> <user>  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.
It would be up to the org's policy about who can accept encrypted mail, and it wouldn't necessarily be signaled by DANE, just if a client discovers a cert that it can use to send encrypted mail, it could use it.  

> 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>  IN SMIMEA 2 0 1 <blob of local TA (or self) signed cert>
> <user>  IN SMIMEA 2 0 1 <blob of local TA (or self) signed cert>

True, I admit there are several ways to publish the RR's

> 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.
I was thinking this too, but it isn't in the explicit in the text right now.  The problem I see is when an org decides to use CU 3 and doesn't bother to include a keyUsage or EKU.   If that isn't the case and can be prevented with best common practices, then that is ideal.

>> , 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.
I wasn't aware of that - yes that is a problem and a good argument against having DANE signal/confuse things.  


> 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)

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