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

Viktor Dukhovni <> Sat, 06 December 2014 05:17 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 720B91A8AC1 for <>; Fri, 5 Dec 2014 21:17:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id mhFR4kGp2NGB for <>; Fri, 5 Dec 2014 21:16:59 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 38E751A8AC3 for <>; Fri, 5 Dec 2014 21:16:58 -0800 (PST)
Received: by (Postfix, from userid 1034) id A6247282FBF; Sat, 6 Dec 2014 05:16:57 +0000 (UTC)
Date: Sat, 6 Dec 2014 05:16:57 +0000
From: Viktor Dukhovni <>
Message-ID: <>
References: <> <>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <>
User-Agent: Mutt/1.5.23 (2014-03-12)
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: Sat, 06 Dec 2014 05:17:01 -0000

On Thu, Dec 04, 2014 at 12:06:37PM -0500, Paul Wouters ? 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.

Though we should keep in mind that the OPS draft updates 6698 to
specify that usage 3 ignores expiration and name checks:

but, this says nothing about ignoring keyUsage.  Also we've (as
the DANE WG) have not yet discussed to what extent the OPS draft
updates apply only to DANE TLSA, or to all DANE documents that use
compatible RRDATA formats.

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

I expect DANE-TA(2) to be a fairly popular certificate usage for
enterprises that want to publish signature only keys, but per the
interim meeting, enterprise certs don't always signal the constraints,
so some additional out of band (not in the certificate) signalling
may in fact be required.

I should also point that when the DANE TLSA RRset for a mailbox
publishes only trust anchors (usage 0 or 2), and/or only digests
of EE keys, the association is at first blush a signature only
association.  This is because for first contact, the user's actual
public key remains unknown and must be obtained by other means.

Only "TLSA [13] ? 0" records provide usable end-entity key material.
And perhaps for SMIME even bare keys are not enough, IIRC one may
need access to the full recipient certificate to construct an SMIME
encrypted message and thus only "TLSA [13] 0 0" are sufficient for
(initial encryption).

So we potentially have the opportunity to declare that anything
other than "1 0 0" or "3 0 0" is a signature-only association, even
after the key is obtained out of band.  This idea may be a dead-end,
but perhaps it is worth mentioning.

> > A variant 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.

Wildcards records are not merged with more specific data published
for the specific "owner name" requested in a query.  Therefore,
one cannot publish a wildcard "CU=2" and also "CU=3" per user,
and have the wildcard apply to all the users.

In any case the CU=3 comment seems to be a misconception.  Just as
in TLS the handshake chain needs to include the TA cert with all
other intermediates even if the TA is self-signed, similarly with
SMIME, the TA will need to be included in the PKCS7 S/MIME message,
along any intermediates and the leaf cert.  Therefore signed SMIME
messages can be verified based on an SMIMEA CU=2 association alone.

> > In a way, the encryption certs could be
> > viewed 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>

Which would completely hide the wildcard, so that in fact one would

    <user>  SMIMEA 2 0 1 <digest of TA>
    <user>  SMIMEA 3 0 0 <encryption cert>

which lines up with my observation a paragraph or two back.  Only
"3 0 0" or "1 0 0" yields usable encryption material, and we could
choose to say so.  Obviating the need for the "_sign" and "_encr"

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

Perhaps this is too rigid.  There are advantages to "3 0 0"
associations, and because they fully specify the certificate content,
they can signal EKU just like all the other usages can.  Though I
think that perhaps a good case was made for not expecting EKU to
be suitably set in all cases and a likely need for additional signals.