Re: Why is privateKeyUsagePeriod deprecated?

["Al Arsenault" <aarsenau@xxxxxxx>]

----- Original Message -----
From: "Peter Gutmann" <pgut001@xxxxxxxxxxxxxxxxx>
To: <Denis.Pinkas@xxxxxxxx>; <pgut001@xxxxxxxxxxxxxxxxx>
Cc: <ietf-pkix@xxxxxxx>
Sent: Wednesday, July 23, 2003 11:24 AM
Subject: Re: Why is privateKeyUsagePeriod deprecated?


> <snip>
>
> Incidentally, one amusing/scary side-effect of using certs after they've
> expired is that the CA generally no longer bothers issuing CRLs for them
> (since they've expired), but they're still being used to validate
signatures
> beyond the 1-year billing period.  As a result, it's impossible to perform
> revocation checking on the cert.  I guess if you're ignoring the expiry
date
> you may as well ignore revocation checking as well :-).
>
> Peter.

This brings up what is to me an interesting question:  exactly what service
do you think you're providing with this signature validation long after the
fact, and why do you think it's important?

That's a big input into whether or not the privateKeyUsagePeriod extension
brings any value.

I can only think of about three reasons why one would want to do a signature
validation months after an order was signed:

    - as part of a business audit;
    - as part of a dispute resolution process (e.g., a non-repudiation
issue)
    - because one's business processes were REALLLLY slow, and it just takes
that long to process an order.

Consider two scenarios:

Scenario 1:



            A certificate is issued 1-January-2004; it's valid until
30-June-2004; there is no privateKeyUsagePeriod extension



Scenario 2:



            A certificate is issued 1-January-2004; it's valid until 31
December-2004; there is a privateKeyUsagePeriod extension allowing use of
the private key for signing from 1-January-2004 through 30-June-2004.



Now, suppose that there is an EDI transaction ostensibly signed 30 March
2004; someone attempts to validate this transaction on 30 December 2004.



In scenario 1, the certificate has expired.  That means that the CA has
stopped attesting to the validity of the owner-key mapping on 30 June 2004.
There is no  current evidence of revocation; i.e., there is no current
indication that the owner-key mapping is valid or not. There is, however, a
CRL and/or OCSP response indicating whether or not the certificate was
revoked on or shortly after 30 March 2004.



In scenario 2, the certificate is still valid.  Thus, there should be
evidence in the system that indicates not only whether the owner-key mapping
was valid on 30 March 2004, but also on 30 December 2004.



Suppose that the certificate was issued to Bob at Acme Corp.  On 30 November
2004, Bob was fired because it was discovered that he had been
misappropriating office supplies.  It is suspected that he has initiated and
signed a number of EDI transactions in connection with his nefarious scheme.



(If you want the certificate issued with Acme Corp. itself instead of Bob,
that's fine; we can just assume that the private key has somehow been
discovered and posted on a prominent web site.  In other words, it's
compromised.)



 So, what do you do?  If we're in Scenario 2, and you're just processing the
transaction on 30 December because your business processes are that slow,
then it might make a difference to you.  You know that the key is marked
compromised; the certificate is revoked. So you don't send the office
supplies.  If it's scenario 1, you MAY choose to accept the transaction and
send the supplies, even though the certificate has long ago expired.  There
may be a difference in behavior.



But in either of the other cases (audit or non-repudiation dispute), does it
really make a difference that you had the information from November?  You're
trying to determine whether accepting the transaction on 30 March was the
right thing to do.  You have to use the information that was available to
you on 30 March (or a few days thereafter) - the CRL or OCSP response from
right after that; the transaction itself; any other records.  If the key
were discovered on 30 November to be compromised, would you really say that
the behavior in March should have been different based on whether a
privateKeyUsageExtension were used or not?



Put another way:  the only potential benefit I can see to scenario 2 over
scenario 1 is that the CA is in essence stating:  "I'll keep track of the
status of Acme Corp., the cert owner, for a longer period of time.  If
evidence arises that Acme Corp. is no longer the rightful, unique holder of
the private key associated with that certificate, I'll let you know - even
though Acme Corp. has long since ceased using that private key to sign new
transactions.  What you do differently because of this information is up to
you."



My point is this:  from what I can see, usage of the extension really
doesn't buy you anything.  In order to accurately assess whether the
transaction was valid at the time of signing, and assess that long after the
fact, you have to archive so much extra information that I don't see what
pain is caused by the fact that the certificate has expired by then. It's
not clear to me what if anything you do differently because you have
information directly tied to the certificate - e.g., it was revoked months
later. It doesn't save much in the way of processing to have any such
information directly tied to the certificate, versus tied to some other
piece of information you had to archive.



I'm certainly open to explanations as to what I'm missing; that is, why it's
important to have this information in the certificate and what you'd do
different because of it.  But given that privateKeyUsagePeriod is permitted
in a certificate for those who really want it (it's a SHOULD NOT, not a MUST
NOT unless you want to mark it critical), and I personally don't see any
benefit to it, I'm in favor of leaving the recommendation the way it is in
3280.



                Al Arsenault