RE: Discussion of notareqs document

["Carl Wallace" <cwallace@xxxxxxxxxxxx>]

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.

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


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