Subject: Re: Why is privateKeyUsagePeriod deprecated?

From: [email-masked] (Peter Gutmann)
Date: Thu, 24 Jul 2003 03:24:55 +1200

Denis Pinkas <[email-masked]> writes:

>RFC 3126 provides some guidance :
>
>    If a recipient wants to hold a valid electronic signature he will
>    have to ensure that he has obtained a valid time stamp for it, before
>    that key (and any key involved in the validation) is revoked.  The
>    sooner the time-stamp is obtained after the signing time, the better.
>
>However, since the "sooner is the better", it is not mentioned explicitly
>that the time-stamp token MUST be obtained at latest before the end of the
>validity period of the certificate (since a CRL does not include the serial
>number of a certificate once it has expired) and the CRL (or OCSP response)
>close to that time MUST be captured.

Right, timestamping (and 3126) would definitely be the proper solution to the
problem.  Unfortunately though it's little-used (and seems unlikely to be
adopted) in the particular area where this type of long-term signature
validation needs to occur, which is in EDI transactions (I'm sure it occurs
elswhere as well, but when I hear people wanting to use expired certs to
verify sigs it's usually in this area).  Typically the requirement for these
things is that you archive copies of all messages going back to the beginning
of time, and have to verify signatures using archived certs at some arbitrary
point in the future.  This is just an updated form of the "securely archive
everything forerever" in interchange agreements. In other words they've taken
the rather vague "archive it securely" and made it more concrete as "archive
messages in signed form so they can be verified as untampered at a later
date", with variations depending on which industry group and/or set of
agreements is in effect.

So what you have is:

- Signed data that must be stored over long periods of time (possibly
  decades).

- Certs with a one-year lifetime (see my earlier posting).

- People in need of guidance as to how they can reconcile the two, within the
  framework that they already have (which unfortunately excludes adding
  additional external services, at least until the EDI standards and
  interchange agreements are all renegotiated, although I suspect the main
  change that will take place at that point is a switch to XML or whatever
  else is trendy at the time).

Let me ask some of the people (at least the ones I can remember) who've
brought this up in the past to see what they'd actually need done.

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.

---

From: "Al Arsenault" <[email-masked]>
Date: Wed, 23 Jul 2003 17:00:19 -0400

----- Original Message -----
From: "Peter Gutmann" <[email-masked]>
To: <[email-masked]>; <[email-masked]>
Cc: <[email-masked]>
Sent: Wednesday, July 23, 2003 11:24 AM
Subject: Re: Why is privateKeyUsagePeriod deprecated?

> <snip>

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

---

From: Russ Housley <[email-masked]>
Date: Thu, 24 Jul 2003 09:22:13 -0400

I agree with Al's conclusion.  SHOULD NOT is the right wording for RFC 3280 
(and its successor).

Russ