Re: [pkix] Self-issued certificates

mrex@sap.com (Martin Rex) Tue, 14 July 2015 20:13 UTC

Return-Path: <mrex@sap.com>
X-Original-To: pkix@ietfa.amsl.com
Delivered-To: pkix@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E0751B2C31 for <pkix@ietfa.amsl.com>; Tue, 14 Jul 2015 13:13:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.551
X-Spam-Level:
X-Spam-Status: No, score=-6.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-5, 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 3sda00atVf8K for <pkix@ietfa.amsl.com>; Tue, 14 Jul 2015 13:12:56 -0700 (PDT)
Received: from smtpde02.smtp.sap-ag.de (smtpde02.smtp.sap-ag.de [155.56.68.140]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 511401B2C27 for <pkix@ietf.org>; Tue, 14 Jul 2015 13:12:56 -0700 (PDT)
Received: from mail05.wdf.sap.corp (mail05.sap.corp [194.39.131.55]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtpde02.smtp.sap-ag.de (Postfix) with ESMTPS id 570FE45B67; Tue, 14 Jul 2015 22:12:54 +0200 (CEST)
X-purgate-ID: 152705::1436904774-0000413A-63BF963A/0/0
X-purgate-size: 2942
X-purgate: clean
X-purgate: This mail is considered clean (visit http://www.eleven.de for further information)
X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de
X-purgate-type: clean
X-SAP-SPAM-Status: clean
Received: from ld9781.wdf.sap.corp (ld9781.wdf.sap.corp [10.21.82.193]) by mail05.wdf.sap.corp (Postfix) with ESMTP id 48065406F5; Tue, 14 Jul 2015 22:12:54 +0200 (CEST)
Received: by ld9781.wdf.sap.corp (Postfix, from userid 10159) id 42B171A1DE; Tue, 14 Jul 2015 22:12:54 +0200 (CEST)
In-Reply-To: <20825998BCB8D84C983674C159E25E753D621BA2@mbs6.app.corp.cht.com.tw>
To: =?ISO-2022-JP?Q?=1B=24=28B=0F2=26J8=405=1B=28B?= <wcwang@cht.com.tw>
Date: Tue, 14 Jul 2015 22:12:54 +0200 (CEST)
X-Mailer: ELM [version 2.4ME+ PL125 (25)]
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="US-ASCII"
Message-Id: <20150714201254.42B171A1DE@ld9781.wdf.sap.corp>
From: mrex@sap.com (Martin Rex)
Archived-At: <http://mailarchive.ietf.org/arch/msg/pkix/ViV-GOFyc9CGzAGUBU4cvGubTnw>
Cc: PKIX <pkix@ietf.org>
Subject: Re: [pkix] Self-issued certificates
X-BeenThere: pkix@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: mrex@sap.com
List-Id: PKIX Working Group <pkix.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/pkix>, <mailto:pkix-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/pkix/>
List-Post: <mailto:pkix@ietf.org>
List-Help: <mailto:pkix-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pkix>, <mailto:pkix-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 14 Jul 2015 20:13:05 -0000

> 
> However, since "key rollover with self-issued certificates" is the
> standard method suggested by X.509 and PKIX, your simile seems to
> implies both X.509 and PKIX are violating the 1997 UN convention.
> Do you really mean that? :)

The originaly idea in X.509 predates the UN convention, so it's only
current consumers that are making use of this half-baked misfeature
that are violatin the UN convention.


> 
> I believe the philosophy of X.509 (or the whole X.500 series) is that
> a Distinguished Name (DN) represents the identity of an entity.
> Therefore, if the DN is changed, it means the identity of that entity
> has been changed. With this philosophy, the DN of each entity should
> not be changed unless its identity is changed.

The last sentence is a non-sequitur.


>
> Especially, a root CA is the trust anchor, which should not change
> its DN between generations of CA keys, otherwise relying parties
> will be confused about whether they are the same root CA entity.

It's extremely difficult to believe that anyone could get confused
about the entity/entities represented by name that simply include
generation identifiers to avoid self-issued problems.

  "CN=VeriSign Class 3 Public Primary Certification Authority - G3, ..."
  "CN=VeriSign Class 3 Public Primary Certification Authority - G5, ..."

Distinguished names contain semantic structure on purpose.  Use whatever
RDName component you like to avoid the troubles and complexitis of
self-issued certificates.

For root CA certs, the distinguished name regularly does not describe
the true entity that operates the CA anyway, because many of them change
ownership once or more often while they're in use.  

  e.g.  RSA->VeriSign->Symantec


The fashion in which the processing of self-issued certificates is specified
actually _creates_ a security problem.  Normally, one might assume that using
a path len constraint of 0 in the certificate of an online CA would preclude
that an attacker who manages to briefly obtain control over a CA key to
issue himself a CA cert.  The official processing rules for self-issued
certs subverts that assumed protection -- the attacker can sign himself
a self-issued CA cert and use that to screw all RPs that process cert
chains in the fashion that X.509 / PKIX specifies.

>From the perspective of risk management, not supporting self-issued
certificates is IMHO a very resonable decision.

For CAs to do rollover with Generation identifiers in DNames
is a no-brainer.  It will also facilitate recognizing and
telling apart the CA certificates -- for RPs that start with an
empty trust store rather than a trust store prepopulated
with hundreds of omnipotent CAs -- or a dynamic trust store
such as that of newer Versions of Microsoft Windows, where you
essentially have no control over the trust anchors any more and
no idea who is trusted.


-Martin