Subject: Re: I-D ACTION:draft-ietf-ltans-reqs-03.txt

From: Peter Sylvester <[email-masked]>
Date: Wed, 3 Nov 2004 18:05:22 +0100 (MET)

Denis, 

Since I had send a message to the list that we should carefully
address the points you mention, and that a last call 
is not exactly appropriate, I comment:

Larry has send a message inviting to clarify. 

I thought the ball was in your camp?

Peter

---

From: Peter Sylvester <[email-masked]>
Date: Wed, 3 Nov 2004 19:11:41 +0100 (MET)

> 
> Denis,
> 
> Clearly more than "none of the comments" were addressed.  As noted when the
> draft was posted, this version aimed to address all editorial comments and
> many of the non-editorial comments.  There are several bracketed comments
> included in the new version that highlight particular areas for discussion.
> Several of these are related directly to your comments.   Additionally, a
> set of email responses were sent on 10/5 (along with several other responses
> with questions regarding some of the suggestions).  A large amount of your
> comments were focused on mechanisms.  I was not prepared to shift the focus
> of the requirements document in that direction prior to the deadline for
> publication.  None of your comments are off the table.
> 
> Carl
> 

I had the impression that some of the points may be shifting to the 
notarisation part, by splitting a TAS into a backend archive service that mainly 
provides some reference to data and some front end notarisation that provides 
some appropriate attestation(s). 

Date: Wed, 3 Nov 2004 19:11:41 +0100 (MET)
From: Peter Sylvester <[email-masked]>
To: [email-masked]
Subject: RE: I-D ACTION:draft-ietf-ltans-reqs-03.txt
Sender: [email-masked]

> 
> Denis,
> 
> Clearly more than "none of the comments" were addressed.  As noted when the
> draft was posted, this version aimed to address all editorial comments and
> many of the non-editorial comments.  There are several bracketed comments
> included in the new version that highlight particular areas for discussion.
> Several of these are related directly to your comments.   Additionally, a
> set of email responses were sent on 10/5 (along with several other responses
> with questions regarding some of the suggestions).  A large amount of your
> comments were focused on mechanisms.  I was not prepared to shift the focus
> of the requirements document in that direction prior to the deadline for
> publication.  None of your comments are off the table.
> 
> Carl
> 

I had the impression that some of the points may be shifting to the 
notarisation part, by splitting a TAS into a backend archive service that mainly 
provides some reference to data and some front end notarisation that provides 
some appropriate attestation(s). 

Date: Wed, 3 Nov 2004 19:00:20 +0100 (MET)
From: Peter Sylvester <[email-masked]>
To: [email-masked], [email-masked]
Subject: RE: Discussion of notareqs document
Sender: [email-masked]

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

IMO opinion it doesn't give additional value waiting for a new CRL without 
doing anything in the meantime. If the *impact/effect* of the signatures in question
are not  confronted to the user in some way, a user may not even think about 
the possibility to revoke a cert. (I am talking about a signature
made at distance.)

Then there are also consumer rights with delays. The fact that a signature
has been validated with this or that CRL probably doesn't influence at all
the rights, even if the signature is proven valid, 100% safe or whatever.
(Well the latter was the dream of the banks and merchants).

The user does not have to revoke a cert, he can 'revoke/repudiate' the action
or document. 

Date: Wed, 3 Nov 2004 18:05:22 +0100 (MET)
From: Peter Sylvester <[email-masked]>
To: [email-masked]
Subject: Re: I-D ACTION:draft-ietf-ltans-reqs-03.txt
Cc: [email-masked]
Sender: [email-masked]

Denis, 

Peter

From: "Carl Wallace" <[email-masked]>
To: "'Denis Pinkas'" <[email-masked]>, <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>, "'Russ Housley'" <[email-masked]>
Subject: RE: I-D ACTION:draft-ietf-ltans-reqs-03.txt
Date: Wed, 3 Nov 2004 11:32:19 -0500
Sender: [email-masked]

Denis,

Clearly more than "none of the comments" were addressed.  As noted when the
draft was posted, this version aimed to address all editorial comments and
many of the non-editorial comments.  There are several bracketed comments
included in the new version that highlight particular areas for discussion.
Several of these are related directly to your comments.   Additionally, a
set of email responses were sent on 10/5 (along with several other responses
with questions regarding some of the suggestions).  A large amount of your
comments were focused on mechanisms.  I was not prepared to shift the focus
of the requirements document in that direction prior to the deadline for
publication.  None of your comments are off the table.

Carl

> -----Original Message-----
> From: Denis Pinkas [mailto:[email-masked]] 
> Sent: Wednesday, November 03, 2004 11:17 AM
> To: [email-masked]; [email-masked]; 
> [email-masked]
> Cc: [email-masked]; [email-masked]; Russ Housley
> Subject: Re: I-D ACTION:draft-ietf-ltans-reqs-03.txt
> 
> To the co-editors of draft-ietf-ltans-reqs-03.txt, Copy to 
> the chairman of LTANS, Copy to the Security Area Advisor and Director.
> 
> I observed that none of the comments I posted on the list on 
> October 1, 2004 has been incorporated in the new draft.
> 
> Would you have some explanations to explain why ?
> 
> Denis
> 
> > A New Internet-Draft is available from the on-line 
> Internet-Drafts directories.
> > This draft is a work item of the Long-Term Archive and 
> Notary Services Working Group of the IETF.
> > 
> > 	Title		: Long-Term Archive Service Requirements
> > 	Author(s)	: C. Wallace, et al.
> > 	Filename	: draft-ietf-ltans-reqs-03.txt
> > 	Pages		: 21
> > 	Date		: 2004-10-25
> > 	
> > There are many scenarios in which users must be able to prove the
> >    existence of data at a specific point in time and be able to
> >    demonstrate the integrity of data since that time, even when the
> >    duration from time of existence to time of demonstration spans a
> >    large period of time.  Additionally, users must be able to verify
> >    signatures on digitally signed data many years after the 
> generation
> >    of the signature.  This document describes a class of long-term
> >    archive services to support such scenarios and the technical
> >    requirements for interacting with such services.
> > 
> > A URL for this Internet-Draft is:
> > http://www.ietf.org/internet-drafts/draft-ietf-ltans-reqs-03.txt
> > 
> > To remove yourself from the I-D Announcement list, send a 
> message to 
> > [email-masked] with the word unsubscribe in 
> the body of the message.
> > You can also visit 
> https://www1.ietf.org/mailman/listinfo/I-D-announce
> > to change your subscription settings.
> > 
> > 
> > Internet-Drafts are also available by anonymous FTP. Login 
> with the username
> > "anonymous" and a password of your e-mail address. After logging in,
> > type "cd internet-drafts" and then
> > 	"get draft-ietf-ltans-reqs-03.txt".
> > 
> > A list of Internet-Drafts directories can be found in
> > http://www.ietf.org/shadow.html 
> > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> > 
> > 
> > Internet-Drafts can also be obtained by e-mail.
> > 
> > Send a message to:
> > 	[email-masked].
> > In the body type:
> > 	"FILE /internet-drafts/draft-ietf-ltans-reqs-03.txt".
> > 	
> > NOTE:	The mail server at ietf.org can return the document in
> > 	MIME-encoded form by using the "mpack" utility.  To use this
> > 	feature, insert the command "ENCODING mime" before the "FILE"
> > 	command.  To decode the response(s), you will need "munpack" or
> > 	a MIME-compliant mail reader.  Different MIME-compliant 
> mail readers
> > 	exhibit different behavior, especially when dealing with
> > 	"multipart" MIME messages (i.e. documents which have been split
> > 	up into multiple messages), so check your local documentation on
> > 	how to manipulate these messages.
> > 		
> > 		
> > Below is the data which will enable a MIME compliant mail reader
> > implementation to automatically retrieve the ASCII version of the
> > Internet-Draft.
> 
> 

Date: Wed, 03 Nov 2004 17:17:26 +0100
From: Denis Pinkas <[email-masked]>
Organization: Bull SA.
To: [email-masked], [email-masked], [email-masked]
CC: [email-masked], [email-masked], Russ Housley <[email-masked]>
Subject: Re: I-D ACTION:draft-ietf-ltans-reqs-03.txt
Sender: [email-masked]

To the co-editors of draft-ietf-ltans-reqs-03.txt,
Copy to the chairman of LTANS,
Copy to the Security Area Advisor and Director.

I observed that none of the comments I posted on the list on October 1, 2004 
has been incorporated in the new draft.

Would you have some explanations to explain why ?

Denis

> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> This draft is a work item of the Long-Term Archive and Notary Services Working Group of the IETF.
> 
> 	Title		: Long-Term Archive Service Requirements
> 	Author(s)	: C. Wallace, et al.
> 	Filename	: draft-ietf-ltans-reqs-03.txt
> 	Pages		: 21
> 	Date		: 2004-10-25
> 	
> There are many scenarios in which users must be able to prove the
>    existence of data at a specific point in time and be able to
>    demonstrate the integrity of data since that time, even when the
>    duration from time of existence to time of demonstration spans a
>    large period of time.  Additionally, users must be able to verify
>    signatures on digitally signed data many years after the generation
>    of the signature.  This document describes a class of long-term
>    archive services to support such scenarios and the technical
>    requirements for interacting with such services.
> 
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-ltans-reqs-03.txt
> 
> To remove yourself from the I-D Announcement list, send a message to 
> [email-masked] with the word unsubscribe in the body of the message.  
> You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
> to change your subscription settings.
> 
> 
> Internet-Drafts are also available by anonymous FTP. Login with the username
> "anonymous" and a password of your e-mail address. After logging in,
> type "cd internet-drafts" and then
> 	"get draft-ietf-ltans-reqs-03.txt".
> 
> A list of Internet-Drafts directories can be found in
> http://www.ietf.org/shadow.html 
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> 
> 
> Internet-Drafts can also be obtained by e-mail.
> 
> Send a message to:
> 	[email-masked].
> In the body type:
> 	"FILE /internet-drafts/draft-ietf-ltans-reqs-03.txt".
> 	
> NOTE:	The mail server at ietf.org can return the document in
> 	MIME-encoded form by using the "mpack" utility.  To use this
> 	feature, insert the command "ENCODING mime" before the "FILE"
> 	command.  To decode the response(s), you will need "munpack" or
> 	a MIME-compliant mail reader.  Different MIME-compliant mail readers
> 	exhibit different behavior, especially when dealing with
> 	"multipart" MIME messages (i.e. documents which have been split
> 	up into multiple messages), so check your local documentation on
> 	how to manipulate these messages.
> 		
> 		
> Below is the data which will enable a MIME compliant mail reader
> implementation to automatically retrieve the ASCII version of the
> Internet-Draft.

Date: Wed,  3 Nov 2004 16:58:24 +0100
From: [email-masked]
To: [email-masked], Denis Pinkas <[email-masked]>
Cc: [email-masked]
Subject: Re: XAdES questions
Sender: [email-masked]

As Denis mentioned, there is an activity going on by IETF trying to define
requirments for long term archival services. You may want to have a look at the
current progress and outcomes. Information available at: ltans.edelweb.fr.

Quoting Denis Pinkas <[email-masked]>:

> > Szabo,
>
> > You are absolutely right about the problem and this is why I think
>  > that XAdES is inconsistent at this time. The problem of archiving
>  > can not be solved using implementation such as XAdES, which delivers
>  > only partial solution to the problem. In theory you could rely
>  > on CA policy, which should issue CRLs immediately after a certificate
>  > is revoked and even in this scenario some timeframe remains open for
>  > manipulation. However, please keep in mind that XAdES does not limit
>  > itself to some particular reference data but rather leaves this part
>  > of the signature open (at least to my understanding), which means
>  > that you can use other reference information such as DVCS or OCSP
>  > response and carry over the liability to third party or use the method
>  > as you have suggested bellow. I state again that electronic records
>  > and digital signatures preservation is suppose to stay in hands of
>  > trusted archival services, where you can play around arbitrary
>  > implementation, using several timestamps to archive a full archival
>  > process.
>
> TAS is certainly the solution. I have sent comments on that topic to the
> LTANS WG from the IETF introducing the concept of a "cryptographic
> maintenance policy" that comes separate from the "signature policy" (in fact
> which must take the relay before the signature policy expires, but may also
> be used before the signature policy expires).
>
> Denis
>
>
>
> > Best regards
> >
> > aleksej
> >
> >
> >>-----Original Message-----
> >>From: PLUGTESTS-SECURITY: Discussion list on security
> >>Interoperability matters
> >>[mailto:[email-masked]] On Behalf Of Szabó Áron
> >>Sent: Thursday, October 28, 2004 11:32 AM
> >>To: [email-masked]
> >>Subject: Re: XAdES questions
> >>
> >>Dear Juan Carlos,
> >>
> >>thanks for your comments, they were very useful. I would
> >>react to some of them.
> >>
> >>In connection with "grace period"...
> >>
> >>At "time 0" a CRL has been issued, the next issue is at "time 4".
> >>At "time 1" I request timestamp by generating and sending the
> >>hash (messageImprint).
> >>At "time 2" I create the electronic signature with the
> >>requested timestamp (SigningTime).
> >>At "time 3" I revoke my certificate.
> >>At "time 4" I get the newly issued CRL which contains the
> >>serialNumber of my revoked certificate.
> >>
> >>Between "time 0" and "time 4" (CRL issues) can elapse several
> >>hours. If I want to verify the electronic signature between
> >>"time 2" and "time 4" I cannot decide whether the signature
> >>is good or wrong. You're right, I have to wait until the next
> >>issue of the CRL. But this means, that if I want to create a
> >>XAdES-A archive signature that cannot be good, because that
> >>will always contain the CRL that just have been issued at
> >>"time 0" (but the needed one would be the other one - issued
> >>at "time 4" or later). I could imagine just one solution to
> >>create correct XAdES-A, but I'm afraid this could hardly work...
> >>
> >>step 1: timestamp request for SigningTime step 2: generating
> >>SignatureValue and the whole structure step 3: waiting until
> >>next CRL is issued (i.e. 4 hours) step 4: fetching the newly
> >>issued CRL (after SigningTime) step 5: generating
> >>ArchiveTimeStamp upon all needed data
> >>
> >>In connection with optional attributes of XAdES...
> >>
> >>Why are "Id" and "URI" attributes of elements optional? How
> >>could be referenced i.e. the optional "Id" of the enveloped
> >>data by the optional "URI" of Reference tag? If I understand
> >>well, there is an inconsistency in this question. The
> >>IncludeType of TimeStampType says (i.e. at
> >>ArchiveTimeStamp) that "URI" is "required" to several
> >>included (Include) elements identified by "Id" attribute, but
> >>those "Id" attributes are "optional". It is needed to change
> >>the "optional" flag to "required" at those included elements,
> >>isn't it? Or is there any other way to make references to
> >>those obejcts, tags?
> >>
> >>Best regards,
> >>Aron
> >>
> >>----------------------------------------------------
> >>Aron Szabo, M. Sc.
> >>Research Associate,
> >>Center of Information Technology
> >>Budapest University of Technology and Economics
> >>
> >>Postal code: 1117
> >>Budapest, Hungary
> >>Address: Magyar tudosok krt. 2.
> >>E-mail: [email-masked]
> >>
> >
> >
>

Date: Wed, 3 Nov 2004 16:15:59 +0100 (MET)
From: Peter Sylvester <[email-masked]>
To: [email-masked]
Subject: Re: XAdES questions
Cc: [email-masked]
Sender: [email-masked]

Since Denis mentioned ltans, I think it is worth to forward it to the ltans list. 

----- Begin Included Message -----

Date:         Wed, 3 Nov 2004 15:04:33 +0100
To: "PLUGTESTS-SECURITY: Discussion list on security Interoperability matters" <[email-masked]>
From: Denis Pinkas <[email-masked]>
Subject: Re: XAdES questions
To: [email-masked]

> Szabo,

> You are absolutely right about the problem and this is why I think 
 > that XAdES is inconsistent at this time. The problem of archiving
 > can not be solved using implementation such as XAdES, which delivers
 > only partial solution to the problem. In theory you could rely
 > on CA policy, which should issue CRLs immediately after a certificate
 > is revoked and even in this scenario some timeframe remains open for
 > manipulation. However, please keep in mind that XAdES does not limit
 > itself to some particular reference data but rather leaves this part
 > of the signature open (at least to my understanding), which means
 > that you can use other reference information such as DVCS or OCSP
 > response and carry over the liability to third party or use the method
 > as you have suggested bellow. I state again that electronic records
 > and digital signatures preservation is suppose to stay in hands of
 > trusted archival services, where you can play around arbitrary
 > implementation, using several timestamps to archive a full archival
 > process.

TAS is certainly the solution. I have sent comments on that topic to the 
LTANS WG from the IETF introducing the concept of a "cryptographic 
maintenance policy" that comes separate from the "signature policy" (in fact 
which must take the relay before the signature policy expires, but may also 
be used before the signature policy expires).

Denis

> Best regards
> 
> aleksej
> 
> 
>>-----Original Message-----
>>From: PLUGTESTS-SECURITY: Discussion list on security 
>>Interoperability matters 
>>[mailto:[email-masked]] On Behalf Of Szabó Áron
>>Sent: Thursday, October 28, 2004 11:32 AM
>>To: [email-masked]
>>Subject: Re: XAdES questions
>>
>>Dear Juan Carlos,
>>
>>thanks for your comments, they were very useful. I would 
>>react to some of them.
>>
>>In connection with "grace period"...
>>
>>At "time 0" a CRL has been issued, the next issue is at "time 4".
>>At "time 1" I request timestamp by generating and sending the 
>>hash (messageImprint).
>>At "time 2" I create the electronic signature with the 
>>requested timestamp (SigningTime).
>>At "time 3" I revoke my certificate.
>>At "time 4" I get the newly issued CRL which contains the 
>>serialNumber of my revoked certificate.
>>
>>Between "time 0" and "time 4" (CRL issues) can elapse several 
>>hours. If I want to verify the electronic signature between 
>>"time 2" and "time 4" I cannot decide whether the signature 
>>is good or wrong. You're right, I have to wait until the next 
>>issue of the CRL. But this means, that if I want to create a 
>>XAdES-A archive signature that cannot be good, because that 
>>will always contain the CRL that just have been issued at 
>>"time 0" (but the needed one would be the other one - issued 
>>at "time 4" or later). I could imagine just one solution to 
>>create correct XAdES-A, but I'm afraid this could hardly work...
>>
>>step 1: timestamp request for SigningTime step 2: generating 
>>SignatureValue and the whole structure step 3: waiting until 
>>next CRL is issued (i.e. 4 hours) step 4: fetching the newly 
>>issued CRL (after SigningTime) step 5: generating 
>>ArchiveTimeStamp upon all needed data
>>
>>In connection with optional attributes of XAdES...
>>
>>Why are "Id" and "URI" attributes of elements optional? How 
>>could be referenced i.e. the optional "Id" of the enveloped 
>>data by the optional "URI" of Reference tag? If I understand 
>>well, there is an inconsistency in this question. The 
>>IncludeType of TimeStampType says (i.e. at
>>ArchiveTimeStamp) that "URI" is "required" to several 
>>included (Include) elements identified by "Id" attribute, but 
>>those "Id" attributes are "optional". It is needed to change 
>>the "optional" flag to "required" at those included elements, 
>>isn't it? Or is there any other way to make references to 
>>those obejcts, tags?
>>
>>Best regards,
>>Aron
>>
>>----------------------------------------------------
>>Aron Szabo, M. Sc.
>>Research Associate,
>>Center of Information Technology
>>Budapest University of Technology and Economics
>>
>>Postal code: 1117
>>Budapest, Hungary
>>Address: Magyar tudosok krt. 2.
>>E-mail: [email-masked]
>>
> 
> 

----- End Included Message -----

Date: Wed, 3 Nov 2004 16:09:42 +0100 (MET)
From: Peter Sylvester <[email-masked]>
To: [email-masked], [email-masked]
Subject: RE: Discussion of notareqs document
Sender: [email-masked]

> 
> 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.
> 
I agree with the last sentence.

But a solution may be different than expected similar as with New York's problem
 of horse shit a century ago. :-)

A signature on a paper based income declaration has almost no meaning concerning
security. It is never verified. As soon as you accept to pay taxes according
to what you receive as a "receipt" of your tax declaration, you confirm
yourself the validity of your "signature" which still is not verified but
the fiscal service may only deduce that if they find out that you haven't
declared everything you had "two chances to lie".

A digital signature on a "income declaration" thus seems totally unnecessary,
it is in fact only a means to limit the number of multiple declaration for the
same 'customer', which by each occurence is not a problem because it can
be resolved, but their is the simple interest to limit the number of such cases. 

In all short term scenarios you have some more or less immediate reaction
with 'the customer' who in one or the other way will confirm the validity
of the signature if the transaction is initiated by the customer.

For a 'tax declaration', i.e. the statement from the state ...
someone else can explain the requirements?

Date: Wed, 3 Nov 2004 15:45:30 +0100 (MET)
From: Peter Sylvester <[email-masked]>
To: [email-masked], [email-masked]
Subject: RE: Discussion of notareqs document
Sender: [email-masked]

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

There are several aspects: 

- I think it is not a good statement to say taht one has to prove that 
  a signature was good at some time, but rather that one assert having performed
  a particular validation, and it succeeded. 

- IMO opinion there is no reason to wait for a CRL for example. If a relying party
  just waits, and has no interaction with the user, I don't think that the
  possibility to determine better whether a signature is valid is enhanced.
  If the 'signer' is never be confronted with the signature, no problem will
  be detected, and there is no motivation for revoking a cert. 

- There are context where consumer rights come into action. In this case
  it is important to determine when certain delays start, I am pretty sure that
  is is not sufficient for a relying party to timestamp sopmething in privacy,
  and confront a user after the delay. 
  Within a delay, a user can 'revoke' the document, without revoking his signing
  certificate. 

- Technically the DVCS protocol is neutral about what is actually certified.
  The idea behind a DVCS attestation concerning a 'signed document' is to
  perform the validity checking at some time and provide *ALL* information
  that had been used to do this, i.e., CRLs, OCSP responses, SCVP reponses, 
  DVCS responses, etc. and indicate a time. Anyone in possession of such
  an attestation can perform the same validaton   

  This approach responds to 'keeping track of a validation act' and the 
  provision of all information. One can combine this with a signature in a 
  similar way as the advance signature formats timestamp. The attestation
  asserts more than a time stamp since the attesting entity has actually
  seen a document that corresponds. 

  The notarisation action and the attestation can include an reponse from
  some archiver (I try to avoid the usage of the word "attestation from an archiver")
  because the degree of security (expressed by an security envelope) of this
  archiving attestation may vary, the notarisation could just include
  an unsigned response if archiver and "notariser" are the same entities.

- This usage of a DVCS like service is a bit contrary to the needs of notaries
  where they serve as information reduction entities. But then, it is
  for example possible that one takes the elements described in the previous
  point, archive them, and just return a statement, saying 'All is ok, if
  details are necessary, they have been archived at XXX under reference RRR'.

- Now I don't know what you ask with 'how is the attestation actually generated'?
  At least it seems to be that it can either contain all information or reference
  them. 

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

Such problems occur as a side quark when trying to make a 100% secure signing device
and a requirement of impossibility of non-repudiation. 

I think it is sufficient to determine the validity of a signature *NOW* and then
shift to whatever the transaction processing foresees. Later revocation does not
automatically invalidate the signature i.e. the associated engagement. And a 
successful verification does not inhibit a subsequent repudiation ..

Date: Wed,  3 Nov 2004 15:36:50 +0100
From: [email-masked]
To: [email-masked]
Subject: RE: Discussion of notareqs document
Sender: [email-masked]

Quoting Carl Wallace <[email-masked]>:

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

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.

From: "Carl Wallace" <[email-masked]>
To: <[email-masked]>
Subject: RE: Discussion of notareqs document
Date: Wed, 3 Nov 2004 09:18:00 -0500
Sender: [email-masked]

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

Date: Wed,  3 Nov 2004 15:05:22 +0100
From: [email-masked]
To: [email-masked]
Subject: RE: Discussion of notareqs document
Sender: [email-masked]

Quoting Carl Wallace <[email-masked]>:

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

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

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

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.

Date: Wed,  3 Nov 2004 14:52:26 +0100
From: [email-masked]
To: [email-masked]
Subject: RE: Discussion of notareqs document
Sender: [email-masked]

Quoting Carl Wallace <[email-masked]>:

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

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

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

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

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.

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

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

> > -----Original Message-----
> > From: [email-masked]
> > [mailto:[email-masked]] On Behalf Of [email-masked]
> > Sent: Wednesday, November 03, 2004 5:53 AM
> > To: [email-masked]
> > 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 <[email-masked]>:
> >
> > >
> > > 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,
> > >
> > > 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: "Carl Wallace" <[email-masked]>
To: <[email-masked]>, <[email-masked]>
Subject: RE: Discussion of notareqs document
Date: Wed, 3 Nov 2004 08:30:34 -0500
Sender: [email-masked]

> 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: "Carl Wallace" <[email-masked]>
To: <[email-masked]>, <[email-masked]>
Subject: RE: Discussion of notareqs document
Date: Wed, 3 Nov 2004 07:45:31 -0500
Sender: [email-masked]

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: [email-masked] 
> [mailto:[email-masked]] On Behalf Of [email-masked]
> Sent: Wednesday, November 03, 2004 5:53 AM
> To: [email-masked]
> 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 <[email-masked]>:
> 
> >
> > 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,
> >
> > 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.
> > >
> > >
> > >
> >
> >
> >
> >
> 
> 

Date: Wed,  3 Nov 2004 14:10:04 +0100
From: [email-masked]
To: [email-masked]
Subject: RE: Discussion of notareqs document
Sender: [email-masked]

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: [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,
> >
> > 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.
> > >
> > >
> > >
> >
> >
>
>

Date: Wed,  3 Nov 2004 11:52:30 +0100
From: [email-masked]
To: [email-masked]
Subject: RE: Discussion of notareqs document
Sender: [email-masked]

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 <[email-masked]>:

>
> 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,
>
> 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: "Carl Wallace" <[email-masked]>
To: "'A. Jerman Blazic'" <[email-masked]>, <[email-masked]>
Subject: RE: Discussion of notareqs document
Date: Tue, 2 Nov 2004 08:38:22 -0500
Sender: [email-masked]

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: [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,
> 
> 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]>
To: <[email-masked]>
Subject: RE: Discussion of notareqs document
Date: Mon, 1 Nov 2004 14:12:37 -0500
Importance: Normal
Sender: [email-masked]

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,

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: "A. Jerman Blazic" <[email-masked]>
To: <[email-masked]>
Subject: RE: Discussion of notareqs document
Date: Mon, 1 Nov 2004 19:52:09 +0100
Sender: [email-masked]

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