Re: [dane] "Name Checks are not appropriate for CU=3"

Viktor Dukhovni <viktor1dane@dukhovni.org> Fri, 17 January 2014 06:26 UTC

Return-Path: <viktor1dane@dukhovni.org>
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 C3F191ADF85 for <dane@ietfa.amsl.com>; Thu, 16 Jan 2014 22:26:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
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 XF7nG3q9AD4L for <dane@ietfa.amsl.com>; Thu, 16 Jan 2014 22:26:15 -0800 (PST)
Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) by ietfa.amsl.com (Postfix) with ESMTP id 2E1C81ADF83 for <dane@ietf.org>; Thu, 16 Jan 2014 22:26:15 -0800 (PST)
Received: by mournblade.imrryr.org (Postfix, from userid 1034) id C7F332AABCE; Fri, 17 Jan 2014 06:26:01 +0000 (UTC)
Date: Fri, 17 Jan 2014 06:26:01 +0000
From: Viktor Dukhovni <viktor1dane@dukhovni.org>
To: dane@ietf.org
Message-ID: <20140117062601.GX2317@mournblade.imrryr.org>
References: <20140116151959.4AA021ABB0@ld9781.wdf.sap.corp> <52D80CC4.9020407@bbn.com> <52D81875.6050705@nist.gov> <20140116180810.GN2317@mournblade.imrryr.org>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <20140116180810.GN2317@mournblade.imrryr.org>
User-Agent: Mutt/1.5.21 (2010-09-15)
Subject: Re: [dane] "Name Checks are not appropriate for CU=3"
X-BeenThere: dane@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: dane@ietf.org
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: Fri, 17 Jan 2014 06:26:18 -0000

On Thu, Jan 16, 2014 at 06:08:10PM +0000, Viktor Dukhovni wrote:

> I'll strive to avoid publishing examples that are likely to fail
> interoperability tests.  For what it is worth, OpenSSL does not
> mind empty subject and issuer DNs even without a SAN extension, if
> the application layer does not object.  The DANE verification code
> I wrote on top of OpenSSL likewise does not object with usage
> DANE-EE(3).

My updated code for essentially anonymous self-signed certificates
now generates certificates with subject and issuer set to "CN=*",
in the hope that this will encounter less friction from strict
parsers.  The extra 24 useless octets in the DER encoding of the
certificate are not prohibitive:

issuer= /CN=*
notBefore=Jan 17 05:29:38 2014 GMT
notAfter=Jan 16 05:29:38 2014 GMT
subject= /CN=*
-----BEGIN CERTIFICATE-----
MIIBBTCBq6ADAgECAgEBMAoGCCqGSM49BAMCMAwxCjAIBgNVBAMMASowHhcNMTQw
MTE3MDUyOTM4WhcNMTQwMTE2MDUyOTM4WjAMMQowCAYDVQQDDAEqMFkwEwYHKoZI
zj0CAQYIKoZIzj0DAQcDQgAEa3wTPD7Pnc0r5Jq5pwWVtOJMpDOGjfhPe3Ger2hr
r9XTMJt8gKo+qPbvokID/sqEmqf1cwh/VJtdiEaEw8f2uDAKBggqhkjOPQQDAgNJ
ADBGAiEAjTtBubyqCqIoOFArwZ/imA483U4+zSKZEgEFMTqqS9MCIQClkwwlavTu
mjagje1TSlDYuScRRstmZc9wp2bsmA1Ljg==
-----END CERTIFICATE-----

Yes I know that one can't yet field only an EC certificate even
for SMTP.  Many pre-DANE opportunistic TLS clients will have older
TLS implementations that don't support EC, but insist on a compatible
(i.e. RSA with SHA1) certificate which they promptly ignore.  The
requisite RSA-2048 certificate is ~400 octets longer:

issuer= /CN=*
notBefore=Jan 17 06:18:09 2014 GMT
notAfter=Jan 16 06:18:09 2014 GMT
subject= /CN=*
-----BEGIN CERTIFICATE-----
MIICkTCCAXmgAwIBAgIBATANBgkqhkiG9w0BAQUFADAMMQowCAYDVQQDDAEqMB4X
DTE0MDExNzA2MTgwOVoXDTE0MDExNjA2MTgwOVowDDEKMAgGA1UEAwwBKjCCASIw
DQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAM60J1M9a5M8SB5kGvWuWSHgI9GV
lcUmufkjhBnN7lUSEgCKjIPWolnH/4JhoIrmMyqtbLAXEbkt64LcvVE2QQxY625S
/om7JJTb/VO3OmY/ae8hWWtgkaBlprg5YDHSGPdCdMLqKb1cjyUYbWzjHZ/vXDGF
tWhA/oW1tEBOVXDvyNJITF22epk3U6SORqOCkKixWQ4W/yKc4wH1ybFtfpdZxPPy
rx+0arWHaw5fbf82D3f55Ox9f+a7AZDKkce32ONqEruGhyTG6m6DHlbzdiiEc6xc
Fklomr8xn+jyf/jyi5YpzylFPBZiF11GVHPMYIUEFscnbLXyvKA88Ud3h9cCAwEA
ATANBgkqhkiG9w0BAQUFAAOCAQEAVu8qwguTCyMQ2rIYVZQvQTY+XYJZxUkwI2RS
4RfTqyJVina9Bi+o2iueWA5dTAqthWMpt0n4XVCuZlrcg82ZP5sJYwIs2FUX9Syk
gRFMG3TtHfrRoFrxylD+qjNdb74vZb1JtLSo4eqnEFUUMpYm3YvocoCkuJJrfsyF
TD2Tjj9Kv/rYMiRUFUU/NwK1+i49OI70L+Lr5nOwE/jxSjLpHUzsdhPGt4Rw7cNs
Eo5yX33tSShARTGFHW8SHZicMBQjbOTEVFslaCFv+qFH10n8W8PZ5romFbyqx9DD
VLlFSW+/4dXJDIFG8F27xWV3kl6Hi+zn49IoTHV7tWB2YtDXkg==
-----END CERTIFICATE-----

With DANE it will finally be practical to field multiple certificates,
one an with an RSA key, for clients that don't support ECDSA, and
another with an ECDSA key for those that do.  The TLSA RRset can
then list both digests.

-- 
	Viktor.