Subject: RE: 3280bis: Private Key Usage Period

From: "Santosh Chokhani" <[email-masked]>
Date: Tue, 14 Feb 2006 13:46:43 -0800

Peter,

All I am saying is that it need not be part of the profile.  If some one
uses the extension, fine.

My reading of Section 4.2 text is that if a CA asserted the private key
usage period as a non-critical extension, it is in conformance with
3280.   My reading of Section 4.2 text is that if a relying party
processed the private key usage period extension, it is in compliance
with 3280.  My reading of Section 4.2 text is that if a relying party
did not process the private key usage period extension, it is in
compliance with 3280, as long as the relying party adhered to the
processing of broader criticality requirement when the extension is
marked critical.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Stefan Santesson
Sent: Tuesday, February 14, 2006 3:16 PM
To: Peter Sylvester
Cc: Denis Pinkas; pkix
Subject: RE: 3280bis: Private Key Usage Period

Here is the section from X.509 2005.

8.2.2.5	Private key usage period extension
This field indicates the period of use of the private key corresponding
to the certified public key. It is applicable only for digital signature
keys. This field is defined as follows:
	privateKeyUsagePeriod EXTENSION ::= {
		SYNTAX			PrivateKeyUsagePeriod
		IDENTIFIED BY		id-ce-privateKeyUsagePeriod }
	PrivateKeyUsagePeriod ::= SEQUENCE {
		notBefore	[0]	GeneralizedTime OPTIONAL,
		notAfter	[1]	GeneralizedTime OPTIONAL }
		( WITH COMPONENTS {..., notBefore PRESENT} |
		WITH COMPONENTS 	{..., notAfter PRESENT} )
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.
This extension is always non-critical.
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.
NOTE 2 - If the verifier of a digital signature wants to check that the
certificate has not been revoked, for example due to key compromise, up
to the time of verification, then a valid certificate will still exist
for the public key at verification time. After the certificate(s) for a
public key have expired, a signature verifier cannot rely on compromises
being notified via CRLs.

-------------------
I agree that we should not ban its use. We have just excluded it from
the profile.

In general I've noticed that we are not confused by standards, we are
only confused that others don't share our interpretation of it :)

Stefan Santesson
Program Manager, Standards Liaison
Windows Security

-----Original Message-----
From: Peter Sylvester [mailto:[email-masked]] 
Sent: den 14 februari 2006 11:55
To: Stefan Santesson
Cc: Denis Pinkas; pkix
Subject: Re: 3280bis: Private Key Usage Period

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

Stefan Santesson wrote:
> IMO this is a confusing extension for which I don't believe there are
> 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.

> The only way we can include this in RFC 3280bis is if we can profile
the
> 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.  :-)
> The problem is that X.509 in its definition use a language of
> enforcement while your text uses a language of guidance.
>
>   
Where do you see 'enforcement'?
> 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.
>   
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?
> 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.
>   
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

---

From: Peter Sylvester <[email-masked]>
Date: Sun, 19 Feb 2006 18:20:16 +0100

First,  I don't argue the content here. There were 30 persons in a 
meeting that agreed on
remval of one sentence and there were opponents of totally removing it.

> uses the extension, fine.
Yes, but it has been and profiled (it has been depracated),
and the text was not identical with X509.

- The ASN1. syntax of X509 is not  the same used as in 3280 (so far).
- The text is different.
- 3280 did not copy all relevant parts, in particular it didn't copy the
  requirements section. 8.2.1 d)

People have used the 3280 definition and not read anything of X.509.
They may now be surprised about not finding anything, not having X509,
and if, they may discover the section 8.2.1 d)  and  there, trying to 
understand
it... 

> 3280.   
Yes.
> My reading of Section 4.2 text is that if a relying party
> with 3280.  
Yes
> My reading of Section 4.2 text is that if a relying party
As far as I see X509, the extension is always non-critical.

> public key have expired, a signature verifier cannot rely on compromises
I have the same text.

-- 
To verify the signature, see http://edelpki.edelweb.fr/ 
Cela vous permet de charger le certificat de l'autorité; 
die Liste mit zurückgerufenen Zertifikaten finden Sie da auch.