[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [pki-tc] OCSP question
Thanks Anders -- and good to see you on the list at last :-) > In case you really need to go back in time in the way you describe, a > solution would be to store the signed OCSP response together with > the signature and the associated data. But I think there is an interesting set of use cases where this is not possible, because of a time lapse between signing and relying; see below. > This will work also in the not so unlikely case that the CA is gone > in 10 years or so. Many people also think that you should > sign the whole package with a time-stamp using a long key as well. I certainly agree we should plan for CAs to be gone; empirically, we all know how rare it is for a CA to last 10 years ;-) And I think reliable binding of time with signed transactions is also important, although not critical. Afterall, system clocks are widely relied upon today without a great deal of validation. But we digress! > In most systems it should be enough to verify the signature during > receival and only accept valid signatures. I reckon there are whole sets of very important applications where significant time elapses between the signature being created and it being relied upon. And to set the scene, I would reiterate that I think one of the truly unique advantages of PKI is that digital signatures create lasting bindings of people (plus their authority information) to the objects they sign. This binding essentially lasts forever (subject to the ageing of the crypto). After I digitally sign something, the signature can be *directly* re-verified years and years into the future with nothing more than a copy of the root public key. Except it would be nice to know that my cert was valid at the time of the signing, hence my original question. To verify the binding between me and my transactions in the case of any other authentication technology usually requires a great deal of forensic work; it can be done (it's fairly common nowadays for forensic IT investigators to establish the true origin of ordinary e-mails or word processor files) but very expensive. So the real power I think of digital signatures is that they can be relied upon long after the time of the signing. Furthermore they can be relied upon by parties who were not "in the loop" at the time of the signature. That is, important PKI applications exist outside today's focus on "real time" (or immediate) checking of signatures. Now, why would anyone want to re-verify an old digital signature? The first set of cases has already been mentioned: forensic investigations. Or the related scenarios where we wish to re-wind a transaction. But there are other, important use cases emerging where checking old signatures will be routine, not exceptional. The first I have come across is electronic conveyancing (real estate property transactions) where several parties all digitally sign a land deal, and a digital version of the Title Deed is lodged with the government. Many parties are involved (buyer, seller, buyer's attorney, seller's attorney, buyer's bank, seller's bank) and their respective signatures may be applied over a period of several weeks as a deal goes through. Moreover, when Title Deeds are digital, they will have planned lifetimes of decades, and at the time of each subseequent transaction, it will be important to re-verify that the old signatures were valid at the time (because fraudulent signing of property transactions is at the heart of much land fraud, and it is the job of a buyer's attorney to always verify that the history of transactions is valid before they advise their client to accept a deal). Electronic conveyancing is at an advanced stage in Australia, and I heard recently in Europe as well, where cross-border recognition of land transactions adds to the complexity. Another example is e-health records. Soonish, we will have systems around the world where many (all?) of a patient's medical event summaries will be digitally signed, by the healthcare professional and possibly also the patient, and lodged in a more or less centralised repository. It will be routine when interrogating these records, over many many years, to double-check that the person signing each record was authorised to do so. Accesses to these records will be subject to strict role based access controls and all accesses logged, again via digital signatures. The validity of a medical person's role is going to be equivalent to their revocation status back at the time of access. Given the legal (and medico-legal) issues involved in the above two cases, I am certain there is a very strong business case for a service which can tell the revocation status of a given certificate at any time in the past. I don't think it would be especially difficult -- at least for CAs that are still in business -- to provide the equivalent of an OCSP response where time is a new parameter. When a CA goes out of business, one of the critical business continuity tasks should be to retrieve and secure the CRLs and delta CRLs. Cheers, Stephen Wilson. > If you can rely on the > storage and integrity of the rest of the system the proof is > implicit. I'm personally in favor of such solutions as key > expiration is a problem not only for end-user certs, > but for CA certificates as well. [snip] > ----- Original Message ----- > From: "Stephen Wilson" <swilson@lockstep.com.au> > To: <pki-tc@lists.oasis-open.org> > Sent: Monday, November 21, 2005 01:00 > Subject: [pki-tc] OCSP question > > > > I have a question specifically about how to check the validity of an old > certificate at the time a given digital signature was created. > > My understanding of OCSP is that it returns the validity of a given > certificate at the time of the request (i.e. "now"). But what if I have a > old digitally signed transaction which I am trying to validate? It could > have been signed years ago, or just days ago, the problem is the same. The > "Relying Party" wants to know if the signer's certificate was valid at the > time of the signature (regardless of whether the certificate happens to > have subsequently expired or even revoked). > > Is the only way to validate old certificates to obtain the CRLs and delta > CRLs leading up to the time of the signature and reconstruct the > certificate validity? > > Or is there an OCSP variant that helps? One that has the time-and-date of > interest as a parameter in the status check request? > > Or finally ... apart from the ill-fated VA model, are there any services on > the market today which provide this information easily? > > Cheers, > > > Stephen Wilson > Lockstep Consulting Pty Ltd > www.lockstep.com.au > ABN 59 593 754 482 > > 11 Minnesota Ave > Five Dock NSW 2046 > Australia > > P +61 (0)414 488 851 > > -------------------- > > About Lockstep > Lockstep was established in early 2004 by noted authentication expert > Stephen Wilson, to provide independent advice and analysis on cyber > security policy, strategy, risk management, and identity management. > Lockstep is also developing unique new smartcard solutions to address > privacy and identity theft. >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]