Subject: 3280bis: private key usage extension (2)

From: "Denis Pinkas" <[email-masked]>
Date: Thu, 16 Feb 2006 16:21:02 +0100

Copy of the minutes from the Paris PKIX meeting:

“He [Denis] suggested that the private key usage extension not be deprecated universally, 
but rather be allowed in certain contexts, e.g., time stamp crypto modules. 
He proposed to soften the prohibition against private key usage or to delete annex D.1. 
and thus annex D) which is the only section that addresses this topic”.

Peter correctly recalls that there was no objection raised on that issue by the participants 
of the Paris meeting.

Stefan’s argumentation is that it should not be part of the profile. 
There are many features described in the document that MAY be implemented 
but are not mandatory to implement. I see advantages to describe the extension within this profile.

I believe however that an additional clarification is needed. The private key usage extension 
is only intended to be used by the owner of the certificate. For this I added: “ by the certificate owner”. 
This extension can fully be ignored by the other “relying parties”, this is why this extension is non-critical. 
For this I added: “Except the certificate owner, other relying parties SHOULD ignore that extension”.

However, it can be very useful for (HSM Hardware Security Modules) when the properties of the HSM 
can be verified : this allows an enforcement by the CA the private key will not be used beyond 
a given date. Since the end of the use of the private key, if specified, will be shorter than the end of the 
validity period of the certificate, this allows to guaranty a minimum period during which 
the signed object can be verified (e.g. PKCs or TSTs).

Proposed revised text:

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 by the certificate owner 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.

   Except the certificate owner, other relying parties SHOULD ignore 
   that 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.

   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 }

Denis

---

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

> Peter correctly recalls that there was no objection raised on that issue by the participants 
To be exact, I did not.

I reminded that as far as I remember there was a consensus of
removing the beginning the paragraph 4.2.1.4 that depracates its
use in the Internet PKI.

> but are not mandatory to implement. I see advantages to describe the extension within this profile.
Indeed, many things in 3280 are included only because they seem to be 
referenced
elsewhere in 3280 whilst the text is basically identical with X509 (with 
the usual
transformation of MUST/shall etc.

I would not mind to add that the notBefore MUST be before the notAfter
if both are present.

> For this I added: “Except the certificate owner, other relying parties SHOULD ignore that extension”.

SHOULD is too weak imo. It is not mentioned in the path validation 
algorithm.
see below

> the signed object can be verified (e.g. PKCs or TSTs).
Whether it enforced or not doesn't matter, the point is not whether it 
is useful
or not but whether one should silently drop it from the specification.
>    certificate SHOULD NOT be used by the certificate owner to sign 
This SHOULD NOT is too much. "An implementation MAY not allow the use
of the signing key, if the current time is before the notBefore or after 
the notAfter
fields."
>    include a critical private key usage period extension.
The text: The extension MUST always be marked non-critical was ok.
>    Except the certificate owner, other relying parties SHOULD ignore 
I'd say: "if the standard path validation algorithm returns a valid 
status, other relying
parties MUST NOT use the extension to declare the usage of the certificate
as invalid."
>    indicated in that extension.
That should not be part of the normative section. The "when" is 
restricting the
usage. Any signing software MAY use the extension either by restricting 
the use
or by creating a warning, etc.
>         notAfter        [1]     GeneralizedTime OPTIONAL }
privateKeyUsagePerio-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) )

to make modern compilers happy. :-)

-- 
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.