Re: [dane] DANE Client Authentication draft updated

Shumon Huque <> Tue, 12 January 2016 22:21 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 78B9E1A8AC2 for <>; Tue, 12 Jan 2016 14:21:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 58N9cI7CGppS for <>; Tue, 12 Jan 2016 14:21:45 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:400d:c09::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 9414B1A8A3D for <>; Tue, 12 Jan 2016 14:21:45 -0800 (PST)
Received: by with SMTP id p186so181944205qke.0 for <>; Tue, 12 Jan 2016 14:21:45 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=knHlwp00O+kRpc3PnKbIHtG1Yp9JrEL5tNjfYsFGkWU=; b=w4MkPqk4w/UiGaIhXttGv3bDiuC3PMiTCDNrXWD8E19tjjZ8QSe68msElpHJCKXMnW hMmnPeT8YS+mQoH93ufIHupwmS30ObN7UkKYq+dJ7xA52/p2xqLbXDdGq20FX2evfv/c FLA4+li+/eSy8i6ECMw9Hs9xdQUk8hli+FkkDxEIpZnj5hAionmbk0yeFXM1UAtlWwq6 gJ08n8ycF8msupLhvV4FBaWkuamAFYVjscJY7PKxTHRKv4LWDQhtEomOB5KkjUFhRVQn 44L6vRYR3ToLw1Si/GB2Uul41CnuXm9L1h3vos1rF+Mz+Wo8wHEbCrva41yJPaJb339l CXmQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=knHlwp00O+kRpc3PnKbIHtG1Yp9JrEL5tNjfYsFGkWU=; b=QTNc9pjpqfB3di41Mdvn52Qu2oA772O5a1kFBEqs/RszEIe8YYGJ2Hg+Yon/yKKsLj E6qAyQerOfMsrerhha5j7GKjMus+dxSQP+kwagOU8kTQpobStIZTQpHK3QdCOAuh6oVF QAh4vf2UOBfsUjd6xiuUDkoxLlMM58jBZkxm40Wg6t1lFAG5Xa4NXpyjlo3VNebaMz2L ZYG6pLW+xFVON2m3UbhJ7Lv27R1bOP5KI6FRk/GatO6YoXVWGTsEnVgdatvVMnmo77V5 D+YR1CyzQZSkNXKyPR4/khRUagYP71Li5+99qwxRiPi/AEg3EkedFmpRrhxD+hRZ7IKa mcVQ==
X-Gm-Message-State: ALoCoQmwbwuRjk3Hrd5NrYF1DRbDgITlUwDctB9not5iVs7pMZKYeyURgLDJoC/2M9Scnknvvqh3VknQQ59EgMeENVgIdmJtxw==
MIME-Version: 1.0
X-Received: by with SMTP id w66mr172430331qka.39.1452637304801; Tue, 12 Jan 2016 14:21:44 -0800 (PST)
Received: by with HTTP; Tue, 12 Jan 2016 14:21:44 -0800 (PST)
In-Reply-To: <>
References: <> <>
Date: Tue, 12 Jan 2016 17:21:44 -0500
Message-ID: <>
From: Shumon Huque <>
To: James Cloos <>
Content-Type: multipart/alternative; boundary=001a114a8dc08a6eb105292a7ac4
Archived-At: <>
Cc: "<>" <>
Subject: Re: [dane] DANE Client Authentication draft updated
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: Tue, 12 Jan 2016 22:21:47 -0000

On Tue, Jan 12, 2016 at 3:05 PM, James Cloos <> wrote:

> For draft-huque-dane-client-cert I'd still prefer RR names like:
>  _smtp._client.example
> for the cert provided by an smtp client which HELO/EHLOs as example.
> And similarly for other protocols.  Rather than things like _smtp-client.
> Putting all of the client TLSAs under a single label allows (but
> obviously does not require) them to be in their own zone.

Thanks for the feedback. I had the _service._client form in an earlier
version of this draft but Viktor talked me out of it, on the grounds of
insufficient usefulness and unneeded complexity. I'd be interested in
hearing other opinions on this point also.

On the "_smtp-client" label choice, I had originally used just "_smtp", but
a colleague more plugged into IANA service name registration procedures
advised me that I should choose a different client specific label. The
"_smtp" label is a server side label with an associated server side port,
and that reusing that label for a client identifier would elicit objections.

Than can be useful.
> And in the case where the proposed tls extension is not used, it should
> be OK for the name to be in CN, too.  So something like 'MUST be in
> either dnsName or CN, but SHOULD be in the dnsName'.

Current IETF specs strongly discourage putting domain name identifiers
in the subject CN (see RFC6125 for example), which I agree with, and
whose lead I followed. I suspect that DANE client certificates is enough
of a green field application, that there aren't backwards compatibility
concerns that would prove to be impediment here. Even if you were using
public CAs, practically all of them today can issue domain names in
dNSName. SRVName unfortunately is a real world impediment for some
parties, which is why that one isn't a MUST.

What specific concerns did you have in mind with disallowing CN?

Shumon Huque