RE: Discussion of notareqs document

[aljosa@xxxxxxxxx]

Santosh,

I am afraid it is not that simple. Let's say I want a Premium service for some
very important document which is also time critical. There are no rules when
CRLs are refreshed and in some scenarios CRLs are not issued for another month
or so. Waiting your document to be formally processed after a month... well
that is just not the evolving scenario. The basic concept of solving this
problem should use two time evidences at least. First one to attest that a
signature existed at the time of arrival and the later attestation that proves
the validity of a signature based on some reference information (CRL more
precisely). The things get a bit more complicated when a document carries
several signatures based on certificates issued by (unsynchronized) CAs.

However, there are also some conceptual approaches to this problem. One is to
assure that CRLs carry some time evidences (when they were actually issued –
the same used as for TAS) and that policies clearly declare that CRLs are
issued after some action and that post action publishing is strictly forbidden
(e.g. a certificate can't be revoked back in time and the revocation is valid
only after a CRL is issued). This way we could at least shorten the time frame
left for manipulation (I am not counting the processing time here, which is
unavoidable).

I think we should agree at least on some basic concepts here and define some TAS
framework understanding. Also, conclusions should be propagated to other areas
and WGs to achieve some consensus on how to properly manage signed documents in
time.

aleksej

Quoting Santosh Chokhani <chokhani@xxxxxxxxxxxx>:

>
> Aleksej,
>
> The archive package should contain the CRL used to verify the transaction.
> That coupled with other times will show when the transaction was received
> and processed.
>
> When speed is of not essence, the relying party can always wait for a CRL
> issued after the transaction was received to verify.  This will ensure that
> the certificate was not revoked in the interim.  Relying party can use the
> later CRL for archiving the transaction.
>
> -----Original Message-----
> From: owner-ietf-ltans@xxxxxxxxxxxx [mailto:owner-ietf-ltans@xxxxxxxxxxxx]
> On Behalf Of A. Jerman Blazic
> Sent: Monday, November 01, 2004 1:52 PM
> To: ietf-ltans@xxxxxxx
> Subject: RE: Discussion of notareqs document
>
>
>
> Dear all,
>
> Following the "e-notary" discussion in the last month I see that
> requirements have been rapidly shifted and are now reflecting the
> certification and validation services. Coming to this point I would like to
> draw your attention to the fundamental problem that at least I have when
> playing around with the scenario of digitally signed documents, which is
> however the crucial focus of TAS services at this point. I also think that
> real scenarios would help us understand the problems more clearly and find
> appropriate solution(s).
>
> Now let's assume that a signed document enters an archive. What happens in
> the first place is signature validation (since we assume that there is no
> point to archive a non-valid document, although such scenarios are also
> possible). We also assume that TAS protocols and ERS are in place. So, what
> we need is some fixation in time that signature (and document) existed at
> some point in time (archiving time!). Providing evidence for a document is
> not a problem, but for a signature there are some sequence issues.
>
> Preserving signatures is based on reference information and evidence record.
> Let's start with T1, when a CRL has been issued and the next time the CRL is
> issued is marked with T5. Now we need to collect some reference information
> (certificates, CRLs, etc.), validate the signature and pack everything
> together before creating the evidence record (timestamp). At time T2 a
> timestamp is requested for collected data following by timestamp issued at
> T3. Until T5 we have enough time to revoke the certificate related to
> digital signature archived, which happens at T4 and we can end up with
> archived invalid signature, although it was submitted to the archive before
> revocation happened.
>
> The problem with CRLs is that they might not be synchronized with revocation
> mechanisms and there is no real information whether a signature is valid or
> not at specific point in time. In theory CRLs should be issued immediately
> after a certificate is revoked, but in practice things are not the same,
> since the procedure itself already has some timeframe (the ideal solution is
> to stop the time during the validation process).
>
> Now, there are options to use more than one evidence record for a single
> data (signature) but I am afraid such procedures might get overall concept
> very complicated and bulky, especially when performing procedures over
> groups of data. I think we should pay some more attention to archival data
> structures and mechanisms supporting TAS operation. I would appreciate if
> some feedback would reach my inbox concerning the mentioned problem and I
> also hope such discussion(s) would unveil the black box internal mechanisms,
> which we named TAS or whatever and after all, solve the main problem of
> LTANS requirements on data export.
>
> Regards
>
> aleksej
>
> > -----Original Message-----
> > From: owner-ietf-ltans@xxxxxxxxxxxx
> > [mailto:owner-ietf-ltans@xxxxxxxxxxxx] On Behalf Of Paul-André PAYS
> > Sent: Thursday, October 28, 2004 4:18 PM
> > To: ietf-ltans@xxxxxxx
> > Subject: Re: Discussion of notareqs document
> >
> >
> >
> >  -- Denis Pinkas --  a dit,  - le 28/10/2004 15:39:
> >
> >
> > 	Paul-André,
> >
> > 	(text deleted)
> >
> >
> >
> > 		This is another proof of the sound approach of
> > LTANS which links "data certs" and "secure archived". Any
> > "data cert" must not only be signed, but a detailed log entry
> > must be archived in a secure way (non rewritable medium, hash
> > linking). This mandatory combination was a major rationale of
> > the openevidence project (the technical solution by then was
> > a a combination of TSP RFC3061, DVCS RFC3029 and hash-linking)
> >
> >
> >
> > 	There is no such mandatory comnbination for LTANS: data needs to be
> > signed (and time-stamped) by the archive service, but the log is not
> > intended to be used as an evidence.
> >
> >
> > I am exactly suggesting that it be.
> >
> > We are preparing a requirements document and not some "a posteriori"
> > rationale for a given protocol or service.  My strong suggestion,
> > based on several years activities for several customers, is indeed
> > that the "certified archival" of "detailed and signed" log is a "must"
> > for a large majority of actual applications and uses cases.
> >
> > What the most "educated" or aware customers do require is a complete
> > set of "evidence management" services. (What they call in France
> > "Gestion de la Preuve" or "Administration de la Preuve"; what they
> > will be able to exhibit in order to dissuade "others" to initiate a
> > litigation, or whenever unsuccessfull, what they will be able to
> > exhibit as evidence elements in a court).
> >
> > My personal view of the whole justification of LTANS  context is, as I
> > am convinced that this type of requirements will be generalized, that
> > the IETF succeeds in proposing and establishing standards that wil
> > enable :
> >
> >
> > 1.	technical interop between business partners
> > 2.	technical interop between solution providers
> >
> > 3.	the judges and their expert to master the e-material
> > (because it conforms to standard and because there exist tools enbling
> > to manipulate them)
> > 4.	the possibility of mutual recognition within a business
> > community
> >
> > And I have no longer any doubt that  "certified archived logs" (more
> > or less equivalent of the certified archival of requests and receipts)
> > will be one of, if not, the most usefull component.
> >
> >
> >
> >
> > 	Denis
> >
> >
> >
> >
> >
> >
> >
> >
> > --
> >
> > Edelweb
> > 	Groupe ON-X Pôle Sécurité
> > paul-andre.pays@xxxxxxxxxx	 papays@xxxxxxxx
> > http://www.edelweb.fr/	 http://www.on-x.com/
> > Tel. + 33 1 40 99 14 14. Fax. +33 1 40 99 99 58 -- Adresse :
> > 15, quai de Dion Bouton  -  92816 Puteaux cedex Pour vérifier
> > la signature électronique, http://edelpki.edelweb.fr/ vous
> > permet d'obtenir le certificat de l'autorité et la LCR.
> >
> >
> >
>
>
>
>