Subject: RE: Certificate Validity Problem

From: "Carl Wallace" <[email-masked]>
Date: Sun, 18 Dec 2005 06:49:55 -0800

An upcoming LTANS I-D will define a few directory attributes used to
store historical certificates and/or historical certificates with
corresponding EvidenceRecord structures. 

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Ersin Gulacti
> Sent: Sunday, December 18, 2005 4:40 AM
> To: [email-masked]
> Subject: Re: Certificate Validity Problem
> 
> 
> 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.
> 
> 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: [email-masked]
Date: Mon, 19 Dec 2005 12:14:57 +0100

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

[Denis] No. It is not. It sufficient to capture the CRL or the OCSP response
at the time of verification or close to the time of verification.

Denis

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: [email-masked]
Date: Mon, 19 Dec 2005 12:21:48 +0100

(text deleted)

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

[Denis]. Not really. It would mean receiving the document and not verifying anything
about the signature.

Signed documents MUST be verified "shortly" after they are received.
Then a dispute may happen two months or two years later, but the proofs
have been captured (or the document has already been rejected because it was invalid).

[Denis/]

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

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