Subject: RE: Discussion of notareqs document

From: "A. Jerman Blazic" <[email-masked]>
Date: Mon, 1 Nov 2004 19:52:09 +0100

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: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Paul-André PAYS
> Sent: Thursday, October 28, 2004 4:18 PM
> To: [email-masked]
> 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é	 
> [email-masked]	 [email-masked]	 
> 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. 
> 
> 
>

---

From: "Santosh Chokhani" <[email-masked]>
Date: Mon, 1 Nov 2004 14:12:37 -0500

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: [email-masked] [mailto:[email-masked]]
On Behalf Of A. Jerman Blazic
Sent: Monday, November 01, 2004 1:52 PM
To: [email-masked]
Subject: RE: Discussion of notareqs document

Dear all,

Regards

aleksej

> 	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.
> 	
> 
> 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 :
> 
> 
> (because it conforms to standard and because there exist tools enbling 
> to manipulate them)
> 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

---

From: "Carl Wallace" <[email-masked]>
Date: Tue, 2 Nov 2004 08:38:22 -0500

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.  

> [mailto:[email-masked]] On Behalf Of A. Jerman Blazic
> 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.
> 
> 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
> 
> 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)
> > 		
> > 
> > 
> needs to be 
> posteriori" 
> complete 
> logs" (more 
> > 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.
> > 
> > 
> > 
> 
>

---

From: [email-masked]
Date: Wed, 3 Nov 2004 11:52:30 +0100

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

---

From: [email-masked]
Date: Wed, 3 Nov 2004 14:10:04 +0100

Carl,

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

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

---

From: "Carl Wallace" <[email-masked]>
Date: Wed, 3 Nov 2004 07:45:31 -0500

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.

> [mailto:[email-masked]] On Behalf Of [email-masked]
> Sent: Wednesday, November 03, 2004 5:53 AM
> To: [email-masked]
> 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
> 
> > 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.
> >
> > 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 
> > 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.
> >
> > 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) 
> named TAS or 
> > whatever and after all, solve the main problem of LTANS 
> requirements on data export.
> >
> > Regards
> >
> > aleksej
> >
> > > 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)
> > >
> > >
> > >
> > > 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 :
> > >
> > >
> > > (because it conforms to standard and because there exist tools 
> > > enbling to manipulate them)
> > > or less equivalent of the certified archival of requests and 
> > > receipts) will be one of, if not, the most usefull component.
> > >
> > >
> > >
> > >
> > > 	Denis
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > --
> > >
> > > Edelweb

---

From: "Carl Wallace" <[email-masked]>
Date: Wed, 3 Nov 2004 08:30:34 -0500

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

CRLs do not provide a means of determining "when revocation was requested"
vs. the revocation time included in the CRL.  That must be enforced by the
CRL issuer.
 
> 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....

OK, but a TAS may archive an invalid signature (or evidence of invalidity).

---

From: [email-masked]
Date: Wed, 3 Nov 2004 14:52:26 +0100

> Why would a CRL be issued so infrequently for someone signing documents?

Well, that is a very good question. But, there are no (technical) restrictions
defined except for policy... and, well legislation.

> revocation events during the entire life of the certificate).

I am discussing mostly time critical services. I do not know what do you mean
exactly here, since the lifetime of a certificate can span for over 5 years and
such archival procedure is just not feasible. TAS must provide response in a
very short time (I imagine 24 hours is maximum for time critical services).

> after a grace period to support retroactive revocation.

I agree and that is one of possible approaches. I wonder what happens, when
retroactive action identifies some critical event (revocation of a certificate)
and data are already grouped. We may end up with some completely redundant data
(if ungrouping is not possible), which in case when several entities (CAs) are
taking role, the scenario gets really ugly.

> should be added as a requirement in the body of the document.

Good and I fully support that this should be mentioned and highlghten at the
very beginning.

---

From: [email-masked]
Date: Wed, 3 Nov 2004 15:05:22 +0100

> vs. the revocation time included in the CRL.  That must be enforced by the

Sure, CRL only defines exact time when revocation occurred. If we could rely
that this happens in the line when CRL is issued (the very same moment) the
problem is solved. At least in theory...

> OK, but a TAS may archive an invalid signature (or evidence of invalidity).

You are absolutely right here and this is another approach, but I guess user of
a "premium" service wants to have attestation of successful archiving ASAP
(next second??), and this is where my questions are targeted to.

---

From: "Carl Wallace" <[email-masked]>
Date: Wed, 3 Nov 2004 09:18:00 -0500

> > immediately after the expiration of each signer's certificate (to 
> > capture revocation events during the entire life of the 
> certificate).
> 
> I am discussing mostly time critical services. I do not know 
> what do you mean exactly here, since the lifetime of a 
> certificate can span for over 5 years and such archival 
> procedure is just not feasible. TAS must provide response in 
> a very short time (I imagine 24 hours is maximum for time 
> critical services).

I meant that collecting the CRL at the end of the certificate lifetime is a
good indication of revocation at any point in time.  Since the focus is
long-term verification, this information may be useful.  It is an extreme
way to deal with synchronization issues across mulitple CAs.  Given the
repeated reference to legislation and lack of technical mechanisms, this
seems to be a significant component of lta policy.

---

From: [email-masked]
Date: Wed, 3 Nov 2004 15:36:50 +0100

> seems to be a significant component of lta policy.

OK, understand and agree on that. But the "premium" service is still a problem.
Some (business) scenarios are build around short lifetimes of documents (e.g.
tax declaration, valid for one year). This approach fails. I thnik we should
expose the problem in some of the documents and at least provide conceptual
approaches (or limitations) to solve them.