[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Discussion of notareqs document
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.
>
>
>