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

From: "Stefan Santesson" <[email-masked]>
Date: Wed, 1 Mar 2006 17:22:24 -0000

I second Russ suggestion.

This thread makes it even clearer to me that we will not achieve
consensus on what this extension really means.

All information in a certificate is information associated with the
certified public key. This makes this extension confusing and the
proposed wording doesn't help.

Reading X.509 suggest that the extension signals to the relying party
that the corresponding private key is restricted but does is not clear
on how that is enforced or what impact a violation of this restriction
has.

I suggest that those who want's to clarify this extension write a Defect
Report to X.509 and use that as basis for their eventual implementation.

Stefan Santesson
Program Manager, Standards Liaison
Windows Security

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Russ Housley
Sent: den 1 mars 2006 16:55
To: Denis Pinkas; pkix
Subject: Re: 3280bis: private key usage extension (2)

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:06:22 +0100

> consensus on what this extension really means.
Why do you think that their is a problem of consensus about what
the extension means? you are claiming confusing or inconsistency
without giving an example about two interpretation which would
conflict the definition. The text in X.509 seems pretty clear to me.

> proposed wording doesn't help.
Well, indeed you can say that a keyusage of signture is set in order
to allow to verify signature, and not to provide a means to a signer to
select an appropriate certificate, but in really implementations that will
use the private key for some signing property will use this information
to select an appropriate certificate.

So it seems that you are confused about the extension? What is it that
you don't understand? What is it good for. The text in X.509 says this.
> on how that is enforced or what impact a violation of this restriction
The same remark is also true for validity dates. Where does any text talks
about how something is enforced. saying "MUST NOT accept" is not
enforcement. And, nowhere in that extension, there is something that
talks about a requirement of  'enforcement'.
> Report to X.509 and use that as basis for their eventual implementation.
That is not the purpose of the discussion. The purpose is that it is the 
only
extension of X.509 concerning certificates that is not in 3280bis.

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