RE: Discussion of notareqs document

["Carl Wallace" <cwallace@xxxxxxxxxxxx>]

Why would a CRL be issued so infrequently for someone signing documents?
Usually that is the case for offline roots and such.  In any case, if when
the evidence record is validated the signer's certificate is not expired,
the relying party (or data validation service) should retrieve the current
CRL and see if the certificate has been revoked and if so whether or not
there is a revocation date indication.  The revocation date can be compared
to the T1 in the record.  

The TAS could be configured to retrieve the CRLs shortly before and
immediately after the expiration of each signer's certificate (to capture
revocation events during the entire life of the certificate).
Alternatively, if CRL publication weren't an unpredictable affair (and in
most cases it isn't), the TAS could simply be configured to retrieve a CRL
after a grace period to support retroactive revocation.

The lta requirements document currently mentions retroactive revocation in
the security considerations section.  Support for retroactive revocation
should be added as a requirement in the body of the document.

> -----Original Message-----
> From: owner-ietf-ltans@xxxxxxxxxxxx 
> [mailto:owner-ietf-ltans@xxxxxxxxxxxx] On Behalf Of aljosa@xxxxxxxxx
> Sent: Wednesday, November 03, 2004 5:53 AM
> To: ietf-ltans@xxxxxxx
> Subject: RE: Discussion of notareqs document
> 
> 
> 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.
> > >
> > >
> > >
> >
> >
> >
> >
> 
>