Subject: Re: Certificate Validity Problem

From: [email-masked]
Date: Mon, 19 Dec 2005 09:36:52 +0100

Thanks to everybody who sent comments about my question. I have read the
answers and related RFC's and it seems that SCVP is the only solution to
learn the status of a certificate at a certain time in the past. However I
find SCVP very complicated and we need only a limited part of the SCVP
functionality.

Please not that knowing the status of a certificate in the past in not necessary in general,
except when the signers's certificate is close to its expiration time, more precisely
if the verification is done once the certificate has expired. However, this last case should not occur
if the signer receives its new certificate (e.g. one month in advance) and use it once received.

Some more explanations about the general case:

1) if the certificate was revoked at the time of signature, it will be also revoked at the time of the verification.
2) if the certificate was suspended, then it may still be suspended, or revoked or not revokded at the time of verifiication.
The status at the time of verification is thus better in the general case.

There is no need for over-engineering by defining a new protocol.

Denis

We would like to implement a new and simpler protocol to solve our
problem. This protocol may be called "Certificate History Retrieval
Protocol". What is the procedure to propose this as a new RFC?

Thanks.

Ersin

>
> Hello,
>
> We are operating a Certificate Authority (which uses our own CA software)
> and we have a process to set certificate status to on-hold. Owners of
> certificates can put their certificates on-hold and they can return them
> to the valid status.
>
> When somebody tries to verify the validity of signature he can only check
> the most recent status of the certificate. He can use the most fresh CRL
> or execute an OCSP query. Both of these techniques lack an important
> functionality, you cannot query the status of a certificate at a certain
> time in the past. Maybe at the time of signing the certificate used was
> on-hold.
>
> Is there a method or another technique to solve this problem?
>
> Thanks.
>

---

From: sravan <[email-masked]>
Date: Mon, 19 Dec 2005 14:55:32 +0530

[email-masked] wrote:

> 1) if the certificate was revoked at the time of signature, it will be 
> also revoked at the time of the verification.
> 2) if the certificate was suspended, then it may still be suspended, 
> or revoked or not revokded at the time of verifiication.
Dear All,
I feel that determining the status of a certificate at a give instance 
is required and we need to have a simpler protocol for determining it.
Here are some points supporting my opinion:

This(knowing the status of a certificate at a give instance) is 
necessary in cases where in, we need to prove the validity of a digital 
signature long after the expiry of the signer's certificate. Say an 
employee approves & signs a document and after some time he terminates 
from the organization; but we need to prove that the document was infact 
approved and signed by that particular employee even after a long time. 
In this case, there will not be anything like the signer getting his new 
certificate as Denis has mentioned.

Also, consider a scenario (as Denis has mentioned in case 2) where in, a 
certificate is suspended and after some time it is activated again.
In this scenario, if a digital signature is created when the certificate 
is suspended and verification is done after sometime(when the 
certificate is activated), the digital signature is accepted although it 
shouldn't be the case.

The problem here is that during certificate validation, latest* 
*revocation information is being used instead of that available at the 
time of signing.

So, I feel that we need to have a simple protocol(similar to OCSP), 
which gives the status of a digital certificate at a given instance. I 
don't need any certificate validation(as is done in SCVP) per se. All I 
need is,
say I give these fields identifying a certificate and the time at which 
that certificate's status is required:
                                <IssuerDN, IssuerPublicKey, 
CertificateSerialNumber, Time>
i need a response telling the status of the identified certificate at 
the given Time.

- Sravan

PS: In all the above cases, I am assuming that signature time-stamp is 
done so that one can determine the signing time in a trusted way.

---

From: Dino Esposito <[email-masked]>
Date: Mon, 19 Dec 2005 10:49:59 +0100

>    The status at the time of verification is thus better in the 
Partially true; when a deed is filed to an eGovernment service (just an 
example) it is possible that the verification happens weeks or months 
after the filing (think of a judiciary litigation). In this case the 
time of verification is meaningless, but it's important the signature 
time and the certification status at that time. Since the protocols 
defined in some other standard (i.e. ETSI 101733, with a self validated 
envelope or SCVP) are not widely spread, the problem will be here. Maybe 
a new protocol is over-engineering, but a common ground would be quite 
useful

Alfredo Esposito
InfoCamere S.C.p.A.
Italy

---

From: "Anders Rundgren" <[email-masked]>
Date: Wed, 21 Dec 2005 21:36:28 +0100

Dear Sravan & Ersin,

<snip>
>*revocation information is being used instead of that available at the 

I would rather say that the problem is to determine the actual signing
time unless you are going to trust the client's (software) opinion on that.

But there is fortunately a simple workaround:

In 21st century information systems, on-line signatures should be used,
making signing time=validation time.  Then OCSP works similar to how
most credit-card processing systems do since the 80ties.  In Scandinavia
governments have abandoned e-mail signatures for on-line signatures,
as on-line not only allows  you to validate a task (not only its signature),
the instant it is actually submitted, but also offers an interactive mode
as well as supporting structured data with full indata and form control
(Excel files or PDF forms sent by signed e-mail is simply stone age revisited).

================================================
   The remaining and non-trivial issue is then how to best address the
   case when a CA (usually via the certificate holder), finds out that a
   certificate may have been used by a fraudster
================================================

In my opinion, historical validation is a problematic approach because it
does not address the fundamental question: WHEN is the "right time" for
a relying party application to call such a service?  If you already know
how to specify this for your user community, please let us, somewhat
less enlightened, share this knowledge :-)

Authentication >> Signatures
Although signatures indeed are "cool",  authentication errors (and due to that
information-theft), is probably in the real world, a considerably bigger issue
as there is no way you can "rollback" such an error.   How do you intend
to deal with this using historical validation?  

To actually be *informed* that you may have had a break-in, or that
you are possibly keeping invalid documents in your systems, seems to be
worth some thinking, maybe even a new protocol!

regards
Anders Rundgren
Principal Engineer
RSA Security