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

Viktor Dukhovni <> Fri, 17 January 2014 06:59 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id DB2111ADF96 for <>; Thu, 16 Jan 2014 22:59:57 -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 Ijf2pVhuYwbF for <>; Thu, 16 Jan 2014 22:59:56 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id E0E9B1ADF93 for <>; Thu, 16 Jan 2014 22:59:55 -0800 (PST)
Received: by (Postfix, from userid 1034) id A9DFE2AABCE; Fri, 17 Jan 2014 06:59:42 +0000 (UTC)
Date: Fri, 17 Jan 2014 06:59:42 +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.21 (2010-09-15)
Subject: Re: [dane] "Name Checks are not appropriate for CU=3"
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, 17 Jan 2014 06:59:58 -0000

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

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?