[no subject]

In case you are trying to address another problem: "was the certificate
maybe not in the possession of its owner at the time of signing", the
above does not work.  In case you need something like that, you would
probably like to be alerted _the_moment_this_becomes_known_
and not ten years after, when the signature is to be relied on.

Anders

----- Original Message ----- 
From: "Stephen Wilson" <swilson@lockstep.com.au>
To: <pki-tc@lists.oasis-open.org>
Sent: Monday, November 21, 2005 22:46
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. 
>  


---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail.  You may a link to this group and all your TCs in OASIS
at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php