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

Stephen Kent <kent@bbn.com> Mon, 20 January 2014 14:51 UTC

Return-Path: <kent@bbn.com>
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 E40BC1A018B for <dane@ietfa.amsl.com>; Mon, 20 Jan 2014 06:51:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.036
X-Spam-Level:
X-Spam-Status: No, score=-2.036 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001] 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 esOpH6r_Mw3D for <dane@ietfa.amsl.com>; Mon, 20 Jan 2014 06:51:05 -0800 (PST)
Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id 47C2E1A0186 for <dane@ietf.org>; Mon, 20 Jan 2014 06:51:05 -0800 (PST)
Received: from dhcp89-089-218.bbn.com ([128.89.89.218]:54454) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from <kent@bbn.com>) id 1W5GBt-000Nu1-Cn for dane@ietf.org; Mon, 20 Jan 2014 09:51:05 -0500
Message-ID: <52DD37DB.5050309@bbn.com>
Date: Mon, 20 Jan 2014 09:51:07 -0500
From: Stephen Kent <kent@bbn.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.2.0
MIME-Version: 1.0
To: dane@ietf.org
References: <20140116151959.4AA021ABB0@ld9781.wdf.sap.corp> <52D80CC4.9020407@bbn.com> <20140117065942.GY2317@mournblade.imrryr.org>
In-Reply-To: <20140117065942.GY2317@mournblade.imrryr.org>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [dane] "Name Checks are not appropriate for CU=3"
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: Mon, 20 Jan 2014 14:51:07 -0000

Viktor,

> On Thu, Jan 16, 2014 at 11:45:56AM -0500, Stephen Kent wrote:
>
>> Martin is correct. This is not well-formed cert as per RFC 5280:
>>
>> 4.1.2.4.Issuer
>> The issuer field identifies the entity that has signed and issued the
>> certificate.The issuer field MUST contain a non-empty distinguished
>> name (DN)
>>
>> [...]
>>
>> We issued 5280bis in part to accommodate DANE's use of ss certs.
>> Please don't provide examples that are obviously non-complaint relative
>> to basic PKIX and X.509 specs.
> Are you referring to RFC 6818?  If so, what is the impact of Section
> 2 of that document?
>
>      2.  Update to RFC 5280, Section 3.2: "Certification Paths and Trust"
>
>         Add the following paragraph to the end of RFC 5280, Section 3.2:
>
>      | Consistent with Section 3.4.61 of X.509 (11/2008) [X.509], we note
>      | that use of self-issued certificates and self-signed certificates
>      | issued by entities other than CAs are outside the scope of this
>      | specification.  Thus, for example, a web server or client might
>      | generate a self-signed certificate to identify itself.  These
>      | certificates and how a relying party uses them to authenticate
>      | asserted identities are both outside the scope of RFC 5280.
>
> If a self-signed EE (i.e. not a CA) certificate is outside the
> scope of 5280, it might seem that the issuer constraint of 5280
> need not apply.
The wording here was a carefully crafted compromise to deal with the
reality of ss certs vs. the X.509 and 5280 rejection of them. You could
interpret the text to say that anything goes, but violating the basic
format requirements of 5280 and its predecessors) and X.509 strikes me
as a bad mashup.
> This does not mean that it is a good idea to push one's luck, but
> I am curious as to whether the 5280 constraints in this thread are
> or are not in scope for self-signed EE certificates?
>
> It is perhaps the case that the question of whether a certificate
> is self-issued or not is not well-formed when both the issuer and
> subject fields are empty?
Self-issued is not the same same self signed, although the fine
distinction is probably not worth the list's attention.

Steve