RE: Discussion of notareqs document

[aljosa@xxxxxxxxx]

Carl,

> Regarding WG focus, the recent shift in requirements focus has been w.r.t.
> to the "notary" requirements.  The long-term archive requirements focus on
> the types of concerns you mention.  That focus has been relatively stable
> for some time, though the requirements document itself is still evolving.

II know that, but correct me if I am wrong: e-notaries were shifted to
certification services (and this is not the real point), which should provide
among other things some attestation on validity of digital signatures. How this
validity is delivered is a crucial question. There might be a DVCS-like service
but the service itself should provide enough information by itself to prove
that a signature was valid at T1 and not wait until T4. DVCS does provide some
attestation, but it is not clear (at least to me), how the attestation is
actually generated. Can we take DVCS response as "enough information" to
enclose it to a signature and pack everything? Peter?

> Regarding signature preservation, as discussed so far, an evidence record is
> relative to a single time T1, e.g. the time of submission to the archive.
> Retroactive revocation would need to be considered before committing the
> data to an archive and initiating an evidence record (using the mechanisms
> that have been discussed so far).  Even if a CRL were issued immediately
> when a cert was revoked, it's revocation time might be before T1.

Well that is the general problem. Legislation states that post-festum revocation
is not allowed, meaning the time of revocation can not be defined before the
time when revocation was requested. It may take some time before next CRL is
published, so when this information is published is the main issue. If we
consider that time stops at the time of processing, some attestation could be
produced. The practice? I am not sure....

Also, TAS performs its own validation at time T1 and by that states that
signature existed at T1. Post-festum validation should only provide information
that nothing really happened before T1....

I don't
> believe I heard anyone discuss using an evidence record to verify a
> signature relative to multiple points in time (that could get ugly).  It
> seems unlikely that retroactive revocation applied after several periodic
> refresh operations (which should be relatively infrequent) at time T4 should
> invalidate a signature generated at, or before, time T1.

Well, I am afraid exactly of that. See my answer to Santosh - I am not stating
that this is the way to go, I just would like to clear up this issue before
some concrete steps forward are made. We have been playing with implementation
of second generation of TAS but this problems causes headaches, not to mention
the fulfillment of LTANS data grouping requirement... The main outcome I would
like to see is at least a common understanding of the problem and some
conclusions on how to manage such data.

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