Re: [pkix] [x500standard] Private key usage period extension

Stefan Santesson <stefan@aaa-sec.com> Fri, 06 May 2016 12:44 UTC

Return-Path: <stefan@aaa-sec.com>
X-Original-To: pkix@ietfa.amsl.com
Delivered-To: pkix@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1EEF912D186 for <pkix@ietfa.amsl.com>; Fri, 6 May 2016 05:44:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001] autolearn=ham autolearn_force=no
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 xa5EhF1cC2uS for <pkix@ietfa.amsl.com>; Fri, 6 May 2016 05:44:50 -0700 (PDT)
Received: from smtp.outgoing.loopia.se (smtp.outgoing.loopia.se [194.9.95.112]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EC2C012D16E for <pkix@ietf.org>; Fri, 6 May 2016 05:44:49 -0700 (PDT)
Received: from s554.loopia.se (localhost [127.0.0.1]) by s554.loopia.se (Postfix) with ESMTP id 79FB817005A8 for <pkix@ietf.org>; Fri, 6 May 2016 14:44:45 +0200 (CEST)
X-Loopia-Auth: user
X-Loopia-Originating-IP: 90.229.17.25
X-Loopia-User: stefan@fiddler.nu
Received: from s500.loopia.se (unknown [172.21.200.98]) by s554.loopia.se (Postfix) with ESMTP id 8F7EF947371; Fri, 6 May 2016 14:44:32 +0200 (CEST)
Received: from s405.loopia.se (unknown [172.21.200.105]) by s500.loopia.se (Postfix) with ESMTP id 8032BA9CA86; Fri, 6 May 2016 14:44:29 +0200 (CEST)
X-Virus-Scanned: amavisd-new at amavis.loopia.se
Received: from s500.loopia.se ([172.21.200.105]) by s405.loopia.se (s405.loopia.se [172.21.200.135]) (amavisd-new, port 10024) with LMTP id T-nrdzgG90gV; Fri, 6 May 2016 14:44:28 +0200 (CEST)
Received: from [10.0.1.51] (unknown [90.229.17.25]) (Authenticated sender: stefan@fiddler.nu) by s500.loopia.se (Postfix) with ESMTPSA id D9CB9A9CA09; Fri, 6 May 2016 14:44:28 +0200 (CEST)
User-Agent: Microsoft-MacOutlook/f.15.1.160411
Date: Fri, 06 May 2016 14:44:27 +0200
From: Stefan Santesson <stefan@aaa-sec.com>
To: <x500standard@freelists.org>, PKIX <pkix@ietf.org>
Message-Id: <4DF9B5CF-874E-4030-AA0A-AA5C12488D11@aaa-sec.com>
Thread-Topic: [x500standard] Private key usage period extension
References: <000901d1a773$379e1680$a6da4380$@x500.eu>
In-Reply-To: <000901d1a773$379e1680$a6da4380$@x500.eu>
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="B_3545390668_854830121"
Archived-At: <http://mailarchive.ietf.org/arch/msg/pkix/-wZ1BiRiLDvQn6MMT3JSgkaYQDg>
Subject: Re: [pkix] [x500standard] Private key usage period extension
X-BeenThere: pkix@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
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: Fri, 06 May 2016 12:44:54 -0000

I think so Erik,

However, to me this belongs with the fuzzy parts of X.509 that would not be designed this way, had the standard been written with the knowledge and experience we have today.
So to me this is a part of X.509 that has little or no value (and not really worth fixing).

Having said that, a private key can have a usage period that extends the certificate, which is a quite common case when certificates are renewed.

At Microsoft, at the time I worked there, we came up with a potential use case  for this extension for CA:s when re-issuing a cert based on an existing cert.
In this use-case the re-issued cert could only be re-issued if not contradicted by the private key usage period extension in the old cert, if present, So in this case the private key usage period had to extend the old cert cert and be honoured in the new cert.
This way you could for example issue a 1 year cert with a 5 year private key validity and make sure It was not renewed forever using the same key.
I think it was actually implemented in the CA but I doubt it was ever used in practice.

/Stefan


From:  <x500standard-bounce@freelists.org> on behalf of Erik Andersen <era@x500.eu>
Reply-To:  <x500standard@freelists.org>
Date:  Friday 6 May 2016 at 10:42
To:  Directory list <x500standard@freelists.org>rg>, PKIX <pkix@ietf.org>
Subject:  [x500standard] Private key usage period extension

X.509 has a specification of the Private key usage period extension (8.2.2.5). This extension is a little confusing. It has notBefore and notAfter specification. However, the text says:

 

The notBefore component indicates the earliest date and time at which the private key could be used for signing. If the notBefore component is not present, then no information is provided as to when the period of valid use of the private key commences. The notAfter component indicates the latest date and time at which the private key could be used for signing. If the notAfter component is not present then no information is provided as to when the period of valid use of the private key concludes.

 

With a little ill will, this can be read as the private key validation period may extend beyond the validity of the public key. Note 1 adds to the confusing, as it says:

 

NOTE 1 – The period of valid use of the private key may be different from the certified validity of the public key as indicated by the certificate validity period. With digital signature keys, the usage period for the signing private key is typically shorter than that for the verifying public key.

 

It is the word “typical” that confuses me. It implies it could be different.

 

This extension was included in RFC 3280 with a heavy health warning. It was omitted from RFC 5280 (except for A.2).

 

In my mind, the validity of the private key should not spread outside the validity period of the certificate.

 

Have I misunderstood something?

 

Erik