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

From: Russ Housley <[email-masked]>
Date: Wed, 01 Mar 2006 10:54:49 -0500

I do not see any good from including this extension.  I suggest we 
drop it altogether.

It was included in RFC 2459 because we discussed all of the 
extensions that were in X.509 at the time.  We discourage its 
use.  Today, many more extensions have been added to X.509, and we 
make no attempt to keep up with them.  They are simply no part of the 
PKIX profile.  I strongly advocate the handling of this extension in 
the same manner.  Simple silence.

Russ

At 10:21 AM 2/16/2006, Denis Pinkas wrote:

>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: Fri, 03 Mar 2006 15:28:52 +0100

Russ Housley wrote:
> It was included in RFC 2459 because we discussed all of the extensions 
> that were in X.509 at the time.  We discourage its use.  Today, many 
> more extensions have been added to X.509, and we make no attempt to 
> keep up with them.  They are simply no part of the PKIX profile.  I 
> strongly advocate the handling of this extension in the same manner.  
> Simple silence.
Can you name some other extensions concerning PKcertificates which is
in X.509 and not in 3280.

The discussion in Paris made clear that we do not discourage its use.
no one has given a reasonable explanation of why it is discouraged.
Claiming that it is inconsistent is not an acceptable argument.

Now you propose being silent. This is a chnage from the previous texts
which is not mentioned in the introduction. 3280 and 3280bis list
the difference with 2459.

Not including it also does not mean that we explicitely discourage it
anymore?

What means "part of profile"?
That you add some constraints of X.509, or a clarification?

There are many texts that are totally identical with X.509,
i.e. equivalent. The text already uses different wording
There is nothing profiled concerning the validity dates.
Why are they in the profile?

Why is the asn.1 syntax present at all. It doesn't differ from X.509
Simple silence? Why?

"This text does not longer mention the privatekeyusage extension
because it is not profiled in a particular way."

And what stops us to add the few extensions concerning CRLs,
i.e. to provide 88 syntax and a IETFish language?

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