Subject: RE: 3280bis: Private Key Usage Period

From: "Stefan Santesson" <[email-masked]>
Date: Tue, 14 Feb 2006 17:57:06 -0000

IMO this is a confusing extension for which I don't believe there are
consistent implementations.

The only way we can include this in RFC 3280bis is if we can profile the
definition of X.509 in a useful manner.

The problem is that X.509 in its definition use a language of
enforcement while your text uses a language of guidance.

It is unclear to me whether X.509 considers a signature produced outside
of the usage period as valid, but one could argue that it is not.
However enforcing that validity period is complex and hard.

Unless there is a compelling use case, I believe that this is one of
those extensions that are simply out of scope for RFC 3280bis.

Implementers can still use it based on the X.509 definition.

Stefan Santesson
Program Manager, Standards Liaison
Windows Security

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Denis Pinkas
Sent: den 14 februari 2006 08:20
To: pkix
Subject: 3280bis: Private Key Usage Period

The text about the private key usage period has been deleted in 3280bis.

During the Paris IETF meeting (August 2005), I advocated the use of the
extension for HSMs.

I offer below some text, that can be placed in an annex or in the main
body of the document.

Denis

=============================================================

Private Key Usage Period

   The private key usage period extension allows the certificate issuer
   to specify a different validity period for the private key than the
   certificate.  This extension is intended for use with digital
   signature keys.  This extension consists of two optional components,
   notBefore and notAfter.  The private key associated with the
   certificate SHOULD NOT be used to sign objects before or after the
   times specified by the two components, respectively.  CAs conforming
   to this profile MUST NOT generate certificates with private key 
   usage period extensions unless at least one of the two components is
   present and the extension is non-critical.

   CAs conforming to this profile MUST NOT generate certificates that
   include a critical private key usage period extension.

   This extension MAY be used within the Internet PKI, when the 
   private key is protected by a Hardware Security Module (HSM) able 
   to parse the associated public key certificate.  In such a case, 
   the HSM MAY limit the use of the private key to the time period 
   indicated in that extension.

   This extension SHOULD NOT be used within the Internet PKI when 
   the private key usage is not enforceable.

   Where used, notBefore and notAfter are represented as 
   GeneralizedTime and MUST be specified and interpreted as defined 
   in section 4.1.2.5.2.

   id-ce-privateKeyUsagePeriod OBJECT IDENTIFIER ::=  { id-ce 16 }

   PrivateKeyUsagePeriod ::= SEQUENCE {
        notBefore       [0]     GeneralizedTime OPTIONAL,
        notAfter        [1]     GeneralizedTime OPTIONAL }

---

From: Peter Sylvester <[email-masked]>
Date: Tue, 14 Feb 2006 20:54:48 +0100

First, I don't have the current text of X509, only the 2000 version.

> consistent implementations.
I am not confused by the extension, although I have a general pb with X509
interpreting the word  could ".. could be used for signing"

On other occurences like 'Revocation date is,  which could be different 
from the
first time it appears in a CRL, seem to indicatae to me that it means 
"MAY happen that
it appears" thus  "the implementation MAY have a feature that inhibit 
that the key is used..".

At least I don't see any other consistent interpretation with the 
"could, shall, etc" in X509
compared with the MUST/MAY SHOULD NOT of the IETF.

> definition of X.509 in a useful manner.
In 3280 the profile is a strong and IMO  an unmotivated suggestion 
"don't use the extension"
And it was suggested in the Paris meeting to remove the first phrase.

I don't support Santosh unless he also suggests that that everything 
which is already said in
X509 must not be repeated in 3280.

You are actually saying different things: You don't believe that there 
is a non-confusing
interpretation (I don't see this), and you ask that we MUST profile 
something in order
for it to be included in 3280. We don't profile the syntaxes of X509 as 
far as I see,
so why are they there.  :-)
> enforcement while your text uses a language of guidance.
Where do you see 'enforcement'?
> of the usage period as valid, but one could argue that it is not.
in my 2000 version Note 1 of paragraph 8.2.2.5 let me believe that the 
contrary is
the case.: The period of valid use of the private key may be different 
from the certified
validity of the public key indicated by the validity period. With 
digital signatures, the
usage period for the signing private key is typically shorter that for 
the verifying public key.

With X509 there is no place to indicate when a signature has been created.
So how can one determine that the private key has been used outside the
valdiity period? SMIME does not count here.

has the text changed in the latest version of X509?

> However enforcing that validity period is complex and hard.
Where in the text X509 do is anything said about enforcing?
> those extensions that are simply out of scope for RFC 3280bis.
The general use case that I see is that a signing device can warn a user 
not to
use the key anymore (because it may not be verifiable "soon"). The date for
the warning can be set by the CA inside the cert and not hard coded
like 10% of validity or in 3 days..

To summarize: During the Paris meeting the suggested approach to remove 
everything
in 3280 that depracates the extension, in partiicular the first 
senetence in its definition
was accepted by all participants of the meeting.

Peter