Re: [pkix] Self-issued certificates

王文正 <> Tue, 21 July 2015 13:47 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id DE6351B2DC0 for <>; Tue, 21 Jul 2015 06:47:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 1.624
X-Spam-Level: *
X-Spam-Status: No, score=1.624 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_TW=1.335, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id gF00Nm-MwPOi for <>; Tue, 21 Jul 2015 06:47:23 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 7411F1B2E01 for <>; Tue, 21 Jul 2015 06:47:21 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256;; s=bill; c=relaxed/simple; q=dns/txt;; t=1437486440; x=1440078440; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type: content-transfer-encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=HxMXRL3KMgyGDXxhd8TNJbtYbNZRhdwsakCtfRG+aKo=; b=mrVYD2JApymsnUKnFqF7fzxeygVm15q4QWBLrPGd1Q0lfOpvLhLz6PHLvtJKxGPr Q4nPDZvzsUQCEZqvonTD5NfbZZ84zZWBzoq0jI8I0gBdQGK2WI17qaRrtMkupGH0 Xd613c6Tu7zZUp4aSWI0WdQBVStdgdvFvq4d5sT6sZk=;
X-AuditID: 0aa00766-f798c6d000002b61-b0-55ae4d68d9ff
Received: from ( []) by (CHT Outgoing ESMTP Mail Server) with SMTP id DA.0F.11105.86D4EA55; Tue, 21 Jul 2015 21:47:20 +0800 (CST)
Received: from (unknown []) by (Symantec Mail Security) with ESMTP id 15111C000088 for <>; Tue, 21 Jul 2015 21:47:20 +0800 (CST)
Received: from ([fe80::3178:69dd:b794:fa86]) by ([fe80::51e1:3e0d:a18c:1a89%12]) with mapi id 14.02.0342.003; Tue, 21 Jul 2015 21:47:19 +0800
From: =?utf-8?B?546L5paH5q2j?= <>
To: PKIX <>
Thread-Topic: [pkix] Self-issued certificates
Thread-Index: AQHQvO6GAYPrVwbgc064vRlSWTnR1Z3YHn2AgAEqVND//8o1gIABb2ZwgACfJkf//8FjAIABpRXAgABR9cr//4HAgAAo4+OAAAEW84AAAiRdgAABHo0AADyYzOD//6JUgP/5T3NA
Date: Tue, 21 Jul 2015 13:47:18 +0000
Message-ID: <>
References: <> <> <> <>
In-Reply-To: <>
Accept-Language: zh-TW, en-US
Content-Language: zh-TW
x-originating-ip: []
Content-Type: text/plain; charset="utf-8"
content-transfer-encoding: base64
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrOKsWRmVeSWpSXmKPExsXCtYA9WzfDd12oQccpLouLB4scGD2WLPnJ FMAYVW+TmJeXX5JYkqqQklqcbKuUnFGim5JZnJyTmJmbWqRbWpJmoaSQmWKrZKakUJCTmJya m5pXYquUWFCQmpeiZMelgAFsgMoy8xRS85LzUzLz0m2VQkPcdC2U7J7NWfNk/8Inu7c97V// onnv057WpxNWJ6yRz5jX85mx4JlkxYuJ31gaGCdIdjFyckgImEgceXuZEcIWk7hwbz1bFyMX h5DAdkaJfxuWsEM4ZxkltjXvgHIOM0r82nuLDaSFTcBIYuPZXUwgtoiAhMSG18/BbGEBHYlb d/ZDxXUlLj37DjZWRGAao8TfWYvB9rEIqErs2boSqIiDg1fAX2L7izKIBa1MEg3Xp4LVcApE S9ycPB9sGaOArMSTBc/AhjILiEucu9jKDnG3gMSSPeeZIWxRiZeP/7GCzJQQkJeY9kYGxGQW 0JRYv0sfolNRYkr3Q7BOXgFBiZMzn7BMYBSbhWToLISOWUg6ZiHpWMDIsopRsDg5Mc/QSA8Y l3rJ+bl6JeWbGCHJIG0H4/b5jocYBTgYlXh4GaTXhgqxJpYVV+YeYpTgYFYS4f1ivy5UiDcl sbIqtSg/vqg0J7X4EGMyMEgmMkuJJucDE1VeSbyhsaWxibmxuYGRoYEhacJK4rzTWzNDhATS gUkuOzW1ILUIZgsTB6dUA+OC3IzPndOM96dEa8+K33ugJ/6C7NIV7pwGmw8tVF7ZrpZa/MTj 52OFNJ1DOw49qSs+fCmuetLR+cqnWbJXJzPGtUysdNmgkDt5a05Pssn/rOfXuT8ynV43MTVB 8tmVbyHFh01a5J9NSK0ru8T6PbSfQ6jX03lfk7JtX6HBvhiXgil1qncq1JRYijMSDbWYi4oT AUAUKaFKAwAA
Archived-At: <>
Subject: Re: [pkix] Self-issued certificates
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: PKIX Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 21 Jul 2015 13:47:26 -0000

> While rolling over a self-signed certificate while preserving trust is an interesting problem (to me, anyway, 'cause I'm a fan of key continuity management ;) in general practice your example chain should never occur in TLS/SSL.  Rollover messages are certificate management messages; new-with-old and old-with-new are management artifacts and not intended for path construction.
> I.e., if in your example:
> - Root rollover is due to pending or past root key expiration, then the "old-root" trust anchor is replaced by "new-root;" the chain terminates at "new-root" and new-with-old doesn't appear.

You are right, if the new root cert (new-with-new self-signed cert) has been distributed to relying parties, then the relying parties can directly use the new root cert as the trust anchor and therefore they do not need to build the certification path with the help of the new-with-old self-issued cert anymore. In the situations where relying parties already has the new root cert in their lists of trust anchors, the certification path will be as follows:

new root cert --> intermediate CA cert --> TLS/SSL cert

However, most relying parties rely on COTS such as browsers or operating systems to update their lists of trust anchors. After a root CA performed its key rollover, it will submit its new root cert to "Root Certificate Programs" of all mainstream browsers or operating systems. It might take server months or even more than half year before the new root cert is accepted by "Root Certificate Programs" of all mainstream browsers or operating systems. Before the new root cert is added to the lists of trust anchors of all mainstream browsers and operating systems, TLS/SSL servers would temporarily rely on the new-with-old certificate to assist relying parties to chain the certification path up to the old root cert (i.e., the old trust anchor).

> - Root rollover is due to root key compromise, new-with-old can't be trusted, "old-root" trust anchor must be removed, and the chain is invalid.

Yes, if the old root key was compromised, then both new-with-old and old-with-new are useless. In that situation, the root CA has to generate a new key pair and distribute the new root cert to relying parties as soon as possible. However, if a root CA of which root key had ever been compromised, I doubt that relying parties will trust the CA again.

Wen-Cheng Wang

Please be advised that this email message (including any attachments) contains confidential information and may be legally privileged. If you are not the intended recipient, please destroy this message and all attachments from your system and do not further collect, process, or use them. Chunghwa Telecom and all its subsidiaries and associated companies shall not be liable for the improper or incomplete transmission of the information contained in this email nor for any delay in its receipt or damage to your system. If you are the intended recipient, please protect the confidential and/or personal information contained in this email with due care. Any unauthorized use, disclosure or distribution of this message in whole or in part is strictly prohibited.  Also, please self-inspect attachments and hyperlinks contained in this email to ensure the information security and to protect personal information.