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

Stefan Santesson <> Fri, 06 May 2016 13:10 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 8CAF812D51D for <>; Fri, 6 May 2016 06:10:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.599
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 4njWpYYA2GLA for <>; Fri, 6 May 2016 06:10:28 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id BB30512D5F3 for <>; Fri, 6 May 2016 06:10:27 -0700 (PDT)
Received: from (localhost []) by (Postfix) with ESMTP id 92566170196C for <>; Fri, 6 May 2016 15:10:25 +0200 (CEST)
X-Loopia-Auth: user
Received: from (unknown []) by (Postfix) with ESMTP id 75B7A94709A; Fri, 6 May 2016 15:10:25 +0200 (CEST)
Received: from (unknown []) by (Postfix) with ESMTP id 6F7D0461A24; Fri, 6 May 2016 15:10:25 +0200 (CEST)
X-Virus-Scanned: amavisd-new at
Received: from ([]) by ( []) (amavisd-new, port 10024) with LMTP id hOd6Vf8A-3l2; Fri, 6 May 2016 15:10:24 +0200 (CEST)
Received: from [] (unknown []) (Authenticated sender: by (Postfix) with ESMTPSA id A8A3613634E8; Fri, 6 May 2016 15:10:24 +0200 (CEST)
User-Agent: Microsoft-MacOutlook/f.15.1.160411
Date: Fri, 06 May 2016 15:10:23 +0200
From: Stefan Santesson <>
To: <>, PKIX <>
Message-Id: <>
Thread-Topic: [x500standard] SV: [pkix] Private key usage period extension
References: <000901d1a773$379e1680$a6da4380$> <> <> <005501d1a792$626cdb20$27469160$>
In-Reply-To: <005501d1a792$626cdb20$27469160$>
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="B_3545392224_1385492806"
Archived-At: <>
Subject: Re: [pkix] [x500standard] SV: Private key usage period extension
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: PKIX Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 06 May 2016 13:10:31 -0000

In line;

From:  <> on behalf of Erik Andersen <>
OK, it is being used. I have seen no reason so far that the private key use period starts before and/or ends after the certificates validity period.


I just posed one.
Actually I would rather see this period extend the certificate than being shorter than the certificate.

Having it longer than the certificate will not impact validation (see below). Having it shorter may cause confusion and potentially security issues.
Having a shorter private key period may create expectations that a verifier will honor this period fail validation if a signature was created outside of this period.
I doubt that there are many signature validation applications that actually would process this extension if present. Resulting in false positive validation result.

If I get a message together with a certificate and the message is signed after the certificate validity period, but before the notAfter for the private key usage period, what do I do? Consider the certificate invalid and discard the message

Yes, because you don’t have a valid certificate for this signature.

 or do I validate the signature with the public key I am not supposed to use anymore.

No. As the certificate is not valid, you stop there. No information in a certificate that is not valid is of any interest to you.


It is of no help to me that there may be another certificates with the same key pair, where the certificate validity period is different. I might not know those certificates.

Exactly. If you don’t have a valid certificate. You fail.






Fra: Erwann Abalea [] 

This extension is heavily used in electronic passports.

ICAO has set it to be mandatory for Root CA and Document Signer certificates (subscriber certs used to verify data in passports), and optional for MasterList signers.

It is typical that closed community applications can make use of odd extensions in a successful manner as they are governed by extended specifications and profiles.


This extension was already deprecated in RFC2459.



2016-05-06 11:53 GMT+02:00 Stephen Farrell <>ie>:

Hi Erik,

I've a separate question: does anyone use this extension
or should we put it on a virtual/mental list of stuff to
be deprecated when/if someone has the energy?


On 06/05/16 09:42, Erik Andersen wrote:
> X.509 has a specification of the Private key usage period extension
> ( 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?