From owner-ietf-ltans Wed Aug  4 12:16:07 2004
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i74JG76h007805;
	Wed, 4 Aug 2004 12:16:07 -0700 (PDT)
	(envelope-from owner-ietf-ltans@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id i74JG7f5007804;
	Wed, 4 Aug 2004 12:16:07 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f
Received: from relay1.san2.attens.com (relay1.san2.attens.com [192.215.81.74])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i74JG2g3007797
	for <ietf-ltans@imc.org>; Wed, 4 Aug 2004 12:16:02 -0700 (PDT)
	(envelope-from cwallace@orionsec.com)
Received: from wcwallace (0127ahost69.starwoodbroadband.com [12.105.246.69])
	by relay1.san2.attens.com (8.11.6/8.9.3) with ESMTP id i74JFuB22347;
	Wed, 4 Aug 2004 19:15:59 GMT
Message-Id: <200408041915.i74JFuB22347@relay1.san2.attens.com>
From: "Carl Wallace" <cwallace@orionsec.com>
To: "'Ernst G Giessmann'" <ErnstG.Giessmann@t-systems.com>,
        <ietf-ltans@imc.org>
Subject: RE: Comments on LTANS documents
Date: Wed, 4 Aug 2004 15:15:56 -0400
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook, Build 11.0.5510
Thread-Index: AcR0t8I/NNCkKBXHSae6MgqrHkjF/QFn4yuA
In-Reply-To: <4107C240.5090000@t-systems.com>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441
Sender: owner-ietf-ltans@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-ltans/mail-archive/>
List-Unsubscribe: <mailto:ietf-ltans-request@imc.org?body=unsubscribe>
List-ID: <ietf-ltans.imc.org>


<large snip>
> Agree. We must differentiate between searching and 
> retrieving. But it is important to identify unambigously the 
> point of retrieval, otherwise you may get two different 
> documents from two different sources both claiming that they 
> are the archived documents.

Why is it important to unambiguously identify the point of retrieval?  The
point of retrieval might change over time.  Do you mean unambiguously
identify the data object to retrieve?


From owner-ietf-ltans Wed Aug  4 12:57:15 2004
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i74JvFDZ011591;
	Wed, 4 Aug 2004 12:57:15 -0700 (PDT)
	(envelope-from owner-ietf-ltans@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id i74JvF4l011590;
	Wed, 4 Aug 2004 12:57:15 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f
Received: from relay1.san2.attens.com (relay1.san2.attens.com [192.215.81.74])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i74JvFB8011584
	for <ietf-ltans@imc.org>; Wed, 4 Aug 2004 12:57:15 -0700 (PDT)
	(envelope-from cwallace@orionsec.com)
Received: from wcwallace (0127ahost69.starwoodbroadband.com [12.105.246.69])
	by relay1.san2.attens.com (8.11.6/8.9.3) with ESMTP id i74JujB19352;
	Wed, 4 Aug 2004 19:56:46 GMT
Message-Id: <200408041956.i74JujB19352@relay1.san2.attens.com>
From: "Carl Wallace" <cwallace@orionsec.com>
To: "'Denis Pinkas'" <Denis.Pinkas@bull.net>,
        "'IETF LTANS'" <ietf-ltans@imc.org>
Subject: RE: Comments on LTANS documents
Date: Wed, 4 Aug 2004 15:56:45 -0400
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook, Build 11.0.5510
Thread-Index: AcRuLohy/wxuPNXrRNSnLbvhoxCqGwMLPxGQ
In-Reply-To: <40FCCB23.9060709@bull.net>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441
Sender: owner-ietf-ltans@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-ltans/mail-archive/>
List-Unsubscribe: <mailto:ietf-ltans-request@imc.org?body=unsubscribe>
List-ID: <ietf-ltans.imc.org>


Denis,

Thanks for your review of the document set.  We will address your comments
on the archive requirements document in the next version.  A few comments
are in-line below.

Carl

<snip>
> As far as the WHO is concerned, there are:
> 
>     1) the person or the application who did the deposit,
> 
>     2) the persons or the applications allowed to retrieve the data
>        (not necessarily the same as 1))
> 
>     3) the persons or the applications wishing to make sure that
>        some data originates from a given Archiving Unit (Arch-Unit)
>        under the responsibility of a given Archiving Authority
>        (Arch-A) and has been stored by it at a given point of time.
> 
> The difference between the above "players" should be 
> introduced in the documents.

The current text addresses each of 1, 2 and 3 as submitter, retriever and
arbitrator.  There are at least two outstanding roles: folks who can search
and folks who can manage a particular entry in an archive (e.g. shorten the
retention period).
 
<snip>
 
> 
> 3. When a person or an application makes deposit, it is of primary 
> importance that it gets back a "proof of deposit" from an 
> Arch-Unit. In case 
> the deposited data would be lost, then the Arch-A would be 
> responsible from 
> the loss.
> 
> Note that AFNOR has done some work to standardize different 
> kinds of proof, 
> including a "proof of deposit" with a full description of the 
> data structure 
> of that proof using ASN.1. This work should be published soon 
> as an AFNOR 
> Experimental Standard.
> 
> The concept of a "proof of deposit" should be introduced in 
> the documents.

The concept is present in the document in 4.1.1: 

	"Following submission, the service must provide a value that can be
   used to retrieve the archived data and/or associated evidence."

	"The acknowledgement of a successful submission should permit the
   submitter to verify that the correct data was received by the service
   for preservation."

"Proof of deposit" is a more descriptive way to label the concept.

> 
> 4. The deposit is made for a given archiving time period. 
> This period cannot 
> be shortened, unless the person who made the deposit signs a document 
> allowing the Arch-A to do so. In case the person who did the deposit 
> complains later on, then the Arch-A would be able to 
> demonstrate that the 
> archiving period has been shortened.
> 
> This concept should be introduced in the documents.

I don't think the requirements doc (or possibly any of the docs) should
mandate that the submitter is the only entity who should be allowed to
perform this operation.  I agree that concepts related to management of
entries in an archive need to be better addressed.
 
> 
> 5. The documents states that " a long-term archive service 
> provides material 
> needed to demonstrate the existence and integrity of data 
> object". This 
> definition is far from sufficient, since, it is missing two 
> dimensions:
> 
>      1) the fact to demonstrate that the archive was made
>        *at a given time*,

True.

> 
>      2) the fact to demonstrate that the archived data originates
>         *from a given Arch-Unit and Arch-A*.

While there is no subdivision similar to "Arch-Unit" and "Arch-A" in the
doc, the notion of identifying the archive service provider in the evidence
is present in 4.1.1.
 
> A better definition is present in section 4.3.1.
> 
> 
> 6. A major component which is not sufficiently described is 
> the Archive 
> Policy (Arch-Pol). The components of an Arch-Pol should be 
> first identified, 
> before attempting to define any data structure or protocol. 
> Section 4.4.2 
> should grow from 3 lines to one or two pages and should be 
> introduced much 
> earlier in the document.

Agree that elements of policy remain largely unexplored in this group and
need attention.

> 
> 7. One of the several aspects to be developed about the 
> Arch-Pol would be 
> how to relate the Arch-Pol under which the document is 
> retrieved 30 years 
> later to the initial Arch-Pol under which the document has be 
> deposited. 
> These policies cannot be the same, since, for example Time-Stamping 
> Authorities used 30 years later could not be known initially. 
> There may be a 
> chain of Arch-Pol to consider.

For most (all?) pieces of evidence, the notion has been to include the data
in the evidence structure itself (e.g. certs/crls/trust anchors).  Is there
any reason not to treat policy in a similar way?  Policy may be another
"special" type of data similar to trust anchors that an archive must handle.
I don't think using a different (or simply rekeyed) TSA constitutes a change
in policy.  Policy chains may require manual consideration.
 
> 
> 8. One of the several aspects to be developed about the 
> Arch-Pol would be 
> the policy for the "automatic" maintenance of archived data.
> 
> One obvious possibility is to time-stamp the archived data at 
> the time of 
> the deposit. One or more time-stamps tokens (TST) may be 
> applied (more than 
> one time-stamp token is not addressed in the documents).
> 
> For the maintenance of these TSTs, there are then two options:
> 
>      a) apply a new TST before the end of the validity period of the
>         TSU certificate and then capture the CRL of the CA which has
>         produced the TSU certificate in order to demonstrate that the
>         TSU certificate was not revoked at the time the new TST was
>         applied (this point is not addressed in any of the current
>         two documents).
> 
>      b) rely on the Certificate Policy of the CA which has produced
>         the TSU certificate, which will impose a specific 
> protection for
>         the TSU private key (key generation mandatory within 
> a security
>         module and no key export possible, mandatory 
> zeroization of the
>         private key at the end of the private key usage period. Once
>         the TSU certificate has expired, then the private key from the
>         TSU cannot be compromised anymore, except using brute force
>         attacks. In practice, the Archiving Unit will need to capture
>         the revocation status of the TSU certificate (usually a CRL),
>         once the TSU certificate has expired, in order to demonstrate
>         that the TSU certificate was not revoked at the end of the
>         validity period of the TSU certificate (this point is not
>         addressed in any of the current two documents).
> 

I'm not sure this is material that belongs in the requirements document.
Certainly the triggers related to refresh operations (if used) need to be
addressed somewhere - probably in the spec defining the mechanism.   
 
> 9. When an archived data is retrieved, with the proof it was 
> archived at a 
> given time, then the proof that the last TST is still valid has to be 
> produced. In practice this means (for case a) above) that the 
> *current* CRL 
> of the last TSU has to be produced (this point is not 
> addressed in any of 
> the current two documents).

Correct.  Additionally, same thing holds true for trust anchor usage (i.e.
most recent timestamp is validated to a current TA as opposed to historical
TA).  As above, this will most likely be addressed in a specification
document rather than in the requirements document.

<snip>

> 14. Transfer from one archive service to another one may only 
> apply for the 
> same or compatible Archive Policies (Arch-Pol).

Why?  The value of data (or financial standing of the data sponsor) may
change over time such that it is OK to use less rigorous archive methods,
i.e. different and non-compatible policies.  This seems more like a policy
instantiation than something for the the requirements doc.

> 
> 15. Disclosing or not the archived data to the Arch-Unit is 
> an interesting 
> topic. Three cases should be identified:
> 
>      1) the archived data is public data,
> 
>      2) the archived data is private data, and only a hash of it
>         is communicated,

A hash may only be transferred to a TSA but an Arch-Unit/TAA/AS/SAS would
receive or already possess the data (either encrypted or plaintext).

<snip> 
> 16. The documents states "where groups of data objects are submitted, 
> non-repudiation proof [of what ?] must still be available for 
> each archived 
> data separately". This is not a MUST. This MAY be a feature.

Do you mean multi-object submission is a may or the ability to verify each
separately is a may?  I think the statement in the doc is correct.
 
<snip>


From owner-ietf-ltans Thu Aug  5 15:21:05 2004
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i75ML5Ak040677;
	Thu, 5 Aug 2004 15:21:05 -0700 (PDT)
	(envelope-from owner-ietf-ltans@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id i75ML5w9040676;
	Thu, 5 Aug 2004 15:21:05 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f
Received: from host13.websitesource.com (host13.websitesource.com [209.239.35.152])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i75ML42E040670
	for <ietf-ltans@imc.org>; Thu, 5 Aug 2004 15:21:04 -0700 (PDT)
	(envelope-from cwallace@orionsec.com)
Received: from wcwallace (opene-130-129-128-137.ietf60.ietf.org [130.129.128.137])
	by host13.websitesource.com (8.12.10/8.12.10) with ESMTP id i75ML87L000878;
	Thu, 5 Aug 2004 18:21:08 -0400
Message-Id: <200408052221.i75ML87L000878@host13.websitesource.com>
From: "Carl Wallace" <cwallace@orionsec.com>
To: "'Russ Housley \(E-mail\)'" <housley@vigilsec.com>,
        "'IETF LTANS'" <ietf-ltans@imc.org>
Subject: LTANS meeting summary
Date: Thu, 5 Aug 2004 18:21:07 -0400
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_0003_01C47B18.FB19F370"
X-Mailer: Microsoft Office Outlook, Build 11.0.5510
Thread-Index: AcR7OoEDOd4HFJemTly2Lbu1UtEhSg==
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441
Sender: owner-ietf-ltans@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-ltans/mail-archive/>
List-Unsubscribe: <mailto:ietf-ltans-request@imc.org?body=unsubscribe>
List-ID: <ietf-ltans.imc.org>


This is a multi-part message in MIME format.

------=_NextPart_000_0003_01C47B18.FB19F370
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

The LTANS group met on 8/5 from 1:00 to 3:00.  The primary topics of
discussion were Notary Requirements and Long-term Archive Protocol.  

Following a review of document status, Tobias Gondrom provided an
introduction to the Notary Requirements document and presented slides from
Andreas Schmidt highlighting some issues.  John Ross provided information
regarding the work done in OASIS that is relevant to LTANS.  In particular,
the recently published Digital Signature Services specification and work of
the legalXML group were noted.  The legalXML group has a requirements
document that may be of use but is currently in the members-only area of the
OASIS web site.  Russ was asked how to proceed with establishing a working
relationship between the OASIS group and the LTANS group.  The issue will be
raised with the IAB to see if a liason should be established.  Larry led a
review of the notary requirements document.  The requirements will continue
to be discussed on the mailing list prior to circulating a new version of
the document.  The group was asked to provide information regarding notary
requirements in various countries.
	
Tobias presented a diagram describing the functionality of an archive
service.  Carl presented a set of slides provided by Peter Sylvester
regarding the archive protocol.  Framework may be quite similar to work
performed by OASIS (e.g. DSS).  Discussion regarding the protocol questioned
the need for the protocol at all.  Instead, definition of bindings in
various environments should be considered, e.g. WebDAV, JSR170.  

The primary actions before the next IETF meeting are: investigation of OASIS
work, review of notary requirements (e.g. from legalXML, mailing list),
consideration of dropping protocol in favor of bindings to specific
technologies.

Carl and Tobias




------=_NextPart_000_0003_01C47B18.FB19F370
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
6.5.7036.0">
<TITLE>LTANS meeting summary</TITLE>
</HEAD>
<BODY>
<!-- Converted from text/rtf format -->

<P><FONT SIZE=3D2 FACE=3D"Arial">The LTANS group met on 8/5 from 1:00 to =
3:00.&nbsp; The primary topics of discussion were Notary Requirements =
and Long-term Archive Protocol.&nbsp; </FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Following a review of document status, =
Tobias Gondrom provided an introduction to the Notary Requirements =
document and presented slides from Andreas Schmidt highlighting some =
issues.&nbsp; John Ross provided information regarding the work done in =
OASIS that is relevant to LTANS.&nbsp; In particular, the recently =
published Digital Signature Services specification and work of the =
legalXML group were noted.&nbsp; The legalXML group has a requirements =
document that may be of use but is currently in the members-only area of =
the OASIS web site.&nbsp; Russ was asked how to proceed with =
establishing a working relationship between the OASIS group and the =
LTANS group.&nbsp; The issue will be raised with the IAB to see if a =
liason should be established.&nbsp; Larry led a review of the notary =
requirements document.&nbsp; The requirements will continue to be =
discussed on the mailing list prior to circulating a new version of the =
document.&nbsp; The group was asked to provide information regarding =
notary requirements in various countries.</FONT></P>

<P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20

<BR><FONT SIZE=3D2 FACE=3D"Arial">Tobias presented a diagram describing =
the functionality of an archive service.&nbsp; Carl presented a set of =
slides provided by Peter Sylvester regarding the archive protocol.&nbsp; =
Framework may be quite similar to work performed by OASIS (e.g. =
DSS).&nbsp; Discussion regarding the protocol questioned the need for =
the protocol at all.&nbsp; Instead, definition of bindings in various =
environments should be considered, e.g. WebDAV, JSR170.&nbsp; =
</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">The primary actions before the next =
IETF meeting are: investigation of OASIS work, review of notary =
requirements (e.g. from legalXML, mailing list), consideration of =
dropping protocol in favor of bindings to specific =
technologies.</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Carl and Tobias</FONT>
</P>
<BR>
<BR>

</BODY>
</HTML>
------=_NextPart_000_0003_01C47B18.FB19F370--


From owner-ietf-ltans Fri Aug 13 10:28:58 2004
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i7DHSwXq041615;
	Fri, 13 Aug 2004 10:28:58 -0700 (PDT)
	(envelope-from owner-ietf-ltans@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id i7DHSwOV041614;
	Fri, 13 Aug 2004 10:28:58 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f
Received: from mucmx01.ixos.de (mucmx01.ixos.de [149.235.31.89])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i7DHSu2c041604
	for <ietf-ltans@imc.org>; Fri, 13 Aug 2004 10:28:56 -0700 (PDT)
	(envelope-from tobias@ixos.de)
Received: from muc-imc.ixos.de (localhost [127.0.0.1])
	by mucmx01.ixos.de (8.12.9/8.12.9) with ESMTP id i7DHStE3003752;
	Fri, 13 Aug 2004 19:28:55 +0200 (MEST)
Received: by muc_mx.ixos.de with Internet Mail Service (5.5.2657.72)
	id <P64L4GWN>; Fri, 13 Aug 2004 19:29:20 +0200
Message-ID: <3C1BE8610E44734499EF92FB35F5B07017D5E6@MUCXGC1.opentext.net>
From: Tobias Gondrom <tobias@ixos.de>
To: "'IETF LTANS'" <ietf-ltans@imc.org>
Cc: Carl Wallace <cwallace@orionsec.com>
Subject: FW: LTANS: minutes and presentations from meeting in San Diego
Date: Fri, 13 Aug 2004 19:28:16 +0200
Importance: high
X-Priority: 1
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
Content-Type: multipart/mixed;
	boundary="----_=_NextPart_000_01C4815A.EBCF4E23"
Sender: owner-ietf-ltans@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-ltans/mail-archive/>
List-Unsubscribe: <mailto:ietf-ltans-request@imc.org?body=unsubscribe>
List-ID: <ietf-ltans.imc.org>


This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_000_01C4815A.EBCF4E23
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C4815A.EBCF4E23"


------_=_NextPart_001_01C4815A.EBCF4E23
Content-Type: text/plain

Hello,

 

Unfortunately I tried to send the presentation with the mail the first time
and it got stuck in a filter for emails that are too big. (it was only about
200kB) 

So I send now only the minutes and asked Peter to publish the Presentations
as soon as possible on our web page:

http://ltans.edelweb.fr <http://ltans.edelweb.fr/> 

 

best regards

 

            Tobias

            Chair of LTANS

 

 

  _____  

From: Tobias Gondrom 
Sent: Thursday, August 12, 2004 12:43 PM
To: 'IETF LTANS'
Subject: LTANS: minutes and presentations from meeting in San Diego

 

Hello,

 

Attached are the minutes and presentations from our WG meeting in San Diego.

 

Best regards

 

            Tobias

            Chair of LTANS

 


------_=_NextPart_001_01C4815A.EBCF4E23
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" =
xmlns:o=3D"urn:schemas-microsoft-com:office:office" =
xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:st1=3D"urn:schemas-microsoft-com:office:smarttags" =
xmlns=3D"http://www.w3.org/TR/REC-html40">

<head>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">


<meta name=3DGenerator content=3D"Microsoft Word 11 (filtered medium)">
<!--[if !mso]>
<style>
v\:* {behavior:url(#default#VML);}
o\:* {behavior:url(#default#VML);}
w\:* {behavior:url(#default#VML);}
.shape {behavior:url(#default#VML);}
</style>
<![endif]--><o:SmartTagType
 namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags" =
name=3D"City"/>
<o:SmartTagType =
namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"
 name=3D"place"/>
<!--[if !mso]>
<style>
st1\:*{behavior:url(#default#ieooui) }
</style>
<![endif]-->
<style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman";}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{color:purple;
	text-decoration:underline;}
p
	{mso-margin-top-alt:auto;
	margin-right:0in;
	mso-margin-bottom-alt:auto;
	margin-left:0in;
	font-size:12.0pt;
	font-family:"Times New Roman";}
span.EmailStyle18
	{mso-style-type:personal;
	font-family:Arial;
	color:windowtext;}
span.EmailStyle19
	{mso-style-type:personal-reply;
	font-family:Arial;
	color:navy;}
@page Section1
	{size:8.5in 11.0in;
	margin:1.0in 1.25in 1.0in 1.25in;}
div.Section1
	{page:Section1;}
-->
</style>
<!--[if gte mso 9]><xml>
 <o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
 <o:shapelayout v:ext=3D"edit">
  <o:idmap v:ext=3D"edit" data=3D"1" />
 </o:shapelayout></xml><![endif]-->
</head>

<body lang=3DEN-US link=3Dblue vlink=3Dpurple>

<div class=3DSection1>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>Hello,<o:p></o:p></span></font></p>=


<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>=


<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>Unfortunately I tried to send the
presentation with the mail the first time and it got stuck in a filter =
for
emails that are too big. (it was only about 200kB) =
<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>So I send now only the minutes and =
asked
Peter to publish the Presentations as soon as possible on our web =
page:<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'><a =
href=3D"http://ltans.edelweb.fr/">http://ltans.edelweb.fr</a><o:p></o:p>=
</span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>=


<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>best =
regards<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>=


<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Tobias<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Chair of LTANS<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>=


<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>=


<div>

<div class=3DMsoNormal align=3Dcenter style=3D'text-align:center'><font =
size=3D3
face=3D"Times New Roman"><span style=3D'font-size:12.0pt'>

<hr size=3D2 width=3D"100%" align=3Dcenter tabindex=3D-1>

</span></font></div>

<p class=3DMsoNormal><b><font size=3D2 face=3DTahoma><span =
style=3D'font-size:10.0pt;
font-family:Tahoma;font-weight:bold'>From:</span></font></b><font =
size=3D2
face=3DTahoma><span style=3D'font-size:10.0pt;font-family:Tahoma'> =
Tobias Gondrom <br>
<b><span style=3D'font-weight:bold'>Sent:</span></b> Thursday, August =
12, 2004
12:43 PM<br>
<b><span style=3D'font-weight:bold'>To:</span></b> 'IETF LTANS'<br>
<b><span style=3D'font-weight:bold'>Subject:</span></b> LTANS: minutes =
and
presentations from meeting in <st1:place w:st=3D"on"><st1:City =
w:st=3D"on">San
  Diego</st1:City></st1:place></span></font><o:p></o:p></p>

</div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>Hello,<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>Attached are the minutes and presentations from our =
WG
meeting in <st1:place w:st=3D"on"><st1:City w:st=3D"on">San =
Diego</st1:City></st1:place>.<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>Best regards<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;
Tobias<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;
Chair of LTANS<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'><o:p>&nbsp;</o:p></span></font></p>

</div>

</body>

</html>

------_=_NextPart_001_01C4815A.EBCF4E23--

------_=_NextPart_000_01C4815A.EBCF4E23
Content-Type: text/plain;
	name="ltans_meeting_minutes.txt"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment;
	filename="ltans_meeting_minutes.txt"

The LTANS WG met on 8/5 from 1:00PM to 3:00PM PDT.  Approximately 30 =
people attended the meeting. =20

Introduction/Administrivia/Status/etc. (Tobias Gondrom)	               =
-  5 Min.

A. Notary Requirements
1. Opening Presentation of Notary Reqs (Tobias) 	               - 15 =
Min.
2. Further presentations of notary reqs/ideas (Tobias) 	               =
- 10 Min.
	2.1 from Andreas Schmidt (Tobias)			       -  5 Min.
	2.2 OASIS (John Ross)					       - 10 Min.
3. Discussion of notary requirements doc (Larry Masinter)              =
- 30 Min.

B. Long-term Archive Protocol
1. Operation of an Archive Service (Tobias)		               - 10 Min.
2. Presentation of protocol draft from Peter Sylvester (Carl Wallace)  =
- 15 Min.
3. Discussion (Carl & Tobias) 					       - 20 Min.

Introduction/Status
- Tobias discussed document status.  Noted that Long-term Archive =
Requirements and ERS are stable.  Last Call for the Long-Term Archive =
Requirements document is planned for late August.  The Long-term =
Archive Protocol is not yet published.  Notary requirements are in =
early stages.  All documents are behind schedule.


A. Notary Requirements
1. Opening Presentation of Notary Reqs (Tobias)=20
- Tobias provided an overview of notary service functionality as =
described in initial requirements document and noted that a notary =
cannot function without trust (i.e. trust in the human behind the =
service).
- Notary functions were defined as follows: record transactions, record =
events, certification of copy documents, administering of oaths, =
attestation and certification of events.


2. Further presentations of notary reqs/ideas
2.1 from Andreas Schmidt (Tobias)
- Tobias presented slides on behalf of Andreas Schmidt, who is now a =
co-author of the notary requirements document. =20
- Identified the need to address varying legal constructions in various =
countries.  This important enough that it must be addressed in the =
requirements.
- Noted that paper notarization is outside of scope.  Larry pointed out =
that there are several IETF protocols that address paper, including =
internet fax. =20
- Notes that E2E (Electronic-to-electronic) transformations are a core =
functionality of notary services.
- Notion of a "transformation seal" was introduced. =20
- Is catalog of data formats and their suitability for transformation =
out of scope?
- Human inspection may not be avoidable.


2.2 OASIS (John Ross)
- Introduced activities in OASIS relevant to LTANS: Digital Signature =
Services (DSS) and legalXML.  legalXML defines the data structures for =
court filings, for example.  In particular, the human interaction is =
addressed.  DSS defines a generic framework for server-based signature =
generation and verification. =20
- Noted that it is difficult to come up with one solution for =
notarization due to differences in various jurisdictions.  Security =
aspects as separated from the data aspects to define a flexible =
solution that can be adapted from community to community to meet the =
various notarization requirements. =20
- Perhaps a means of working together could be established.  The group =
meets every two weeks with participants phoning in from a variety of =
locations.  Group has some face-to-face meetings and significant degree =
of participation. =20
- There are two documents recently released for comment: DSS Core =
Protocols, Elements and Bindings; XML Timestamping DSS Profile.
- These documents support CMS, XML DSIG and RFC 3161.
- Additionally, there is a requirements document and an FAQ available =
on the group's website.
- Other profiles are nearly ready for publication, including XADES, =
German signature law, Electronic Post Mark (EPM), code signing, =
asynchronous operation, entity seal, policy wise operation and web =
services security.
- OASIS participation requires membership (~$200 for individual =
membership).
- The group is interested in making sure that work done by LTANS is =
complementary and consistent with OASIS work, e.g. make sure there is =
one standard that is adopted. =20
- XADES is the profile related to long-term archive.  It is an XML equiv=
alent of RFC3126.
- Russ was asked if working with OASIS would be a problem.  Resolution =
is to raise issue to IAB and establish a liason.


3. Discussion about proceeding with notary work (Larry Masinter)
- Larry led a discussion of the notary requirements draft. =20
- Initial comments noted issues with the first paragraph, i.e. =
Wikipedia reference for notary definition.  The text needs work to =
establish a global scope for notarization.  Clarification that the =
initial text is not aiming to provide definitions but is simply trying =
to provide some context for the scope is necessary.
- Folks were requested to provide info regarding notary function in =
their parts of the world to the mailing list.
- It was discussed how far OASIS has already available standard for =
notary services: Currently nothing specific, the information related to =
notarization is carried data payload in OASIS, DSS is simply the =
sealing mechanism.
OASIS wants to provide input to the mailinglist (their "legalXML group" =
has possibly a requirements document)
- Discussed must/may/should text in requirements documents.  Next =
version will feature softer uses of such terms.
- Tobias solicited use cases from participants.  What services would be =
required to satisfy notary functions globally.
- In Norway, government acts as a notary.  It's not really a trusted =
third party.  It's trusted by the population, i.e. Norwegians trust =
their government.  The transactions are primarily between individual =
and the government.  Transactions between individuals are notarized by =
private notaries.
- It was noted that it is difficult to imagine that governments =
anywhere require a third party.  Larry pointed out that agencies rely =
on other agencies, which is a similar, e.g. the postal service provides =
a postmark that other agencies rely upon.
- The transaction set specified in the requirments document was =
reviewed.  An open question is what are the kinds of transactions and =
services that must be offered by a notary?  Some in the current list =
may not be suitable, e.g. administration of oaths.  It was suggested =
that the administration of oaths may accumulate more differences than =
some other use cases.
- Section 4 provides the meat of the document.  Editorially the sub-sub =
sections will probably go away since everything is a functional =
requirement. =20
- A review of must/may/should is in order.  The initial draft included =
such terms primarily to elicit opinion.
- Authentication may simply be required in order to exercise a notary.
In some cases the notary needs authentication only to aquire his =
payment, thus not _all_ services may need authentication.
- "Provide services" needs to be made more explicit.  Current text is =
too vague.  How to demonstrate trust?  Perhaps by demonstrating that =
you are someone with a long history of trust.  Does long history of =
trust demonstrate trust?  Demonstration of trust may be outside of =
scope.  Bonding is an example.  The term "trust" is maybe to vague.  =
Replace with notions like proof of identity.
- It's kind of like PGP web of trust.
- The "Operation" requirement is not a protocol requirement but is a =
service requirement.  For example, the notary must know how to perform =
his duties.  How to demonstrate that the notary system is under the =
control of the notary?  Perhaps some certified programs or evaluation =
to support such.  The requirement seems to indicate that someone is =
certified as a notary.  Is this necessary in internet environment?
- In France, notaries are certified for specific purposes after going =
through some legal exercise related to that purpose.  Perhaps a notary =
protocol could provide an indication as to whether there was a human =
notary involved, what the notary is authorized for, who authorized the =
notary, etc.
- The term "notary office" is not defined.

- What is the language for expressing notary capabilities?  There =
should be profiles for notary functions (maybe like OASIS DSS =
profiles).
- For some notarization requirements, there is not a confidentiality =
requirement.  In some cases there may actually be a publicity =
requirement, i.e. notaries that only handle public documents.
- The "Operational Considerations" and "Security Considerations" are =
incomplete.  The Operational Considerations sections needs to address =
topics like access control to the notary itself, denial of service =
attacks that prevent proper service.  The Security Considerations =
sections needs to include a threat analysis and mitigations of those =
threats.  These sections are essentially placeholders.
- Tobias noted that it is not clear to him that there is a need for =
notary services.  The reason for producing the requirements document =
was to elicit input regarding whether such things are needed.  One =
opinion was noted that the group should proceed with notary service =
work owing to the legal challenges and associated technical challenges. =
=20
- John Ross noted that in OASIS some general characteristics had been =
assembled from various requirements from different countries.  Most of =
there research was collected from the legalXML group (i.e. =
non-technical legal folks) to identify the requirements for the =
protocol.  The OASIS group has concentrated on the what is required for =
the seal.
- The entity seal profile from OASIS is the applicable profile (when =
available).
- Show of hands yielded no one supporting notary service protocols, =
some folks who felt the group should not proceed with such work.  =
Probably more "not sures" in the crowd.
- Would real notaries want to replace current practices with IETF =
equivalent?
- Service is only valuable if it is legally honored.
- Is there a way to address such things in a way similar to CA =
policies?

B Long-term Archive Protocol
1. Operation of an Archive Service (Tobias)
- Should there be search functionality? Should there be management of =
attributes?  How much should we stray into content management?
- Discussed the various transactions: submission, retrieval, deletion, =
transfer. =20
- Discussed the functionality that should be provided by an archive =
service. =20

2. Presentation of protocol draft from Peter Sylvester (Carl Wallace)
3. Discussion (Carl & Tobias)
- The possibility of dropping the protocol in favor of bindings to =
existing mechanisms, e.g. WebDAV, was raised.  In particular, this =
would avoid reinventing the wheel for things like searching.
- MIME headers are important component to solution.  For example, =
define a mulitpart archive type.
- May want to access the parts separately. =20
- There were questions as to whether content type info should be =
included in the protocol.  There were opinions for an against.  Future =
clients may not support MIME or the types indicated by the type.  =
Providing a hint is probably preferrable to not providing type.  The =
time of origin and time of archiving may be important clues for =
determing appropriate handler for data at points well into the future.
- Tobias noted that proof of integrity/non-repudiation is the service =
provided by the archive service, e.g. over a blob.  The payload could =
be XML signature, CMS signature or unsigned. =20
- The group will consider dropping the protocol specification as it is =
currently considered and instead focusing on defining bindings between =
evidence data and data, e.g. for WebDAV.

 =09

Action items
- Investigate establishing liason with OASIS group
- Collect details of notary operation from various countries from list =
participants
- Solicit comments on the notary requirements
- Discuss need for archive protocol vs. alternative means.  =
Investigate, in particular, use of WebDAV.
------_=_NextPart_000_01C4815A.EBCF4E23--


From owner-ietf-ltans Tue Aug 17 23:26:44 2004
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i7I6Qi8o068627;
	Tue, 17 Aug 2004 23:26:44 -0700 (PDT)
	(envelope-from owner-ietf-ltans@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id i7I6QicY068626;
	Tue, 17 Aug 2004 23:26:44 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f
Received: from psmtp.com (exprod6ob1.obsmtp.com [12.158.35.211])
	by above.proper.com (8.12.11/8.12.9) with SMTP id i7I6Qhk8068619
	for <ietf-ltans@imc.org>; Tue, 17 Aug 2004 23:26:43 -0700 (PDT)
	(envelope-from LMM@acm.org)
Received: from source ([192.150.22.8]) by exprod6ob1.obsmtp.com ([12.158.35.250]) with SMTP;
	Tue, 17 Aug 2004 23:26:43 PDT
Received: from inner-relay-3.corp.adobe.com (inner-relay-3 [153.32.251.51])
	by smtp-relay-8.adobe.com (8.12.10/8.12.10) with ESMTP id i7I6QRJI019759
	for <ietf-ltans@imc.org>; Tue, 17 Aug 2004 23:26:32 -0700 (PDT)
Received: from calsj-dev (calsj-dev.corp.adobe.com [153.32.1.193])
	by inner-relay-3.corp.adobe.com (8.12.9/8.12.9) with ESMTP id i7I6QRkq009677
	for <ietf-ltans@imc.org>; Tue, 17 Aug 2004 23:26:27 -0700 (PDT)
Received: from MasinterT40 ([130.248.176.4]) by mailsj-v1.corp.adobe.com
 (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep  8 2003))
 with ESMTP id <0I2M000T0PVYV1@mailsj-v1.corp.adobe.com> for
 ietf-ltans@imc.org; Tue, 17 Aug 2004 23:26:27 -0700 (PDT)
Date: Tue, 17 Aug 2004 23:25:55 -0700
From: Larry Masinter <LMM@acm.org>
Subject: MD5, SHA-0
To: "'IETF LTANS'" <ietf-ltans@imc.org>
Message-id: <0I2M000T7PVZV1@mailsj-v1.corp.adobe.com>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1441
X-Mailer: Microsoft Office Outlook, Build 11.0.6353
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7BIT
Thread-index: AcSE7Decf9bkaedGQXu6y0t6EalCLg==
Sender: owner-ietf-ltans@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-ltans/mail-archive/>
List-Unsubscribe: <mailto:ietf-ltans-request@imc.org?body=unsubscribe>
List-ID: <ietf-ltans.imc.org>


It's sometimes hard to discern technical details in news
articles. Anyone have a more reliable source on what
happened at Crypto 2004?

http://news.com.com/Crypto+researchers+abuzz+over+flaws/2100-1002_3-5313655.
html

I still haven't understood, for notary services, if
the notary service doesn't have the original document
but just the hash, what happens when the hash algorithm
is compromised?

Larry
-- 
http://larry.masinter.net


From owner-ietf-ltans Mon Aug 23 13:26:25 2004
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i7NKQO3i031246;
	Mon, 23 Aug 2004 13:26:24 -0700 (PDT)
	(envelope-from owner-ietf-ltans@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id i7NKQOxY031245;
	Mon, 23 Aug 2004 13:26:24 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f
Received: from host13.websitesource.com (host13.websitesource.com [209.239.35.152])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i7NKQOW0031235
	for <ietf-ltans@imc.org>; Mon, 23 Aug 2004 13:26:24 -0700 (PDT)
	(envelope-from chokhani@orionsec.com)
Received: from wchokhani3 (dpvc-138-88-161-20.res.east.verizon.net [138.88.161.20])
	by host13.websitesource.com (8.12.10/8.12.10) with ESMTP id i7NKQOod022970;
	Mon, 23 Aug 2004 16:26:24 -0400
From: "Santosh Chokhani" <chokhani@orionsec.com>
To: "'Larry Masinter'" <LMM@acm.org>, "'IETF LTANS'" <ietf-ltans@imc.org>
Subject: RE: MD5, SHA-0
Date: Mon, 23 Aug 2004 16:26:24 -0400
Message-ID: <000501c4894f$75b081a0$9a00a8c0@hq.orionsec.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.6626
Importance: Normal
In-Reply-To: <0I2M000T7PVZV1@mailsj-v1.corp.adobe.com>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i7NKQOW0031240
Sender: owner-ietf-ltans@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-ltans/mail-archive/>
List-Unsubscribe: <mailto:ietf-ltans-request@imc.org?body=unsubscribe>
List-ID: <ietf-ltans.imc.org>


Larry:

The initial reading is that SHA-1 is relatively safe, but people should move
to SHA 256 within next 5 years.

That said, LTANS does need to worry about what happens if the notary has the
hash of the document.  If the hash gets broken, it dilutes the document
existence claim.

I think one alternative is to use the encrypt scheme as ERS folks have
proposed for trusted archive.  Of course, the caveats in the ERS encryption
paper will apply.

-----Original Message-----
From: owner-ietf-ltans@mail.imc.org [mailto:owner-ietf-ltans@mail.imc.org]
On Behalf Of Larry Masinter
Sent: Wednesday, August 18, 2004 2:26 AM
To: 'IETF LTANS'
Subject: MD5, SHA-0



It's sometimes hard to discern technical details in news articles. Anyone
have a more reliable source on what happened at Crypto 2004?

http://news.com.com/Crypto+researchers+abuzz+over+flaws/2100-1002_3-5313655.
html

I still haven't understood, for notary services, if
the notary service doesn't have the original document
but just the hash, what happens when the hash algorithm
is compromised?

Larry
-- 
http://larry.masinter.net



From owner-ietf-ltans Wed Aug 25 01:15:34 2004
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i7P8FYfx039473;
	Wed, 25 Aug 2004 01:15:34 -0700 (PDT)
	(envelope-from owner-ietf-ltans@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id i7P8FYV1039472;
	Wed, 25 Aug 2004 01:15:34 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i7P8FVEn039436
	for <ietf-ltans@imc.org>; Wed, 25 Aug 2004 01:15:33 -0700 (PDT)
	(envelope-from Denis.Pinkas@bull.net)
Received: from clbull.frcl.bull.fr (IDENT:root@clbull.frcl.bull.fr [129.182.8.31])
	by odin2.bull.net (8.9.3/8.9.3) with ESMTP id KAA59412;
	Wed, 25 Aug 2004 10:26:15 +0200
Received: from bull.net (frcls4013.frcl.bull.fr [129.182.108.120])
	by clbull.frcl.bull.fr (8.9.3/8.9.3) with ESMTP id KAA15048;
	Wed, 25 Aug 2004 10:05:37 +0200
Message-ID: <412C4A09.1030407@bull.net>
Date: Wed, 25 Aug 2004 10:12:57 +0200
From: Denis Pinkas <Denis.Pinkas@bull.net>
Organization: Bull SA.
User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0
X-Accept-Language: en-us, en, fr
MIME-Version: 1.0
To: Santosh Chokhani <chokhani@orionsec.com>
CC: "'IETF LTANS'" <ietf-ltans@imc.org>
Subject: Re: MD5, SHA-0
References: <000501c4894f$75b081a0$9a00a8c0@hq.orionsec.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-ietf-ltans@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-ltans/mail-archive/>
List-Unsubscribe: <mailto:ietf-ltans-request@imc.org?body=unsubscribe>
List-ID: <ietf-ltans.imc.org>


Santosh,

> Larry:
> 
> The initial reading is that SHA-1 is relatively safe, but people should move
> to SHA 256 within next 5 years.
> 
> That said, LTANS does need to worry about what happens if the notary has the
> hash of the document.  If the hash gets broken, it dilutes the document
> existence claim.

No. Apply a new time-stamp token with a new hash function.

> I think one alternative is to use the encrypt scheme as ERS folks have
> proposed for trusted archive.  Of course, the caveats in the ERS encryption
> paper will apply.

Avoid any kind of encryption for that purpose.

Denis

> -----Original Message-----
> From: owner-ietf-ltans@mail.imc.org [mailto:owner-ietf-ltans@mail.imc.org]
> On Behalf Of Larry Masinter
> Sent: Wednesday, August 18, 2004 2:26 AM
> To: 'IETF LTANS'
> Subject: MD5, SHA-0
> 
> 
> 
> It's sometimes hard to discern technical details in news articles. Anyone
> have a more reliable source on what happened at Crypto 2004?
> 
> http://news.com.com/Crypto+researchers+abuzz+over+flaws/2100-1002_3-5313655.
> html
> 
> I still haven't understood, for notary services, if
> the notary service doesn't have the original document
> but just the hash, what happens when the hash algorithm
> is compromised?
> 
> Larry



From owner-ietf-ltans Wed Aug 25 03:42:19 2004
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i7PAgJvs080955;
	Wed, 25 Aug 2004 03:42:19 -0700 (PDT)
	(envelope-from owner-ietf-ltans@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id i7PAgJak080954;
	Wed, 25 Aug 2004 03:42:19 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f
Received: from host13.websitesource.com (host13.websitesource.com [209.239.35.152])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i7PAgJ8G080930
	for <ietf-ltans@imc.org>; Wed, 25 Aug 2004 03:42:19 -0700 (PDT)
	(envelope-from cwallace@orionsec.com)
Received: from wcwallace (dpvc-138-88-161-20.res.east.verizon.net [138.88.161.20])
	by host13.websitesource.com (8.12.10/8.12.10) with ESMTP id i7PAgHod032208
	for <ietf-ltans@imc.org>; Wed, 25 Aug 2004 06:42:17 -0400
Message-Id: <200408251042.i7PAgHod032208@host13.websitesource.com>
From: "Carl Wallace" <cwallace@orionsec.com>
To: "'IETF LTANS'" <ietf-ltans@imc.org>
Subject: RE: MD5, SHA-0
Date: Wed, 25 Aug 2004 06:42:17 -0400
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook, Build 11.0.5510
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441
In-Reply-To: <412C4A09.1030407@bull.net>
Thread-Index: AcSKfYT985ePK1amTgWCgfEoyYAoggAEj4nw
Sender: owner-ietf-ltans@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-ltans/mail-archive/>
List-Unsubscribe: <mailto:ietf-ltans-request@imc.org?body=unsubscribe>
List-ID: <ietf-ltans.imc.org>


> > That said, LTANS does need to worry about what happens if 
> the notary 
> > has the hash of the document.  If the hash gets broken, it 
> dilutes the 
> > document existence claim.
> 
> No. Apply a new time-stamp token with a new hash function.

For what data should a new time-stamp token based on a new hash function be
obtained?  In this thread, the question related to the case where the notary
has only a hash of the original document.


From owner-ietf-ltans Wed Aug 25 04:20:21 2004
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i7PBKLUT089216;
	Wed, 25 Aug 2004 04:20:21 -0700 (PDT)
	(envelope-from owner-ietf-ltans@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id i7PBKLOn089215;
	Wed, 25 Aug 2004 04:20:21 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f
Received: from host13.websitesource.com (host13.websitesource.com [209.239.35.152])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i7PBKKHS089209
	for <ietf-ltans@imc.org>; Wed, 25 Aug 2004 04:20:20 -0700 (PDT)
	(envelope-from chokhani@orionsec.com)
Received: from wchokhani3 (pcp09271907pcs.arlngt01.va.comcast.net [69.143.130.247])
	by host13.websitesource.com (8.12.10/8.12.10) with ESMTP id i7PBKLod009706
	for <ietf-ltans@imc.org>; Wed, 25 Aug 2004 07:20:21 -0400
From: "Santosh Chokhani" <chokhani@orionsec.com>
To: "'IETF LTANS'" <ietf-ltans@imc.org>
Subject: RE: MD5, SHA-0
Date: Wed, 25 Aug 2004 07:20:15 -0400
Message-ID: <004001c48a95$82492b50$aa02a8c0@hq.orionsec.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.6626
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441
In-Reply-To: <412C4A09.1030407@bull.net>
Sender: owner-ietf-ltans@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-ltans/mail-archive/>
List-Unsubscribe: <mailto:ietf-ltans-request@imc.org?body=unsubscribe>
List-ID: <ietf-ltans.imc.org>


Carl, Denis:

My response was terse.  I assumed that the question was prompted with when
the Notary is given only the hash in the first place for the reasons of
confidentiality.

Thus, I was proposing that to preserve the confidentiality desired b the
submitter, we look into ERS encryption approach.

-----Original Message-----
From: Denis Pinkas [mailto:Denis.Pinkas@bull.net] 
Sent: Wednesday, August 25, 2004 4:13 AM
To: Santosh Chokhani
Cc: 'IETF LTANS'
Subject: Re: MD5, SHA-0


Santosh,

> Larry:
> 
> The initial reading is that SHA-1 is relatively safe, but people 
> should move to SHA 256 within next 5 years.
> 
> That said, LTANS does need to worry about what happens if the notary 
> has the hash of the document.  If the hash gets broken, it dilutes the 
> document existence claim.

No. Apply a new time-stamp token with a new hash function.

> I think one alternative is to use the encrypt scheme as ERS folks have 
> proposed for trusted archive.  Of course, the caveats in the ERS 
> encryption paper will apply.

Avoid any kind of encryption for that purpose.

Denis

> -----Original Message-----
> From: owner-ietf-ltans@mail.imc.org 
> [mailto:owner-ietf-ltans@mail.imc.org]
> On Behalf Of Larry Masinter
> Sent: Wednesday, August 18, 2004 2:26 AM
> To: 'IETF LTANS'
> Subject: MD5, SHA-0
> 
> 
> 
> It's sometimes hard to discern technical details in news articles. 
> Anyone have a more reliable source on what happened at Crypto 2004?
> 
> http://news.com.com/Crypto+researchers+abuzz+over+flaws/2100-1002_3-53
> 13655.
> html
> 
> I still haven't understood, for notary services, if
> the notary service doesn't have the original document
> but just the hash, what happens when the hash algorithm
> is compromised?
> 
> Larry



From owner-ietf-ltans Wed Aug 25 04:37:55 2004
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i7PBbtvx092984;
	Wed, 25 Aug 2004 04:37:55 -0700 (PDT)
	(envelope-from owner-ietf-ltans@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id i7PBbtJ0092983;
	Wed, 25 Aug 2004 04:37:55 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i7PBbr3n092972
	for <ietf-ltans@imc.org>; Wed, 25 Aug 2004 04:37:54 -0700 (PDT)
	(envelope-from Denis.Pinkas@bull.net)
Received: from clbull.frcl.bull.fr (IDENT:root@clbull.frcl.bull.fr [129.182.8.31])
	by odin2.bull.net (8.9.3/8.9.3) with ESMTP id NAA65290;
	Wed, 25 Aug 2004 13:48:41 +0200
Received: from bull.net (frcls4013.frcl.bull.fr [129.182.108.120])
	by clbull.frcl.bull.fr (8.9.3/8.9.3) with ESMTP id NAA16842;
	Wed, 25 Aug 2004 13:28:04 +0200
Message-ID: <412C797C.90102@bull.net>
Date: Wed, 25 Aug 2004 13:35:24 +0200
From: Denis Pinkas <Denis.Pinkas@bull.net>
Organization: Bull SA.
User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0
X-Accept-Language: en-us, en, fr
MIME-Version: 1.0
To: Santosh Chokhani <chokhani@orionsec.com>
CC: "'IETF LTANS'" <ietf-ltans@imc.org>
Subject: Re: MD5, SHA-0
References: <004001c48a95$82492b50$aa02a8c0@hq.orionsec.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-ietf-ltans@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-ltans/mail-archive/>
List-Unsubscribe: <mailto:ietf-ltans-request@imc.org?body=unsubscribe>
List-ID: <ietf-ltans.imc.org>


Santosh,

> Carl, Denis:
> 
> My response was terse.  I assumed that the question was prompted with when
> the Notary is given only the hash in the first place for the reasons of
> confidentiality.

Hum, hum !!!

My undersnding of the primary role of a notary (at least under the French 
legislation) is to look at the content of the document (already signed) 
before applying his own signature. Therefor I have some difficulties with 
schemes where the Notary would not have access to the semantics of the 
document. Otherwise the word "Notary" should not be used for that case.

Denis



> Thus, I was proposing that to preserve the confidentiality desired b the
> submitter, we look into ERS encryption approach.
> 
> -----Original Message-----
> From: Denis Pinkas [mailto:Denis.Pinkas@bull.net] 
> Sent: Wednesday, August 25, 2004 4:13 AM
> To: Santosh Chokhani
> Cc: 'IETF LTANS'
> Subject: Re: MD5, SHA-0
> 
> 
> Santosh,
> 
> 
>>Larry:
>>
>>The initial reading is that SHA-1 is relatively safe, but people 
>>should move to SHA 256 within next 5 years.
>>
>>That said, LTANS does need to worry about what happens if the notary 
>>has the hash of the document.  If the hash gets broken, it dilutes the 
>>document existence claim.
> 
> 
> No. Apply a new time-stamp token with a new hash function.
> 
> 
>>I think one alternative is to use the encrypt scheme as ERS folks have 
>>proposed for trusted archive.  Of course, the caveats in the ERS 
>>encryption paper will apply.
> 
> 
> Avoid any kind of encryption for that purpose.
> 
> Denis
> 
> 
>>-----Original Message-----
>>From: owner-ietf-ltans@mail.imc.org 
>>[mailto:owner-ietf-ltans@mail.imc.org]
>>On Behalf Of Larry Masinter
>>Sent: Wednesday, August 18, 2004 2:26 AM
>>To: 'IETF LTANS'
>>Subject: MD5, SHA-0
>>
>>
>>
>>It's sometimes hard to discern technical details in news articles. 
>>Anyone have a more reliable source on what happened at Crypto 2004?
>>
>>http://news.com.com/Crypto+researchers+abuzz+over+flaws/2100-1002_3-53
>>13655.
>>html
>>
>>I still haven't understood, for notary services, if
>>the notary service doesn't have the original document
>>but just the hash, what happens when the hash algorithm
>>is compromised?
>>
>>Larry
> 
> 
> 
> 



From owner-ietf-ltans Wed Aug 25 04:50:12 2004
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i7PBoCba096736;
	Wed, 25 Aug 2004 04:50:12 -0700 (PDT)
	(envelope-from owner-ietf-ltans@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id i7PBoCYt096735;
	Wed, 25 Aug 2004 04:50:12 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f
Received: from host13.websitesource.com (host13.websitesource.com [209.239.35.152])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i7PBoC90096725
	for <ietf-ltans@imc.org>; Wed, 25 Aug 2004 04:50:12 -0700 (PDT)
	(envelope-from chokhani@orionsec.com)
Received: from wchokhani3 (pcp09271907pcs.arlngt01.va.comcast.net [69.143.130.247])
	by host13.websitesource.com (8.12.10/8.12.10) with ESMTP id i7PBoDod016832
	for <ietf-ltans@imc.org>; Wed, 25 Aug 2004 07:50:13 -0400
From: "Santosh Chokhani" <chokhani@orionsec.com>
To: "'IETF LTANS'" <ietf-ltans@imc.org>
Subject: RE: MD5, SHA-0
Date: Wed, 25 Aug 2004 07:50:07 -0400
Message-ID: <006201c48a99$ae44a460$aa02a8c0@hq.orionsec.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.6626
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441
In-Reply-To: <412C797C.90102@bull.net>
Sender: owner-ietf-ltans@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-ltans/mail-archive/>
List-Unsubscribe: <mailto:ietf-ltans-request@imc.org?body=unsubscribe>
List-ID: <ietf-ltans.imc.org>


Denis:

If we assume that notary notarizes the original document, we do not have a
problem.

Larry:

Should the notary requirement make this clear? 

-----Original Message-----
From: Denis Pinkas [mailto:Denis.Pinkas@bull.net] 
Sent: Wednesday, August 25, 2004 7:35 AM
To: Santosh Chokhani
Cc: 'IETF LTANS'
Subject: Re: MD5, SHA-0


Santosh,

> Carl, Denis:
> 
> My response was terse.  I assumed that the question was prompted with 
> when the Notary is given only the hash in the first place for the 
> reasons of confidentiality.

Hum, hum !!!

My undersnding of the primary role of a notary (at least under the French 
legislation) is to look at the content of the document (already signed) 
before applying his own signature. Therefor I have some difficulties with 
schemes where the Notary would not have access to the semantics of the 
document. Otherwise the word "Notary" should not be used for that case.

Denis



> Thus, I was proposing that to preserve the confidentiality desired b 
> the submitter, we look into ERS encryption approach.
> 
> -----Original Message-----
> From: Denis Pinkas [mailto:Denis.Pinkas@bull.net]
> Sent: Wednesday, August 25, 2004 4:13 AM
> To: Santosh Chokhani
> Cc: 'IETF LTANS'
> Subject: Re: MD5, SHA-0
> 
> 
> Santosh,
> 
> 
>>Larry:
>>
>>The initial reading is that SHA-1 is relatively safe, but people
>>should move to SHA 256 within next 5 years.
>>
>>That said, LTANS does need to worry about what happens if the notary
>>has the hash of the document.  If the hash gets broken, it dilutes the 
>>document existence claim.
> 
> 
> No. Apply a new time-stamp token with a new hash function.
> 
> 
>>I think one alternative is to use the encrypt scheme as ERS folks have
>>proposed for trusted archive.  Of course, the caveats in the ERS 
>>encryption paper will apply.
> 
> 
> Avoid any kind of encryption for that purpose.
> 
> Denis
> 
> 
>>-----Original Message-----
>>From: owner-ietf-ltans@mail.imc.org
>>[mailto:owner-ietf-ltans@mail.imc.org]
>>On Behalf Of Larry Masinter
>>Sent: Wednesday, August 18, 2004 2:26 AM
>>To: 'IETF LTANS'
>>Subject: MD5, SHA-0
>>
>>
>>
>>It's sometimes hard to discern technical details in news articles.
>>Anyone have a more reliable source on what happened at Crypto 2004?
>>
>>http://news.com.com/Crypto+researchers+abuzz+over+flaws/2100-1002_3-53
>>13655.
>>html
>>
>>I still haven't understood, for notary services, if
>>the notary service doesn't have the original document
>>but just the hash, what happens when the hash algorithm
>>is compromised?
>>
>>Larry
> 
> 
> 
> 



From owner-ietf-ltans Wed Aug 25 06:37:28 2004
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i7PDbS74019011;
	Wed, 25 Aug 2004 06:37:28 -0700 (PDT)
	(envelope-from owner-ietf-ltans@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id i7PDbSUP019010;
	Wed, 25 Aug 2004 06:37:28 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f
Received: from igw (adsl-63-194-79-229.dsl.snfc21.pacbell.net [63.194.79.229])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i7PDbRIW018987
	for <ietf-ltans@imc.org>; Wed, 25 Aug 2004 06:37:27 -0700 (PDT)
	(envelope-from arshad.noor@strongauth.com)
Received: from noorhome.net (localhost [127.0.0.1])
 by igw.noorhome.net (iPlanet Messaging Server 5.2 Patch 1 (built Aug 19 2002))
 with ESMTP id <0I3000DAS7K0XD@igw.noorhome.net> for ietf-ltans@imc.org; Wed,
 25 Aug 2004 06:16:48 -0700 (PDT)
Received: from [12.18.36.40] by igw.noorhome.net (mshttpd); Wed,
 25 Aug 2004 09:16:48 -0400
Date: Wed, 25 Aug 2004 09:16:48 -0400
From: Arshad Noor <arshad.noor@strongauth.com>
Subject: Re: RE: MD5, SHA-0
To: Santosh Chokhani <chokhani@orionsec.com>
Cc: "'IETF LTANS'" <ietf-ltans@imc.org>
Message-id: <876a6d38.6d38876a@noorhome.net>
MIME-version: 1.0
X-Mailer: iPlanet Messenger Express 5.2 Patch 1 (built Aug 19 2002)
Content-type: text/plain; charset=us-ascii
Content-language: en
Content-transfer-encoding: 7BIT
Content-disposition: inline
X-Accept-Language: en
Sender: owner-ietf-ltans@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-ltans/mail-archive/>
List-Unsubscribe: <mailto:ietf-ltans-request@imc.org?body=unsubscribe>
List-ID: <ietf-ltans.imc.org>


I cannot speak for the French (or for that matter, for the remaining 49 states 
of the US), but the State of California requires that Notaries must review the 
document BEFORE the document signer signs it (I would presume that this 
may be a uniform requirement in the US).

Notaries sign two types of documents - Acknowledgements and Jurats.  An
Acknowledgement witnesses the actual act of the document signer signing 
the document, while in the Jurat, the document signer must swear to veracity 
of the contents of the document before signing it.  In both cases, the Notary 
MUST review the unsigned paper document, and witness the signer signing
the document before he/she notarizes it.  

There are no laws around electronic notarization in CA, and it might be prudent
to not use the word "Notary" or "Notarization" with such services until there is
a law that defines it - we may risk diluting the meaning of the word in the paper
world.

Arshad Noor
StrongAuth, Inc.


----- Original Message -----
From: Santosh Chokhani <chokhani@orionsec.com>
Date: Wednesday, August 25, 2004 7:50 am
Subject: RE: MD5, SHA-0

> 
> Denis:
> 
> If we assume that notary notarizes the original document, we do 
> not have a
> problem.
> 
> Larry:
> 
> Should the notary requirement make this clear? 
> 
> -----Original Message-----
> From: Denis Pinkas [mailto:Denis.Pinkas@bull.net] 
> Sent: Wednesday, August 25, 2004 7:35 AM
> To: Santosh Chokhani
> Cc: 'IETF LTANS'
> Subject: Re: MD5, SHA-0
> 
> 
> Santosh,
> 
> > Carl, Denis:
> > 
> > My response was terse.  I assumed that the question was prompted 
> with 
> > when the Notary is given only the hash in the first place for 
> the 
> > reasons of confidentiality.
> 
> Hum, hum !!!
> 
> My undersnding of the primary role of a notary (at least under the 
> French 
> legislation) is to look at the content of the document (already 
> signed) 
> before applying his own signature. Therefor I have some 
> difficulties with 
> schemes where the Notary would not have access to the semantics of 
> the 
> document. Otherwise the word "Notary" should not be used for that 
> case.
> Denis
> 
> 
> 
> > Thus, I was proposing that to preserve the confidentiality 
> desired b 
> > the submitter, we look into ERS encryption approach.
> > 
> > -----Original Message-----
> > From: Denis Pinkas [mailto:Denis.Pinkas@bull.net]
> > Sent: Wednesday, August 25, 2004 4:13 AM
> > To: Santosh Chokhani
> > Cc: 'IETF LTANS'
> > Subject: Re: MD5, SHA-0
> > 
> > 
> > Santosh,
> > 
> > 
> >>Larry:
> >>
> >>The initial reading is that SHA-1 is relatively safe, but people
> >>should move to SHA 256 within next 5 years.
> >>
> >>That said, LTANS does need to worry about what happens if the notary
> >>has the hash of the document.  If the hash gets broken, it 
> dilutes the 
> >>document existence claim.
> > 
> > 
> > No. Apply a new time-stamp token with a new hash function.
> > 
> > 
> >>I think one alternative is to use the encrypt scheme as ERS 
> folks have
> >>proposed for trusted archive.  Of course, the caveats in the ERS 
> >>encryption paper will apply.
> > 
> > 
> > Avoid any kind of encryption for that purpose.
> > 
> > Denis
> > 
> > 
> >>-----Original Message-----
> >>From: owner-ietf-ltans@mail.imc.org
> >>[mailto:owner-ietf-ltans@mail.imc.org]
> >>On Behalf Of Larry Masinter
> >>Sent: Wednesday, August 18, 2004 2:26 AM
> >>To: 'IETF LTANS'
> >>Subject: MD5, SHA-0
> >>
> >>
> >>
> >>It's sometimes hard to discern technical details in news articles.
> >>Anyone have a more reliable source on what happened at Crypto 2004?
> >>
> >>http://news.com.com/Crypto+researchers+abuzz+over+flaws/2100-
> 1002_3-53
> >>13655.
> >>html
> >>
> >>I still haven't understood, for notary services, if
> >>the notary service doesn't have the original document
> >>but just the hash, what happens when the hash algorithm
> >>is compromised?
> >>
> >>Larry
> > 
> > 
> > 
> > 
> 
> 
> 


From owner-ietf-ltans Wed Aug 25 08:16:31 2004
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i7PFGVHn043057;
	Wed, 25 Aug 2004 08:16:31 -0700 (PDT)
	(envelope-from owner-ietf-ltans@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id i7PFGVnJ043056;
	Wed, 25 Aug 2004 08:16:31 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f
Received: from MessageInpector.nationalnotary.org (mail.nationalnotary.org [65.115.114.141])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i7PFGU4h043038
	for <ietf-ltans@imc.org>; Wed, 25 Aug 2004 08:16:30 -0700 (PDT)
	(envelope-from rhansberger@nationalnotary.org)
Received: from louise2.nationalnotary.org (LOUISE2 [192.168.1.247])
	by MessageInpector.nationalnotary.org (Switch-2.2.8/Switch-2.2.4) with ESMTP id W7PG0D3700000108
	for <ietf-ltans@imc.org>; Wed, 25 Aug 2004 08:13:03 -0800
Received: by Louise2 with Internet Mail Service (5.5.2657.72)
	id <RKG7HA9H>; Wed, 25 Aug 2004 08:13:33 -0800
Message-ID: <561F9357D239EB428AE3A4F14244431303946C@Louise2>
From: Richard Hansberger <rhansberger@nationalnotary.org>
To: "'ietf-ltans@imc.org'" <ietf-ltans@imc.org>
Subject: RE: RE: MD5, SHA-0
Date: Wed, 25 Aug 2004 08:13:31 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
Content-Type: multipart/mixed; boundary="--123456789-987654321-abcdefg"
X-MessageInspectorSig: 8efbd4336c30e6281c4c93b5ba69208e
Sender: owner-ietf-ltans@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-ltans/mail-archive/>
List-Unsubscribe: <mailto:ietf-ltans-request@imc.org?body=unsubscribe>
List-ID: <ietf-ltans.imc.org>



----123456789-987654321-abcdefg
Content-Type: text/plain

I hope some of this information is useful; I can provide specific
documentation if necessary.

Many state laws mandate that Notaries may NOT notarize documents with "blank
or incomplete" spaces. Notaries are expected to review documents carefully,
though not to interpret them for signers. In every case and in every state,
the signer MUST appear before the Notary. Physical presence of the signer
before the Notary is almost the entire premise of notarization.

Acknowledgments and jurats are only two types of notarial acts. There are at
least 7 others (off the top of my head). What is common to them all is a
notarial certificate that contains wording indicating the act performed. By
far, however, acknowledgments and jurats comprise the bulk of what Notaries
do on a daily basis.

California actually does have provisions for electronic notarization (we are
running pilots right now), and three other states do as well: CO, AZ, PA.

Richard J. Hansberger
Director of eNotarization
National Notary Association
818-739-4027

-----Original Message-----
From: Arshad Noor [mailto:arshad.noor@strongauth.com] 
Sent: Wednesday, August 25, 2004 5:17 AM
To: Santosh Chokhani
Cc: 'IETF LTANS'
Subject: Re: RE: MD5, SHA-0



I cannot speak for the French (or for that matter, for the remaining 49
states 
of the US), but the State of California requires that Notaries must review
the 
document BEFORE the document signer signs it (I would presume that this 
may be a uniform requirement in the US).

Notaries sign two types of documents - Acknowledgements and Jurats.  An
Acknowledgement witnesses the actual act of the document signer signing 
the document, while in the Jurat, the document signer must swear to veracity

of the contents of the document before signing it.  In both cases, the
Notary 
MUST review the unsigned paper document, and witness the signer signing the
document before he/she notarizes it.  

There are no laws around electronic notarization in CA, and it might be
prudent to not use the word "Notary" or "Notarization" with such services
until there is a law that defines it - we may risk diluting the meaning of
the word in the paper world.

Arshad Noor
StrongAuth, Inc.


----- Original Message -----
From: Santosh Chokhani <chokhani@orionsec.com>
Date: Wednesday, August 25, 2004 7:50 am
Subject: RE: MD5, SHA-0

> 
> Denis:
> 
> If we assume that notary notarizes the original document, we do
> not have a
> problem.
> 
> Larry:
> 
> Should the notary requirement make this clear?
> 
> -----Original Message-----
> From: Denis Pinkas [mailto:Denis.Pinkas@bull.net]
> Sent: Wednesday, August 25, 2004 7:35 AM
> To: Santosh Chokhani
> Cc: 'IETF LTANS'
> Subject: Re: MD5, SHA-0
> 
> 
> Santosh,
> 
> > Carl, Denis:
> > 
> > My response was terse.  I assumed that the question was prompted
> with
> > when the Notary is given only the hash in the first place for
> the
> > reasons of confidentiality.
> 
> Hum, hum !!!
> 
> My undersnding of the primary role of a notary (at least under the
> French 
> legislation) is to look at the content of the document (already 
> signed) 
> before applying his own signature. Therefor I have some 
> difficulties with 
> schemes where the Notary would not have access to the semantics of 
> the 
> document. Otherwise the word "Notary" should not be used for that 
> case.
> Denis
> 
> 
> 
> > Thus, I was proposing that to preserve the confidentiality
> desired b
> > the submitter, we look into ERS encryption approach.
> > 
> > -----Original Message-----
> > From: Denis Pinkas [mailto:Denis.Pinkas@bull.net]
> > Sent: Wednesday, August 25, 2004 4:13 AM
> > To: Santosh Chokhani
> > Cc: 'IETF LTANS'
> > Subject: Re: MD5, SHA-0
> > 
> > 
> > Santosh,
> > 
> > 
> >>Larry:
> >>
> >>The initial reading is that SHA-1 is relatively safe, but people 
> >>should move to SHA 256 within next 5 years.
> >>
> >>That said, LTANS does need to worry about what happens if the notary 
> >>has the hash of the document.  If the hash gets broken, it
> dilutes the
> >>document existence claim.
> > 
> > 
> > No. Apply a new time-stamp token with a new hash function.
> > 
> > 
> >>I think one alternative is to use the encrypt scheme as ERS
> folks have
> >>proposed for trusted archive.  Of course, the caveats in the ERS
> >>encryption paper will apply.
> > 
> > 
> > Avoid any kind of encryption for that purpose.
> > 
> > Denis
> > 
> > 
> >>-----Original Message-----
> >>From: owner-ietf-ltans@mail.imc.org 
> >>[mailto:owner-ietf-ltans@mail.imc.org]
> >>On Behalf Of Larry Masinter
> >>Sent: Wednesday, August 18, 2004 2:26 AM
> >>To: 'IETF LTANS'
> >>Subject: MD5, SHA-0
> >>
> >>
> >>
> >>It's sometimes hard to discern technical details in news articles. 
> >>Anyone have a more reliable source on what happened at Crypto 2004?
> >>
> >>http://news.com.com/Crypto+researchers+abuzz+over+flaws/2100-
> 1002_3-53
> >>13655.
> >>html
> >>
> >>I still haven't understood, for notary services, if
> >>the notary service doesn't have the original document
> >>but just the hash, what happens when the hash algorithm
> >>is compromised?
> >>
> >>Larry
> > 
> > 
> > 
> > 
> 
> 
> 
----123456789-987654321-abcdefg
Content-Type: text/plain
Content-Disposition: inline

This email message and any files transmitted with it contain confidential information intended only for the person(s) to whom this email message is addressed.  If you have received this email message in error, please notify the sender immediately.

----123456789-987654321-abcdefg--


From owner-ietf-ltans Wed Aug 25 08:38:32 2004
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i7PFcWG7048103;
	Wed, 25 Aug 2004 08:38:32 -0700 (PDT)
	(envelope-from owner-ietf-ltans@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id i7PFcWF3048102;
	Wed, 25 Aug 2004 08:38:32 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f
Received: from igw (adsl-63-194-79-229.dsl.snfc21.pacbell.net [63.194.79.229])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i7PFcVR0048081
	for <ietf-ltans@imc.org>; Wed, 25 Aug 2004 08:38:31 -0700 (PDT)
	(envelope-from arshad.noor@strongauth.com)
Received: from noorhome.net (localhost [127.0.0.1])
 by igw.noorhome.net (iPlanet Messaging Server 5.2 Patch 1 (built Aug 19 2002))
 with ESMTP id <0I3000DGUD5ZXD@igw.noorhome.net> for ietf-ltans@imc.org; Wed,
 25 Aug 2004 08:17:59 -0700 (PDT)
Received: from [12.18.36.40] by igw.noorhome.net (mshttpd); Wed,
 25 Aug 2004 11:17:59 -0400
Date: Wed, 25 Aug 2004 11:17:59 -0400
From: Arshad Noor <arshad.noor@strongauth.com>
Subject: Re: RE: RE: MD5, SHA-0
To: Richard Hansberger <rhansberger@nationalnotary.org>
Cc: "'ietf-ltans@imc.org'" <ietf-ltans@imc.org>
Message-id: <37357636.76363735@noorhome.net>
MIME-version: 1.0
X-Mailer: iPlanet Messenger Express 5.2 Patch 1 (built Aug 19 2002)
Content-type: multipart/mixed; boundary="Boundary_(ID_buIBGRozu9VfNhYJWAZceQ)"
Content-language: en
X-Accept-Language: en
Sender: owner-ietf-ltans@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-ltans/mail-archive/>
List-Unsubscribe: <mailto:ietf-ltans-request@imc.org?body=unsubscribe>
List-ID: <ietf-ltans.imc.org>


This is a multi-part message in MIME format.

--Boundary_(ID_buIBGRozu9VfNhYJWAZceQ)
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7BIT
Content-disposition: inline

Richard,

Thank you for shedding more light on the subject.  Can you point me to
information on the electronic notarization pilots?  I am most interested
in the one in CA, but am also keen on knowing how the remaining three
states are implementing it.

Thank you.

Arshad Noor
StrongAuth, Inc.

----- Original Message -----
From: Richard Hansberger <rhansberger@nationalnotary.org>
Date: Wednesday, August 25, 2004 12:13 pm
Subject: RE: RE: MD5, SHA-0

> I hope some of this information is useful; I can provide specific
> documentation if necessary.
> 
> Many state laws mandate that Notaries may NOT notarize documents 
> with "blank
> or incomplete" spaces. Notaries are expected to review documents 
> carefully,though not to interpret them for signers. In every case 
> and in every state,
> the signer MUST appear before the Notary. Physical presence of the 
> signerbefore the Notary is almost the entire premise of notarization.
> 
> Acknowledgments and jurats are only two types of notarial acts. 
> There are at
> least 7 others (off the top of my head). What is common to them 
> all is a
> notarial certificate that contains wording indicating the act 
> performed. By
> far, however, acknowledgments and jurats comprise the bulk of what 
> Notariesdo on a daily basis.
> 
> California actually does have provisions for electronic 
> notarization (we are
> running pilots right now), and three other states do as well: CO, 
> AZ, PA.
> 
> Richard J. Hansberger
> Director of eNotarization
> National Notary Association
> 818-739-4027
> 
> -----Original Message-----
> From: Arshad Noor [mailto:arshad.noor@strongauth.com] 
> Sent: Wednesday, August 25, 2004 5:17 AM
> To: Santosh Chokhani
> Cc: 'IETF LTANS'
> Subject: Re: RE: MD5, SHA-0
> 
> 
> 
> I cannot speak for the French (or for that matter, for the 
> remaining 49
> states 
> of the US), but the State of California requires that Notaries 
> must review
> the 
> document BEFORE the document signer signs it (I would presume that 
> this 
> may be a uniform requirement in the US).
> 
> Notaries sign two types of documents - Acknowledgements and 
> Jurats.  An
> Acknowledgement witnesses the actual act of the document signer 
> signing 
> the document, while in the Jurat, the document signer must swear 
> to veracity
> 
> of the contents of the document before signing it.  In both cases, the
> Notary 
> MUST review the unsigned paper document, and witness the signer 
> signing the
> document before he/she notarizes it.  
> 
> There are no laws around electronic notarization in CA, and it 
> might be
> prudent to not use the word "Notary" or "Notarization" with such 
> servicesuntil there is a law that defines it - we may risk 
> diluting the meaning of
> the word in the paper world.
> 
> Arshad Noor
> StrongAuth, Inc.
> 
> 
> ----- Original Message -----
> From: Santosh Chokhani <chokhani@orionsec.com>
> Date: Wednesday, August 25, 2004 7:50 am
> Subject: RE: MD5, SHA-0
> 
> > 
> > Denis:
> > 
> > If we assume that notary notarizes the original document, we do
> > not have a
> > problem.
> > 
> > Larry:
> > 
> > Should the notary requirement make this clear?
> > 
> > -----Original Message-----
> > From: Denis Pinkas [mailto:Denis.Pinkas@bull.net]
> > Sent: Wednesday, August 25, 2004 7:35 AM
> > To: Santosh Chokhani
> > Cc: 'IETF LTANS'
> > Subject: Re: MD5, SHA-0
> > 
> > 
> > Santosh,
> > 
> > > Carl, Denis:
> > > 
> > > My response was terse.  I assumed that the question was prompted
> > with
> > > when the Notary is given only the hash in the first place for
> > the
> > > reasons of confidentiality.
> > 
> > Hum, hum !!!
> > 
> > My undersnding of the primary role of a notary (at least under the
> > French 
> > legislation) is to look at the content of the document (already 
> > signed) 
> > before applying his own signature. Therefor I have some 
> > difficulties with 
> > schemes where the Notary would not have access to the semantics 
> of 
> > the 
> > document. Otherwise the word "Notary" should not be used for 
> that 
> > case.
> > Denis
> > 
> > 
> > 
> > > Thus, I was proposing that to preserve the confidentiality
> > desired b
> > > the submitter, we look into ERS encryption approach.
> > > 
> > > -----Original Message-----
> > > From: Denis Pinkas [mailto:Denis.Pinkas@bull.net]
> > > Sent: Wednesday, August 25, 2004 4:13 AM
> > > To: Santosh Chokhani
> > > Cc: 'IETF LTANS'
> > > Subject: Re: MD5, SHA-0
> > > 
> > > 
> > > Santosh,
> > > 
> > > 
> > >>Larry:
> > >>
> > >>The initial reading is that SHA-1 is relatively safe, but 
> people 
> > >>should move to SHA 256 within next 5 years.
> > >>
> > >>That said, LTANS does need to worry about what happens if the 
> notary 
> > >>has the hash of the document.  If the hash gets broken, it
> > dilutes the
> > >>document existence claim.
> > > 
> > > 
> > > No. Apply a new time-stamp token with a new hash function.
> > > 
> > > 
> > >>I think one alternative is to use the encrypt scheme as ERS
> > folks have
> > >>proposed for trusted archive.  Of course, the caveats in the ERS
> > >>encryption paper will apply.
> > > 
> > > 
> > > Avoid any kind of encryption for that purpose.
> > > 
> > > Denis
> > > 
> > > 
> > >>-----Original Message-----
> > >>From: owner-ietf-ltans@mail.imc.org 
> > >>[mailto:owner-ietf-ltans@mail.imc.org]
> > >>On Behalf Of Larry Masinter
> > >>Sent: Wednesday, August 18, 2004 2:26 AM
> > >>To: 'IETF LTANS'
> > >>Subject: MD5, SHA-0
> > >>
> > >>
> > >>
> > >>It's sometimes hard to discern technical details in news 
> articles. 
> > >>Anyone have a more reliable source on what happened at Crypto 
> 2004?> >>
> > >>http://news.com.com/Crypto+researchers+abuzz+over+flaws/2100-
> > 1002_3-53
> > >>13655.
> > >>html
> > >>
> > >>I still haven't understood, for notary services, if
> > >>the notary service doesn't have the original document
> > >>but just the hash, what happens when the hash algorithm
> > >>is compromised?
> > >>
> > >>Larry
> > > 
> > > 
> > > 
> > > 
> > 
> > 
> > 

--Boundary_(ID_buIBGRozu9VfNhYJWAZceQ)
Content-type: text/plain
Content-transfer-encoding: 7BIT
Content-disposition: inline

This email message and any files transmitted with it contain confidential information intended only for the person(s) to whom this email message is addressed.  If you have received this email message in error, please notify the sender immediately.

--Boundary_(ID_buIBGRozu9VfNhYJWAZceQ)--


From owner-ietf-ltans Thu Aug 26 00:20:28 2004
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i7Q7KSH7073345;
	Thu, 26 Aug 2004 00:20:28 -0700 (PDT)
	(envelope-from owner-ietf-ltans@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id i7Q7KSfq073344;
	Thu, 26 Aug 2004 00:20:28 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f
Received: from mail4.telekom.de (mail4.telekom.de [195.243.210.197])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i7Q7KRbS073286
	for <ietf-ltans@imc.org>; Thu, 26 Aug 2004 00:20:27 -0700 (PDT)
	(envelope-from ErnstG.Giessmann@t-systems.com)
Received: from U9JWN.mgb01.telekom.de by mail2.dmz.telekom.de with ESMTP for ietf-ltans@imc.org; Thu, 26 Aug 2004 09:19:24 +0200
Received: from mailgate9.telekom.de by U9JWN.mgb01.telekom.de with ESMTP for ietf-ltans@imc.org; Thu, 26 Aug 2004 09:18:49 +0200
Received: from bach.bln05.telekom.de by mailgate9.telekom.de (8.8.8/1.1.8.2/02Aug95-1122AM)
	id JAA0000001718; Thu, 26 Aug 2004 09:18:48 +0200 (MET DST)
Received: from [172.23.7.12] ([172.23.7.12])
	by bach.bln05.telekom.de (8.8.8+Sun/8.8.8) with ESMTP id JAA09368
	for <ietf-ltans@imc.org>; Thu, 26 Aug 2004 09:20:24 +0200 (MET DST)
Message-Id: <412D8EC5.7060707@t-systems.com>
Date: Thu, 26 Aug 2004 09:18:29 +0200
From: Ernst G Giessmann <ErnstG.Giessmann@t-systems.com>
User-Agent: Mozilla Thunderbird 0.7 (Windows/20040616)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "'IETF LTANS'" <ietf-ltans@imc.org>
Subject: Re: MD5, SHA-0
References: <000501c4894f$75b081a0$9a00a8c0@hq.orionsec.com> <412C4A09.1030407@bull.net>
In-Reply-To: <412C4A09.1030407@bull.net>
X-Enigmail-Version: 0.84.0.0
X-Enigmail-Supports: pgp-inline, pgp-mime
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-ietf-ltans@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-ltans/mail-archive/>
List-Unsubscribe: <mailto:ietf-ltans-request@imc.org?body=unsubscribe>
List-ID: <ietf-ltans.imc.org>


>> Larry:
>>
>> The initial reading is that SHA-1 is relatively safe, but people
>> should move
>> to SHA 256 within next 5 years.
>>
>> That said, LTANS does need to worry about what happens if the notary
>> has the
>> hash of the document.  If the hash gets broken, it dilutes the document
>> existence claim.

It dilutes the proof of the document existence claim via *that* hash. If
the document existence claim proof can be thickened by other means, you
are safe.

Denis Pinkas wrote:
> No. Apply a new time-stamp token with a new hash function.

Denis is right, this is a well known way of thickening.


>> I think one alternative is to use the encrypt scheme as ERS folks have
>> proposed for trusted archive.  Of course, the caveats in the ERS
>> encryption paper will apply.


Denis Pinkas wrote:
> Avoid any kind of encryption for that purpose.

Denis is right again: Encryption is the way to protect a document from
disclosure but *not* from a wrong existence claim.

Ernst.


From owner-ietf-ltans Mon Aug 30 12:47:42 2004
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i7UJlgmc097415;
	Mon, 30 Aug 2004 12:47:42 -0700 (PDT)
	(envelope-from owner-ietf-ltans@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id i7UJlgeP097414;
	Mon, 30 Aug 2004 12:47:42 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f
Received: from mailext.sit.fraunhofer.de (mailext.sit.fraunhofer.de [141.12.72.89])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i7UJlf5W097373
	for <ietf-ltans@imc.org>; Mon, 30 Aug 2004 12:47:41 -0700 (PDT)
	(envelope-from thomas.kunz@sit.fraunhofer.de)
Received: from localhost (localhost [127.0.0.1])
	by mailext.sit.fraunhofer.de (8.12.10/8.12.10) with ESMTP id i7UK4NL4008447
	for <ietf-ltans@imc.org>; Mon, 30 Aug 2004 22:04:24 +0200
Received: from pD9F6E359.dip.t-dialin.net (pD9F6E359.dip.t-dialin.net
	[217.246.227.89]) by mailext.sit.fraunhofer.de (Horde) with HTTP for
	<kunz@mailext.sit.fraunhofer.de>; Mon, 30 Aug 2004 22:04:23 +0200
Message-ID: <1093896263.549wjk8xskn4@mailext.sit.fraunhofer.de>
Date: Mon, 30 Aug 2004 22:04:23 +0200
From: Thomas Kunz <thomas.kunz@sit.fraunhofer.de>
To: ietf-ltans@imc.org
Subject: Scenarios for notary services
MIME-Version: 1.0
Content-Type: text/plain; charset="ISO-8859-1"
Content-Disposition: inline
User-Agent: Internet Messaging Program (IMP) 4.0-cvs
X-Originating-IP:  217.246.227.89
X-Organisation:  Fraunhofer-SIT
X-Virus-Scanned: by amavisd-new
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i7UJlg5W097408
Sender: owner-ietf-ltans@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-ltans/mail-archive/>
List-Unsubscribe: <mailto:ietf-ltans-request@imc.org?body=unsubscribe>
List-ID: <ietf-ltans.imc.org>


Hello,

to corroborate the case for notary services in general, we would like
to supplement the use-case section of the requirements doc by some
more concrete, yet still rather generic, scenarios.
We think it fit to include the following section in the document:

4. Scenarios

This sections describes some concrete scenarios based on the use cases
introduced in section 3.

4.1 Record transactions
The following example will show the additional benefits of a notary
service in the case of private transactions.


We start with a basic protocol that achieves, upon completion, a state
of mutual non-repudiation between two parties, A and B.
Suppose, A wants to offer an electronic contract (contract_A) to B,
where "contract_A" means that A has digitally signed the contract with
her private key. This is sent as an offer to B:

contract_A -> B

B, after receiving and accepting contract_A, counter-signs the contract
and sends it back to A as an acceptance of A's offer:

(contract_A)_B -> A

Now, A has to confirm reception of the acceptance. He signs
(contract_A)_B and sends it back to B:

((contract_A)_B)_A -> B

After that, both parties have a document with at least two signatures,
and neither party can succeed in repudiating the validity of the
contract.

Now let's see what happens when we put a notary service N as a trusted
third party between A and B. When B gets the contract from A and
accepts it, he signs the contract and sends it to N:

(contract_A)_B -> N

The notary confirms receipt of the contract with a signature and sends
it to both A and B:

((contract_A)_B)_N -> A, B

After that, both parties have a document signed by A, B, and N. Since N
is trusted, A and B can be sure that the other party has a contract
which is signed by both. We have the same level of trust as in the
scenario without the notary service. However, an additional benefit
of using a notary in this case, can be to archive the contract, as may
be required by the law for certain types of contracts.

In order to allow for N to provide documentation that all necessary
information has been provided to both parties, the scenario can be
extended as follows:

When A and B get the confirmation ((contract_A)_B)_N from N,
both A and B send an acknowledgement to N:

ack_A -> N
ack_B -> N

After N received the two acknowledgements he sends a notification to
both A and B that confirms that the transaction is completed:

not_N -> A, B

For both ack_A/B and not_N it suffices to contain (sufficiently secure)
hash values of the pertaining original documents, and the same is true
for the third message sent from the notary in the protocol above, but
not for the second one, if the contract is to be archived by the notary.


The utility of notary services in these generic scenarios is twofold:
They can accomplish the fulfillment of technical requirements, e.g.,
archiving of transaction records, which may in turn be entailed by
legal requirements. And they can be instrumental in the fulfillment of
genuine legal requirements, like documentation that all necessary
information has been provided to all involved parties.

Best regards,

Andreas and Thomas

------------------------------------------------------------
Dipl. Inf. Thomas Kunz
Fraunhofer - Institut für Sichere Telekooperation (FhG-SIT)
Dolivostrasse 15
D-64293 Darmstadt (Germany)
Tel: +49-6151-869-60204
------------------------------------------------------------
e-mail: thomas.kunz@sit.fraunhofer.de

http://www.sit.fraunhofer.de
------------------------------------------------------------

---------------------------------------------------------------
Fraunhofer Institut Sichere Telekooperation
Fraunhofer Institute Secure Telekooperation

Diese Mail wurde per Webmail Interface versand.
This message was sent using Webmail Interface.
----------------------------------------------------------------



From owner-ietf-ltans Mon Aug 30 13:24:17 2004
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id i7UKOG9F004543;
	Mon, 30 Aug 2004 13:24:16 -0700 (PDT)
	(envelope-from owner-ietf-ltans@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id i7UKOGo0004542;
	Mon, 30 Aug 2004 13:24:16 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f
Received: from psmtp.com (exprod6ob3.obsmtp.com [12.158.35.213])
	by above.proper.com (8.12.11/8.12.9) with SMTP id i7UKOEjZ004536
	for <ietf-ltans@imc.org>; Mon, 30 Aug 2004 13:24:14 -0700 (PDT)
	(envelope-from LMM@acm.org)
Received: from source ([192.150.22.7]) by exprod6ob3.obsmtp.com ([12.158.35.250]) with SMTP;
	Mon, 30 Aug 2004 13:24:19 PDT
Received: from inner-relay-1.corp.adobe.com (inner-relay-1 [153.32.1.51])
	by smtp-relay-7.sea.adobe.com (8.12.10/8.12.10) with ESMTP id i7UKOINf015941;
	Mon, 30 Aug 2004 13:24:18 -0700 (PDT)
Received: from calsj-dev (calsj-dev.corp.adobe.com [153.32.1.193])
	by inner-relay-1.corp.adobe.com (8.12.9/8.12.9) with ESMTP id i7UKOITk028098;
	Mon, 30 Aug 2004 13:24:18 -0700 (PDT)
Received: from MasinterT40 (c-131-136.corp.adobe.com [153.32.131.136])
 by mailsj-v1.corp.adobe.com
 (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep  8 2003))
 with ESMTP id <0I3A00J7S0OIBI@mailsj-v1.corp.adobe.com>; Mon,
 30 Aug 2004 13:24:18 -0700 (PDT)
Date: Mon, 30 Aug 2004 13:24:17 -0700
From: Larry Masinter <LMM@acm.org>
Subject: RE: Scenarios for notary services
In-reply-to: <1093896263.549wjk8xskn4@mailext.sit.fraunhofer.de>
To: "'Thomas Kunz'" <thomas.kunz@sit.fraunhofer.de>
Cc: ietf-ltans@imc.org
Message-id: <0I3A00J7T0OIBI@mailsj-v1.corp.adobe.com>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
X-Mailer: Microsoft Office Outlook, Build 11.0.6353
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7BIT
Thread-index: AcSOzJLDgSQRI+RuQO+NbMFaUyD2cwAAde5w
Sender: owner-ietf-ltans@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-ltans/mail-archive/>
List-Unsubscribe: <mailto:ietf-ltans-request@imc.org?body=unsubscribe>
List-ID: <ietf-ltans.imc.org>


It might be useful to extend your scenarios to include
the 10-years-later-judge, trying to decide whether a presented
contract was agreed at the time it was signed.

I wonder if it is agreed that in LTANS, "Long-Term"
applies not only to Archive but also to Notary Services,
i.e., Long Term Notary Services. Thus the requirements
for notary services should consider the long-term scenario.

Larry
-- 
http://larry.masinter.net





Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7UKOG9F004543; Mon, 30 Aug 2004 13:24:16 -0700 (PDT) (envelope-from owner-ietf-ltans@mail.imc.org)
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7UKOGo0004542; Mon, 30 Aug 2004 13:24:16 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f
Received: from psmtp.com (exprod6ob3.obsmtp.com [12.158.35.213]) by above.proper.com (8.12.11/8.12.9) with SMTP id i7UKOEjZ004536 for <ietf-ltans@imc.org>; Mon, 30 Aug 2004 13:24:14 -0700 (PDT) (envelope-from LMM@acm.org)
Received: from source ([192.150.22.7]) by exprod6ob3.obsmtp.com ([12.158.35.250]) with SMTP; Mon, 30 Aug 2004 13:24:19 PDT
Received: from inner-relay-1.corp.adobe.com (inner-relay-1 [153.32.1.51]) by smtp-relay-7.sea.adobe.com (8.12.10/8.12.10) with ESMTP id i7UKOINf015941; Mon, 30 Aug 2004 13:24:18 -0700 (PDT)
Received: from calsj-dev (calsj-dev.corp.adobe.com [153.32.1.193]) by inner-relay-1.corp.adobe.com (8.12.9/8.12.9) with ESMTP id i7UKOITk028098; Mon, 30 Aug 2004 13:24:18 -0700 (PDT)
Received: from MasinterT40 (c-131-136.corp.adobe.com [153.32.131.136]) by mailsj-v1.corp.adobe.com (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep  8 2003)) with ESMTP id <0I3A00J7S0OIBI@mailsj-v1.corp.adobe.com>; Mon, 30 Aug 2004 13:24:18 -0700 (PDT)
Date: Mon, 30 Aug 2004 13:24:17 -0700
From: Larry Masinter <LMM@acm.org>
Subject: RE: Scenarios for notary services
In-reply-to: <1093896263.549wjk8xskn4@mailext.sit.fraunhofer.de>
To: "'Thomas Kunz'" <thomas.kunz@sit.fraunhofer.de>
Cc: ietf-ltans@imc.org
Message-id: <0I3A00J7T0OIBI@mailsj-v1.corp.adobe.com>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
X-Mailer: Microsoft Office Outlook, Build 11.0.6353
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7BIT
Thread-index: AcSOzJLDgSQRI+RuQO+NbMFaUyD2cwAAde5w
Sender: owner-ietf-ltans@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-ltans/mail-archive/>
List-Unsubscribe: <mailto:ietf-ltans-request@imc.org?body=unsubscribe>
List-ID: <ietf-ltans.imc.org>

It might be useful to extend your scenarios to include
the 10-years-later-judge, trying to decide whether a presented
contract was agreed at the time it was signed.

I wonder if it is agreed that in LTANS, "Long-Term"
applies not only to Archive but also to Notary Services,
i.e., Long Term Notary Services. Thus the requirements
for notary services should consider the long-term scenario.

Larry
-- 
http://larry.masinter.net





Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7UJlgmc097415; Mon, 30 Aug 2004 12:47:42 -0700 (PDT) (envelope-from owner-ietf-ltans@mail.imc.org)
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7UJlgeP097414; Mon, 30 Aug 2004 12:47:42 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f
Received: from mailext.sit.fraunhofer.de (mailext.sit.fraunhofer.de [141.12.72.89]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7UJlf5W097373 for <ietf-ltans@imc.org>; Mon, 30 Aug 2004 12:47:41 -0700 (PDT) (envelope-from thomas.kunz@sit.fraunhofer.de)
Received: from localhost (localhost [127.0.0.1]) by mailext.sit.fraunhofer.de (8.12.10/8.12.10) with ESMTP id i7UK4NL4008447 for <ietf-ltans@imc.org>; Mon, 30 Aug 2004 22:04:24 +0200
Received: from pD9F6E359.dip.t-dialin.net (pD9F6E359.dip.t-dialin.net [217.246.227.89]) by mailext.sit.fraunhofer.de (Horde) with HTTP for <kunz@mailext.sit.fraunhofer.de>; Mon, 30 Aug 2004 22:04:23 +0200
Message-ID: <1093896263.549wjk8xskn4@mailext.sit.fraunhofer.de>
Date: Mon, 30 Aug 2004 22:04:23 +0200
From: Thomas Kunz <thomas.kunz@sit.fraunhofer.de>
To: ietf-ltans@imc.org
Subject: Scenarios for notary services
MIME-Version: 1.0
Content-Type: text/plain; charset="ISO-8859-1"
Content-Disposition: inline
User-Agent: Internet Messaging Program (IMP) 4.0-cvs
X-Originating-IP:  217.246.227.89
X-Organisation:  Fraunhofer-SIT
X-Virus-Scanned: by amavisd-new
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i7UJlg5W097408
Sender: owner-ietf-ltans@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-ltans/mail-archive/>
List-Unsubscribe: <mailto:ietf-ltans-request@imc.org?body=unsubscribe>
List-ID: <ietf-ltans.imc.org>

Hello,

to corroborate the case for notary services in general, we would like
to supplement the use-case section of the requirements doc by some
more concrete, yet still rather generic, scenarios.
We think it fit to include the following section in the document:

4. Scenarios

This sections describes some concrete scenarios based on the use cases
introduced in section 3.

4.1 Record transactions
The following example will show the additional benefits of a notary
service in the case of private transactions.


We start with a basic protocol that achieves, upon completion, a state
of mutual non-repudiation between two parties, A and B.
Suppose, A wants to offer an electronic contract (contract_A) to B,
where "contract_A" means that A has digitally signed the contract with
her private key. This is sent as an offer to B:

contract_A -> B

B, after receiving and accepting contract_A, counter-signs the contract
and sends it back to A as an acceptance of A's offer:

(contract_A)_B -> A

Now, A has to confirm reception of the acceptance. He signs
(contract_A)_B and sends it back to B:

((contract_A)_B)_A -> B

After that, both parties have a document with at least two signatures,
and neither party can succeed in repudiating the validity of the
contract.

Now let's see what happens when we put a notary service N as a trusted
third party between A and B. When B gets the contract from A and
accepts it, he signs the contract and sends it to N:

(contract_A)_B -> N

The notary confirms receipt of the contract with a signature and sends
it to both A and B:

((contract_A)_B)_N -> A, B

After that, both parties have a document signed by A, B, and N. Since N
is trusted, A and B can be sure that the other party has a contract
which is signed by both. We have the same level of trust as in the
scenario without the notary service. However, an additional benefit
of using a notary in this case, can be to archive the contract, as may
be required by the law for certain types of contracts.

In order to allow for N to provide documentation that all necessary
information has been provided to both parties, the scenario can be
extended as follows:

When A and B get the confirmation ((contract_A)_B)_N from N,
both A and B send an acknowledgement to N:

ack_A -> N
ack_B -> N

After N received the two acknowledgements he sends a notification to
both A and B that confirms that the transaction is completed:

not_N -> A, B

For both ack_A/B and not_N it suffices to contain (sufficiently secure)
hash values of the pertaining original documents, and the same is true
for the third message sent from the notary in the protocol above, but
not for the second one, if the contract is to be archived by the notary.


The utility of notary services in these generic scenarios is twofold:
They can accomplish the fulfillment of technical requirements, e.g.,
archiving of transaction records, which may in turn be entailed by
legal requirements. And they can be instrumental in the fulfillment of
genuine legal requirements, like documentation that all necessary
information has been provided to all involved parties.

Best regards,

Andreas and Thomas

------------------------------------------------------------
Dipl. Inf. Thomas Kunz
Fraunhofer - Institut für Sichere Telekooperation (FhG-SIT)
Dolivostrasse 15
D-64293 Darmstadt (Germany)
Tel: +49-6151-869-60204
------------------------------------------------------------
e-mail: thomas.kunz@sit.fraunhofer.de

http://www.sit.fraunhofer.de
------------------------------------------------------------

---------------------------------------------------------------
Fraunhofer Institut Sichere Telekooperation
Fraunhofer Institute Secure Telekooperation

Diese Mail wurde per Webmail Interface versand.
This message was sent using Webmail Interface.
----------------------------------------------------------------




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7Q7KSH7073345; Thu, 26 Aug 2004 00:20:28 -0700 (PDT) (envelope-from owner-ietf-ltans@mail.imc.org)
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7Q7KSfq073344; Thu, 26 Aug 2004 00:20:28 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f
Received: from mail4.telekom.de (mail4.telekom.de [195.243.210.197]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7Q7KRbS073286 for <ietf-ltans@imc.org>; Thu, 26 Aug 2004 00:20:27 -0700 (PDT) (envelope-from ErnstG.Giessmann@t-systems.com)
Received: from U9JWN.mgb01.telekom.de by mail2.dmz.telekom.de with ESMTP for ietf-ltans@imc.org; Thu, 26 Aug 2004 09:19:24 +0200
Received: from mailgate9.telekom.de by U9JWN.mgb01.telekom.de with ESMTP for ietf-ltans@imc.org; Thu, 26 Aug 2004 09:18:49 +0200
Received: from bach.bln05.telekom.de by mailgate9.telekom.de (8.8.8/1.1.8.2/02Aug95-1122AM) id JAA0000001718; Thu, 26 Aug 2004 09:18:48 +0200 (MET DST)
Received: from [172.23.7.12] ([172.23.7.12]) by bach.bln05.telekom.de (8.8.8+Sun/8.8.8) with ESMTP id JAA09368 for <ietf-ltans@imc.org>; Thu, 26 Aug 2004 09:20:24 +0200 (MET DST)
Message-Id: <412D8EC5.7060707@t-systems.com>
Date: Thu, 26 Aug 2004 09:18:29 +0200
From: Ernst G Giessmann <ErnstG.Giessmann@t-systems.com>
User-Agent: Mozilla Thunderbird 0.7 (Windows/20040616)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "'IETF LTANS'" <ietf-ltans@imc.org>
Subject: Re: MD5, SHA-0
References: <000501c4894f$75b081a0$9a00a8c0@hq.orionsec.com> <412C4A09.1030407@bull.net>
In-Reply-To: <412C4A09.1030407@bull.net>
X-Enigmail-Version: 0.84.0.0
X-Enigmail-Supports: pgp-inline, pgp-mime
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-ietf-ltans@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-ltans/mail-archive/>
List-Unsubscribe: <mailto:ietf-ltans-request@imc.org?body=unsubscribe>
List-ID: <ietf-ltans.imc.org>

>> Larry:
>>
>> The initial reading is that SHA-1 is relatively safe, but people
>> should move
>> to SHA 256 within next 5 years.
>>
>> That said, LTANS does need to worry about what happens if the notary
>> has the
>> hash of the document.  If the hash gets broken, it dilutes the document
>> existence claim.

It dilutes the proof of the document existence claim via *that* hash. If
the document existence claim proof can be thickened by other means, you
are safe.

Denis Pinkas wrote:
> No. Apply a new time-stamp token with a new hash function.

Denis is right, this is a well known way of thickening.


>> I think one alternative is to use the encrypt scheme as ERS folks have
>> proposed for trusted archive.  Of course, the caveats in the ERS
>> encryption paper will apply.


Denis Pinkas wrote:
> Avoid any kind of encryption for that purpose.

Denis is right again: Encryption is the way to protect a document from
disclosure but *not* from a wrong existence claim.

Ernst.



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7PFcWG7048103; Wed, 25 Aug 2004 08:38:32 -0700 (PDT) (envelope-from owner-ietf-ltans@mail.imc.org)
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7PFcWF3048102; Wed, 25 Aug 2004 08:38:32 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f
Received: from igw (adsl-63-194-79-229.dsl.snfc21.pacbell.net [63.194.79.229]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7PFcVR0048081 for <ietf-ltans@imc.org>; Wed, 25 Aug 2004 08:38:31 -0700 (PDT) (envelope-from arshad.noor@strongauth.com)
Received: from noorhome.net (localhost [127.0.0.1]) by igw.noorhome.net (iPlanet Messaging Server 5.2 Patch 1 (built Aug 19 2002)) with ESMTP id <0I3000DGUD5ZXD@igw.noorhome.net> for ietf-ltans@imc.org; Wed, 25 Aug 2004 08:17:59 -0700 (PDT)
Received: from [12.18.36.40] by igw.noorhome.net (mshttpd); Wed, 25 Aug 2004 11:17:59 -0400
Date: Wed, 25 Aug 2004 11:17:59 -0400
From: Arshad Noor <arshad.noor@strongauth.com>
Subject: Re: RE: RE: MD5, SHA-0
To: Richard Hansberger <rhansberger@nationalnotary.org>
Cc: "'ietf-ltans@imc.org'" <ietf-ltans@imc.org>
Message-id: <37357636.76363735@noorhome.net>
MIME-version: 1.0
X-Mailer: iPlanet Messenger Express 5.2 Patch 1 (built Aug 19 2002)
Content-type: multipart/mixed; boundary="Boundary_(ID_buIBGRozu9VfNhYJWAZceQ)"
Content-language: en
X-Accept-Language: en
Sender: owner-ietf-ltans@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-ltans/mail-archive/>
List-Unsubscribe: <mailto:ietf-ltans-request@imc.org?body=unsubscribe>
List-ID: <ietf-ltans.imc.org>

This is a multi-part message in MIME format.

--Boundary_(ID_buIBGRozu9VfNhYJWAZceQ)
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7BIT
Content-disposition: inline

Richard,

Thank you for shedding more light on the subject.  Can you point me to
information on the electronic notarization pilots?  I am most interested
in the one in CA, but am also keen on knowing how the remaining three
states are implementing it.

Thank you.

Arshad Noor
StrongAuth, Inc.

----- Original Message -----
From: Richard Hansberger <rhansberger@nationalnotary.org>
Date: Wednesday, August 25, 2004 12:13 pm
Subject: RE: RE: MD5, SHA-0

> I hope some of this information is useful; I can provide specific
> documentation if necessary.
> 
> Many state laws mandate that Notaries may NOT notarize documents 
> with "blank
> or incomplete" spaces. Notaries are expected to review documents 
> carefully,though not to interpret them for signers. In every case 
> and in every state,
> the signer MUST appear before the Notary. Physical presence of the 
> signerbefore the Notary is almost the entire premise of notarization.
> 
> Acknowledgments and jurats are only two types of notarial acts. 
> There are at
> least 7 others (off the top of my head). What is common to them 
> all is a
> notarial certificate that contains wording indicating the act 
> performed. By
> far, however, acknowledgments and jurats comprise the bulk of what 
> Notariesdo on a daily basis.
> 
> California actually does have provisions for electronic 
> notarization (we are
> running pilots right now), and three other states do as well: CO, 
> AZ, PA.
> 
> Richard J. Hansberger
> Director of eNotarization
> National Notary Association
> 818-739-4027
> 
> -----Original Message-----
> From: Arshad Noor [mailto:arshad.noor@strongauth.com] 
> Sent: Wednesday, August 25, 2004 5:17 AM
> To: Santosh Chokhani
> Cc: 'IETF LTANS'
> Subject: Re: RE: MD5, SHA-0
> 
> 
> 
> I cannot speak for the French (or for that matter, for the 
> remaining 49
> states 
> of the US), but the State of California requires that Notaries 
> must review
> the 
> document BEFORE the document signer signs it (I would presume that 
> this 
> may be a uniform requirement in the US).
> 
> Notaries sign two types of documents - Acknowledgements and 
> Jurats.  An
> Acknowledgement witnesses the actual act of the document signer 
> signing 
> the document, while in the Jurat, the document signer must swear 
> to veracity
> 
> of the contents of the document before signing it.  In both cases, the
> Notary 
> MUST review the unsigned paper document, and witness the signer 
> signing the
> document before he/she notarizes it.  
> 
> There are no laws around electronic notarization in CA, and it 
> might be
> prudent to not use the word "Notary" or "Notarization" with such 
> servicesuntil there is a law that defines it - we may risk 
> diluting the meaning of
> the word in the paper world.
> 
> Arshad Noor
> StrongAuth, Inc.
> 
> 
> ----- Original Message -----
> From: Santosh Chokhani <chokhani@orionsec.com>
> Date: Wednesday, August 25, 2004 7:50 am
> Subject: RE: MD5, SHA-0
> 
> > 
> > Denis:
> > 
> > If we assume that notary notarizes the original document, we do
> > not have a
> > problem.
> > 
> > Larry:
> > 
> > Should the notary requirement make this clear?
> > 
> > -----Original Message-----
> > From: Denis Pinkas [mailto:Denis.Pinkas@bull.net]
> > Sent: Wednesday, August 25, 2004 7:35 AM
> > To: Santosh Chokhani
> > Cc: 'IETF LTANS'
> > Subject: Re: MD5, SHA-0
> > 
> > 
> > Santosh,
> > 
> > > Carl, Denis:
> > > 
> > > My response was terse.  I assumed that the question was prompted
> > with
> > > when the Notary is given only the hash in the first place for
> > the
> > > reasons of confidentiality.
> > 
> > Hum, hum !!!
> > 
> > My undersnding of the primary role of a notary (at least under the
> > French 
> > legislation) is to look at the content of the document (already 
> > signed) 
> > before applying his own signature. Therefor I have some 
> > difficulties with 
> > schemes where the Notary would not have access to the semantics 
> of 
> > the 
> > document. Otherwise the word "Notary" should not be used for 
> that 
> > case.
> > Denis
> > 
> > 
> > 
> > > Thus, I was proposing that to preserve the confidentiality
> > desired b
> > > the submitter, we look into ERS encryption approach.
> > > 
> > > -----Original Message-----
> > > From: Denis Pinkas [mailto:Denis.Pinkas@bull.net]
> > > Sent: Wednesday, August 25, 2004 4:13 AM
> > > To: Santosh Chokhani
> > > Cc: 'IETF LTANS'
> > > Subject: Re: MD5, SHA-0
> > > 
> > > 
> > > Santosh,
> > > 
> > > 
> > >>Larry:
> > >>
> > >>The initial reading is that SHA-1 is relatively safe, but 
> people 
> > >>should move to SHA 256 within next 5 years.
> > >>
> > >>That said, LTANS does need to worry about what happens if the 
> notary 
> > >>has the hash of the document.  If the hash gets broken, it
> > dilutes the
> > >>document existence claim.
> > > 
> > > 
> > > No. Apply a new time-stamp token with a new hash function.
> > > 
> > > 
> > >>I think one alternative is to use the encrypt scheme as ERS
> > folks have
> > >>proposed for trusted archive.  Of course, the caveats in the ERS
> > >>encryption paper will apply.
> > > 
> > > 
> > > Avoid any kind of encryption for that purpose.
> > > 
> > > Denis
> > > 
> > > 
> > >>-----Original Message-----
> > >>From: owner-ietf-ltans@mail.imc.org 
> > >>[mailto:owner-ietf-ltans@mail.imc.org]
> > >>On Behalf Of Larry Masinter
> > >>Sent: Wednesday, August 18, 2004 2:26 AM
> > >>To: 'IETF LTANS'
> > >>Subject: MD5, SHA-0
> > >>
> > >>
> > >>
> > >>It's sometimes hard to discern technical details in news 
> articles. 
> > >>Anyone have a more reliable source on what happened at Crypto 
> 2004?> >>
> > >>http://news.com.com/Crypto+researchers+abuzz+over+flaws/2100-
> > 1002_3-53
> > >>13655.
> > >>html
> > >>
> > >>I still haven't understood, for notary services, if
> > >>the notary service doesn't have the original document
> > >>but just the hash, what happens when the hash algorithm
> > >>is compromised?
> > >>
> > >>Larry
> > > 
> > > 
> > > 
> > > 
> > 
> > 
> > 

--Boundary_(ID_buIBGRozu9VfNhYJWAZceQ)
Content-type: text/plain
Content-transfer-encoding: 7BIT
Content-disposition: inline

This email message and any files transmitted with it contain confidential information intended only for the person(s) to whom this email message is addressed.  If you have received this email message in error, please notify the sender immediately.

--Boundary_(ID_buIBGRozu9VfNhYJWAZceQ)--



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7PFGVHn043057; Wed, 25 Aug 2004 08:16:31 -0700 (PDT) (envelope-from owner-ietf-ltans@mail.imc.org)
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7PFGVnJ043056; Wed, 25 Aug 2004 08:16:31 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f
Received: from MessageInpector.nationalnotary.org (mail.nationalnotary.org [65.115.114.141]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7PFGU4h043038 for <ietf-ltans@imc.org>; Wed, 25 Aug 2004 08:16:30 -0700 (PDT) (envelope-from rhansberger@nationalnotary.org)
Received: from louise2.nationalnotary.org (LOUISE2 [192.168.1.247]) by MessageInpector.nationalnotary.org (Switch-2.2.8/Switch-2.2.4) with ESMTP id W7PG0D3700000108 for <ietf-ltans@imc.org>; Wed, 25 Aug 2004 08:13:03 -0800
Received: by Louise2 with Internet Mail Service (5.5.2657.72) id <RKG7HA9H>; Wed, 25 Aug 2004 08:13:33 -0800
Message-ID: <561F9357D239EB428AE3A4F14244431303946C@Louise2>
From: Richard Hansberger <rhansberger@nationalnotary.org>
To: "'ietf-ltans@imc.org'" <ietf-ltans@imc.org>
Subject: RE: RE: MD5, SHA-0
Date: Wed, 25 Aug 2004 08:13:31 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
Content-Type: multipart/mixed; boundary="--123456789-987654321-abcdefg"
X-MessageInspectorSig: 8efbd4336c30e6281c4c93b5ba69208e
Sender: owner-ietf-ltans@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-ltans/mail-archive/>
List-Unsubscribe: <mailto:ietf-ltans-request@imc.org?body=unsubscribe>
List-ID: <ietf-ltans.imc.org>

----123456789-987654321-abcdefg
Content-Type: text/plain

I hope some of this information is useful; I can provide specific
documentation if necessary.

Many state laws mandate that Notaries may NOT notarize documents with "blank
or incomplete" spaces. Notaries are expected to review documents carefully,
though not to interpret them for signers. In every case and in every state,
the signer MUST appear before the Notary. Physical presence of the signer
before the Notary is almost the entire premise of notarization.

Acknowledgments and jurats are only two types of notarial acts. There are at
least 7 others (off the top of my head). What is common to them all is a
notarial certificate that contains wording indicating the act performed. By
far, however, acknowledgments and jurats comprise the bulk of what Notaries
do on a daily basis.

California actually does have provisions for electronic notarization (we are
running pilots right now), and three other states do as well: CO, AZ, PA.

Richard J. Hansberger
Director of eNotarization
National Notary Association
818-739-4027

-----Original Message-----
From: Arshad Noor [mailto:arshad.noor@strongauth.com] 
Sent: Wednesday, August 25, 2004 5:17 AM
To: Santosh Chokhani
Cc: 'IETF LTANS'
Subject: Re: RE: MD5, SHA-0



I cannot speak for the French (or for that matter, for the remaining 49
states 
of the US), but the State of California requires that Notaries must review
the 
document BEFORE the document signer signs it (I would presume that this 
may be a uniform requirement in the US).

Notaries sign two types of documents - Acknowledgements and Jurats.  An
Acknowledgement witnesses the actual act of the document signer signing 
the document, while in the Jurat, the document signer must swear to veracity

of the contents of the document before signing it.  In both cases, the
Notary 
MUST review the unsigned paper document, and witness the signer signing the
document before he/she notarizes it.  

There are no laws around electronic notarization in CA, and it might be
prudent to not use the word "Notary" or "Notarization" with such services
until there is a law that defines it - we may risk diluting the meaning of
the word in the paper world.

Arshad Noor
StrongAuth, Inc.


----- Original Message -----
From: Santosh Chokhani <chokhani@orionsec.com>
Date: Wednesday, August 25, 2004 7:50 am
Subject: RE: MD5, SHA-0

> 
> Denis:
> 
> If we assume that notary notarizes the original document, we do
> not have a
> problem.
> 
> Larry:
> 
> Should the notary requirement make this clear?
> 
> -----Original Message-----
> From: Denis Pinkas [mailto:Denis.Pinkas@bull.net]
> Sent: Wednesday, August 25, 2004 7:35 AM
> To: Santosh Chokhani
> Cc: 'IETF LTANS'
> Subject: Re: MD5, SHA-0
> 
> 
> Santosh,
> 
> > Carl, Denis:
> > 
> > My response was terse.  I assumed that the question was prompted
> with
> > when the Notary is given only the hash in the first place for
> the
> > reasons of confidentiality.
> 
> Hum, hum !!!
> 
> My undersnding of the primary role of a notary (at least under the
> French 
> legislation) is to look at the content of the document (already 
> signed) 
> before applying his own signature. Therefor I have some 
> difficulties with 
> schemes where the Notary would not have access to the semantics of 
> the 
> document. Otherwise the word "Notary" should not be used for that 
> case.
> Denis
> 
> 
> 
> > Thus, I was proposing that to preserve the confidentiality
> desired b
> > the submitter, we look into ERS encryption approach.
> > 
> > -----Original Message-----
> > From: Denis Pinkas [mailto:Denis.Pinkas@bull.net]
> > Sent: Wednesday, August 25, 2004 4:13 AM
> > To: Santosh Chokhani
> > Cc: 'IETF LTANS'
> > Subject: Re: MD5, SHA-0
> > 
> > 
> > Santosh,
> > 
> > 
> >>Larry:
> >>
> >>The initial reading is that SHA-1 is relatively safe, but people 
> >>should move to SHA 256 within next 5 years.
> >>
> >>That said, LTANS does need to worry about what happens if the notary 
> >>has the hash of the document.  If the hash gets broken, it
> dilutes the
> >>document existence claim.
> > 
> > 
> > No. Apply a new time-stamp token with a new hash function.
> > 
> > 
> >>I think one alternative is to use the encrypt scheme as ERS
> folks have
> >>proposed for trusted archive.  Of course, the caveats in the ERS
> >>encryption paper will apply.
> > 
> > 
> > Avoid any kind of encryption for that purpose.
> > 
> > Denis
> > 
> > 
> >>-----Original Message-----
> >>From: owner-ietf-ltans@mail.imc.org 
> >>[mailto:owner-ietf-ltans@mail.imc.org]
> >>On Behalf Of Larry Masinter
> >>Sent: Wednesday, August 18, 2004 2:26 AM
> >>To: 'IETF LTANS'
> >>Subject: MD5, SHA-0
> >>
> >>
> >>
> >>It's sometimes hard to discern technical details in news articles. 
> >>Anyone have a more reliable source on what happened at Crypto 2004?
> >>
> >>http://news.com.com/Crypto+researchers+abuzz+over+flaws/2100-
> 1002_3-53
> >>13655.
> >>html
> >>
> >>I still haven't understood, for notary services, if
> >>the notary service doesn't have the original document
> >>but just the hash, what happens when the hash algorithm
> >>is compromised?
> >>
> >>Larry
> > 
> > 
> > 
> > 
> 
> 
> 
----123456789-987654321-abcdefg
Content-Type: text/plain
Content-Disposition: inline

This email message and any files transmitted with it contain confidential information intended only for the person(s) to whom this email message is addressed.  If you have received this email message in error, please notify the sender immediately.

----123456789-987654321-abcdefg--



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7PDbS74019011; Wed, 25 Aug 2004 06:37:28 -0700 (PDT) (envelope-from owner-ietf-ltans@mail.imc.org)
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7PDbSUP019010; Wed, 25 Aug 2004 06:37:28 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f
Received: from igw (adsl-63-194-79-229.dsl.snfc21.pacbell.net [63.194.79.229]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7PDbRIW018987 for <ietf-ltans@imc.org>; Wed, 25 Aug 2004 06:37:27 -0700 (PDT) (envelope-from arshad.noor@strongauth.com)
Received: from noorhome.net (localhost [127.0.0.1]) by igw.noorhome.net (iPlanet Messaging Server 5.2 Patch 1 (built Aug 19 2002)) with ESMTP id <0I3000DAS7K0XD@igw.noorhome.net> for ietf-ltans@imc.org; Wed, 25 Aug 2004 06:16:48 -0700 (PDT)
Received: from [12.18.36.40] by igw.noorhome.net (mshttpd); Wed, 25 Aug 2004 09:16:48 -0400
Date: Wed, 25 Aug 2004 09:16:48 -0400
From: Arshad Noor <arshad.noor@strongauth.com>
Subject: Re: RE: MD5, SHA-0
To: Santosh Chokhani <chokhani@orionsec.com>
Cc: "'IETF LTANS'" <ietf-ltans@imc.org>
Message-id: <876a6d38.6d38876a@noorhome.net>
MIME-version: 1.0
X-Mailer: iPlanet Messenger Express 5.2 Patch 1 (built Aug 19 2002)
Content-type: text/plain; charset=us-ascii
Content-language: en
Content-transfer-encoding: 7BIT
Content-disposition: inline
X-Accept-Language: en
Sender: owner-ietf-ltans@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-ltans/mail-archive/>
List-Unsubscribe: <mailto:ietf-ltans-request@imc.org?body=unsubscribe>
List-ID: <ietf-ltans.imc.org>

I cannot speak for the French (or for that matter, for the remaining 49 states 
of the US), but the State of California requires that Notaries must review the 
document BEFORE the document signer signs it (I would presume that this 
may be a uniform requirement in the US).

Notaries sign two types of documents - Acknowledgements and Jurats.  An
Acknowledgement witnesses the actual act of the document signer signing 
the document, while in the Jurat, the document signer must swear to veracity 
of the contents of the document before signing it.  In both cases, the Notary 
MUST review the unsigned paper document, and witness the signer signing
the document before he/she notarizes it.  

There are no laws around electronic notarization in CA, and it might be prudent
to not use the word "Notary" or "Notarization" with such services until there is
a law that defines it - we may risk diluting the meaning of the word in the paper
world.

Arshad Noor
StrongAuth, Inc.


----- Original Message -----
From: Santosh Chokhani <chokhani@orionsec.com>
Date: Wednesday, August 25, 2004 7:50 am
Subject: RE: MD5, SHA-0

> 
> Denis:
> 
> If we assume that notary notarizes the original document, we do 
> not have a
> problem.
> 
> Larry:
> 
> Should the notary requirement make this clear? 
> 
> -----Original Message-----
> From: Denis Pinkas [mailto:Denis.Pinkas@bull.net] 
> Sent: Wednesday, August 25, 2004 7:35 AM
> To: Santosh Chokhani
> Cc: 'IETF LTANS'
> Subject: Re: MD5, SHA-0
> 
> 
> Santosh,
> 
> > Carl, Denis:
> > 
> > My response was terse.  I assumed that the question was prompted 
> with 
> > when the Notary is given only the hash in the first place for 
> the 
> > reasons of confidentiality.
> 
> Hum, hum !!!
> 
> My undersnding of the primary role of a notary (at least under the 
> French 
> legislation) is to look at the content of the document (already 
> signed) 
> before applying his own signature. Therefor I have some 
> difficulties with 
> schemes where the Notary would not have access to the semantics of 
> the 
> document. Otherwise the word "Notary" should not be used for that 
> case.
> Denis
> 
> 
> 
> > Thus, I was proposing that to preserve the confidentiality 
> desired b 
> > the submitter, we look into ERS encryption approach.
> > 
> > -----Original Message-----
> > From: Denis Pinkas [mailto:Denis.Pinkas@bull.net]
> > Sent: Wednesday, August 25, 2004 4:13 AM
> > To: Santosh Chokhani
> > Cc: 'IETF LTANS'
> > Subject: Re: MD5, SHA-0
> > 
> > 
> > Santosh,
> > 
> > 
> >>Larry:
> >>
> >>The initial reading is that SHA-1 is relatively safe, but people
> >>should move to SHA 256 within next 5 years.
> >>
> >>That said, LTANS does need to worry about what happens if the notary
> >>has the hash of the document.  If the hash gets broken, it 
> dilutes the 
> >>document existence claim.
> > 
> > 
> > No. Apply a new time-stamp token with a new hash function.
> > 
> > 
> >>I think one alternative is to use the encrypt scheme as ERS 
> folks have
> >>proposed for trusted archive.  Of course, the caveats in the ERS 
> >>encryption paper will apply.
> > 
> > 
> > Avoid any kind of encryption for that purpose.
> > 
> > Denis
> > 
> > 
> >>-----Original Message-----
> >>From: owner-ietf-ltans@mail.imc.org
> >>[mailto:owner-ietf-ltans@mail.imc.org]
> >>On Behalf Of Larry Masinter
> >>Sent: Wednesday, August 18, 2004 2:26 AM
> >>To: 'IETF LTANS'
> >>Subject: MD5, SHA-0
> >>
> >>
> >>
> >>It's sometimes hard to discern technical details in news articles.
> >>Anyone have a more reliable source on what happened at Crypto 2004?
> >>
> >>http://news.com.com/Crypto+researchers+abuzz+over+flaws/2100-
> 1002_3-53
> >>13655.
> >>html
> >>
> >>I still haven't understood, for notary services, if
> >>the notary service doesn't have the original document
> >>but just the hash, what happens when the hash algorithm
> >>is compromised?
> >>
> >>Larry
> > 
> > 
> > 
> > 
> 
> 
> 



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7PBoCba096736; Wed, 25 Aug 2004 04:50:12 -0700 (PDT) (envelope-from owner-ietf-ltans@mail.imc.org)
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7PBoCYt096735; Wed, 25 Aug 2004 04:50:12 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f
Received: from host13.websitesource.com (host13.websitesource.com [209.239.35.152]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7PBoC90096725 for <ietf-ltans@imc.org>; Wed, 25 Aug 2004 04:50:12 -0700 (PDT) (envelope-from chokhani@orionsec.com)
Received: from wchokhani3 (pcp09271907pcs.arlngt01.va.comcast.net [69.143.130.247]) by host13.websitesource.com (8.12.10/8.12.10) with ESMTP id i7PBoDod016832 for <ietf-ltans@imc.org>; Wed, 25 Aug 2004 07:50:13 -0400
From: "Santosh Chokhani" <chokhani@orionsec.com>
To: "'IETF LTANS'" <ietf-ltans@imc.org>
Subject: RE: MD5, SHA-0
Date: Wed, 25 Aug 2004 07:50:07 -0400
Message-ID: <006201c48a99$ae44a460$aa02a8c0@hq.orionsec.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.6626
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441
In-Reply-To: <412C797C.90102@bull.net>
Sender: owner-ietf-ltans@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-ltans/mail-archive/>
List-Unsubscribe: <mailto:ietf-ltans-request@imc.org?body=unsubscribe>
List-ID: <ietf-ltans.imc.org>

Denis:

If we assume that notary notarizes the original document, we do not have a
problem.

Larry:

Should the notary requirement make this clear? 

-----Original Message-----
From: Denis Pinkas [mailto:Denis.Pinkas@bull.net] 
Sent: Wednesday, August 25, 2004 7:35 AM
To: Santosh Chokhani
Cc: 'IETF LTANS'
Subject: Re: MD5, SHA-0


Santosh,

> Carl, Denis:
> 
> My response was terse.  I assumed that the question was prompted with 
> when the Notary is given only the hash in the first place for the 
> reasons of confidentiality.

Hum, hum !!!

My undersnding of the primary role of a notary (at least under the French 
legislation) is to look at the content of the document (already signed) 
before applying his own signature. Therefor I have some difficulties with 
schemes where the Notary would not have access to the semantics of the 
document. Otherwise the word "Notary" should not be used for that case.

Denis



> Thus, I was proposing that to preserve the confidentiality desired b 
> the submitter, we look into ERS encryption approach.
> 
> -----Original Message-----
> From: Denis Pinkas [mailto:Denis.Pinkas@bull.net]
> Sent: Wednesday, August 25, 2004 4:13 AM
> To: Santosh Chokhani
> Cc: 'IETF LTANS'
> Subject: Re: MD5, SHA-0
> 
> 
> Santosh,
> 
> 
>>Larry:
>>
>>The initial reading is that SHA-1 is relatively safe, but people
>>should move to SHA 256 within next 5 years.
>>
>>That said, LTANS does need to worry about what happens if the notary
>>has the hash of the document.  If the hash gets broken, it dilutes the 
>>document existence claim.
> 
> 
> No. Apply a new time-stamp token with a new hash function.
> 
> 
>>I think one alternative is to use the encrypt scheme as ERS folks have
>>proposed for trusted archive.  Of course, the caveats in the ERS 
>>encryption paper will apply.
> 
> 
> Avoid any kind of encryption for that purpose.
> 
> Denis
> 
> 
>>-----Original Message-----
>>From: owner-ietf-ltans@mail.imc.org
>>[mailto:owner-ietf-ltans@mail.imc.org]
>>On Behalf Of Larry Masinter
>>Sent: Wednesday, August 18, 2004 2:26 AM
>>To: 'IETF LTANS'
>>Subject: MD5, SHA-0
>>
>>
>>
>>It's sometimes hard to discern technical details in news articles.
>>Anyone have a more reliable source on what happened at Crypto 2004?
>>
>>http://news.com.com/Crypto+researchers+abuzz+over+flaws/2100-1002_3-53
>>13655.
>>html
>>
>>I still haven't understood, for notary services, if
>>the notary service doesn't have the original document
>>but just the hash, what happens when the hash algorithm
>>is compromised?
>>
>>Larry
> 
> 
> 
> 




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7PBbtvx092984; Wed, 25 Aug 2004 04:37:55 -0700 (PDT) (envelope-from owner-ietf-ltans@mail.imc.org)
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7PBbtJ0092983; Wed, 25 Aug 2004 04:37:55 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7PBbr3n092972 for <ietf-ltans@imc.org>; Wed, 25 Aug 2004 04:37:54 -0700 (PDT) (envelope-from Denis.Pinkas@bull.net)
Received: from clbull.frcl.bull.fr (IDENT:root@clbull.frcl.bull.fr [129.182.8.31]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id NAA65290; Wed, 25 Aug 2004 13:48:41 +0200
Received: from bull.net (frcls4013.frcl.bull.fr [129.182.108.120]) by clbull.frcl.bull.fr (8.9.3/8.9.3) with ESMTP id NAA16842; Wed, 25 Aug 2004 13:28:04 +0200
Message-ID: <412C797C.90102@bull.net>
Date: Wed, 25 Aug 2004 13:35:24 +0200
From: Denis Pinkas <Denis.Pinkas@bull.net>
Organization: Bull SA.
User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0
X-Accept-Language: en-us, en, fr
MIME-Version: 1.0
To: Santosh Chokhani <chokhani@orionsec.com>
CC: "'IETF LTANS'" <ietf-ltans@imc.org>
Subject: Re: MD5, SHA-0
References: <004001c48a95$82492b50$aa02a8c0@hq.orionsec.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-ietf-ltans@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-ltans/mail-archive/>
List-Unsubscribe: <mailto:ietf-ltans-request@imc.org?body=unsubscribe>
List-ID: <ietf-ltans.imc.org>

Santosh,

> Carl, Denis:
> 
> My response was terse.  I assumed that the question was prompted with when
> the Notary is given only the hash in the first place for the reasons of
> confidentiality.

Hum, hum !!!

My undersnding of the primary role of a notary (at least under the French 
legislation) is to look at the content of the document (already signed) 
before applying his own signature. Therefor I have some difficulties with 
schemes where the Notary would not have access to the semantics of the 
document. Otherwise the word "Notary" should not be used for that case.

Denis



> Thus, I was proposing that to preserve the confidentiality desired b the
> submitter, we look into ERS encryption approach.
> 
> -----Original Message-----
> From: Denis Pinkas [mailto:Denis.Pinkas@bull.net] 
> Sent: Wednesday, August 25, 2004 4:13 AM
> To: Santosh Chokhani
> Cc: 'IETF LTANS'
> Subject: Re: MD5, SHA-0
> 
> 
> Santosh,
> 
> 
>>Larry:
>>
>>The initial reading is that SHA-1 is relatively safe, but people 
>>should move to SHA 256 within next 5 years.
>>
>>That said, LTANS does need to worry about what happens if the notary 
>>has the hash of the document.  If the hash gets broken, it dilutes the 
>>document existence claim.
> 
> 
> No. Apply a new time-stamp token with a new hash function.
> 
> 
>>I think one alternative is to use the encrypt scheme as ERS folks have 
>>proposed for trusted archive.  Of course, the caveats in the ERS 
>>encryption paper will apply.
> 
> 
> Avoid any kind of encryption for that purpose.
> 
> Denis
> 
> 
>>-----Original Message-----
>>From: owner-ietf-ltans@mail.imc.org 
>>[mailto:owner-ietf-ltans@mail.imc.org]
>>On Behalf Of Larry Masinter
>>Sent: Wednesday, August 18, 2004 2:26 AM
>>To: 'IETF LTANS'
>>Subject: MD5, SHA-0
>>
>>
>>
>>It's sometimes hard to discern technical details in news articles. 
>>Anyone have a more reliable source on what happened at Crypto 2004?
>>
>>http://news.com.com/Crypto+researchers+abuzz+over+flaws/2100-1002_3-53
>>13655.
>>html
>>
>>I still haven't understood, for notary services, if
>>the notary service doesn't have the original document
>>but just the hash, what happens when the hash algorithm
>>is compromised?
>>
>>Larry
> 
> 
> 
> 




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7PBKLUT089216; Wed, 25 Aug 2004 04:20:21 -0700 (PDT) (envelope-from owner-ietf-ltans@mail.imc.org)
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7PBKLOn089215; Wed, 25 Aug 2004 04:20:21 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f
Received: from host13.websitesource.com (host13.websitesource.com [209.239.35.152]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7PBKKHS089209 for <ietf-ltans@imc.org>; Wed, 25 Aug 2004 04:20:20 -0700 (PDT) (envelope-from chokhani@orionsec.com)
Received: from wchokhani3 (pcp09271907pcs.arlngt01.va.comcast.net [69.143.130.247]) by host13.websitesource.com (8.12.10/8.12.10) with ESMTP id i7PBKLod009706 for <ietf-ltans@imc.org>; Wed, 25 Aug 2004 07:20:21 -0400
From: "Santosh Chokhani" <chokhani@orionsec.com>
To: "'IETF LTANS'" <ietf-ltans@imc.org>
Subject: RE: MD5, SHA-0
Date: Wed, 25 Aug 2004 07:20:15 -0400
Message-ID: <004001c48a95$82492b50$aa02a8c0@hq.orionsec.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.6626
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441
In-Reply-To: <412C4A09.1030407@bull.net>
Sender: owner-ietf-ltans@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-ltans/mail-archive/>
List-Unsubscribe: <mailto:ietf-ltans-request@imc.org?body=unsubscribe>
List-ID: <ietf-ltans.imc.org>

Carl, Denis:

My response was terse.  I assumed that the question was prompted with when
the Notary is given only the hash in the first place for the reasons of
confidentiality.

Thus, I was proposing that to preserve the confidentiality desired b the
submitter, we look into ERS encryption approach.

-----Original Message-----
From: Denis Pinkas [mailto:Denis.Pinkas@bull.net] 
Sent: Wednesday, August 25, 2004 4:13 AM
To: Santosh Chokhani
Cc: 'IETF LTANS'
Subject: Re: MD5, SHA-0


Santosh,

> Larry:
> 
> The initial reading is that SHA-1 is relatively safe, but people 
> should move to SHA 256 within next 5 years.
> 
> That said, LTANS does need to worry about what happens if the notary 
> has the hash of the document.  If the hash gets broken, it dilutes the 
> document existence claim.

No. Apply a new time-stamp token with a new hash function.

> I think one alternative is to use the encrypt scheme as ERS folks have 
> proposed for trusted archive.  Of course, the caveats in the ERS 
> encryption paper will apply.

Avoid any kind of encryption for that purpose.

Denis

> -----Original Message-----
> From: owner-ietf-ltans@mail.imc.org 
> [mailto:owner-ietf-ltans@mail.imc.org]
> On Behalf Of Larry Masinter
> Sent: Wednesday, August 18, 2004 2:26 AM
> To: 'IETF LTANS'
> Subject: MD5, SHA-0
> 
> 
> 
> It's sometimes hard to discern technical details in news articles. 
> Anyone have a more reliable source on what happened at Crypto 2004?
> 
> http://news.com.com/Crypto+researchers+abuzz+over+flaws/2100-1002_3-53
> 13655.
> html
> 
> I still haven't understood, for notary services, if
> the notary service doesn't have the original document
> but just the hash, what happens when the hash algorithm
> is compromised?
> 
> Larry




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7PAgJvs080955; Wed, 25 Aug 2004 03:42:19 -0700 (PDT) (envelope-from owner-ietf-ltans@mail.imc.org)
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7PAgJak080954; Wed, 25 Aug 2004 03:42:19 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f
Received: from host13.websitesource.com (host13.websitesource.com [209.239.35.152]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7PAgJ8G080930 for <ietf-ltans@imc.org>; Wed, 25 Aug 2004 03:42:19 -0700 (PDT) (envelope-from cwallace@orionsec.com)
Received: from wcwallace (dpvc-138-88-161-20.res.east.verizon.net [138.88.161.20]) by host13.websitesource.com (8.12.10/8.12.10) with ESMTP id i7PAgHod032208 for <ietf-ltans@imc.org>; Wed, 25 Aug 2004 06:42:17 -0400
Message-Id: <200408251042.i7PAgHod032208@host13.websitesource.com>
From: "Carl Wallace" <cwallace@orionsec.com>
To: "'IETF LTANS'" <ietf-ltans@imc.org>
Subject: RE: MD5, SHA-0
Date: Wed, 25 Aug 2004 06:42:17 -0400
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook, Build 11.0.5510
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441
In-Reply-To: <412C4A09.1030407@bull.net>
Thread-Index: AcSKfYT985ePK1amTgWCgfEoyYAoggAEj4nw
Sender: owner-ietf-ltans@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-ltans/mail-archive/>
List-Unsubscribe: <mailto:ietf-ltans-request@imc.org?body=unsubscribe>
List-ID: <ietf-ltans.imc.org>

> > That said, LTANS does need to worry about what happens if 
> the notary 
> > has the hash of the document.  If the hash gets broken, it 
> dilutes the 
> > document existence claim.
> 
> No. Apply a new time-stamp token with a new hash function.

For what data should a new time-stamp token based on a new hash function be
obtained?  In this thread, the question related to the case where the notary
has only a hash of the original document.



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7P8FYfx039473; Wed, 25 Aug 2004 01:15:34 -0700 (PDT) (envelope-from owner-ietf-ltans@mail.imc.org)
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7P8FYV1039472; Wed, 25 Aug 2004 01:15:34 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7P8FVEn039436 for <ietf-ltans@imc.org>; Wed, 25 Aug 2004 01:15:33 -0700 (PDT) (envelope-from Denis.Pinkas@bull.net)
Received: from clbull.frcl.bull.fr (IDENT:root@clbull.frcl.bull.fr [129.182.8.31]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id KAA59412; Wed, 25 Aug 2004 10:26:15 +0200
Received: from bull.net (frcls4013.frcl.bull.fr [129.182.108.120]) by clbull.frcl.bull.fr (8.9.3/8.9.3) with ESMTP id KAA15048; Wed, 25 Aug 2004 10:05:37 +0200
Message-ID: <412C4A09.1030407@bull.net>
Date: Wed, 25 Aug 2004 10:12:57 +0200
From: Denis Pinkas <Denis.Pinkas@bull.net>
Organization: Bull SA.
User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0
X-Accept-Language: en-us, en, fr
MIME-Version: 1.0
To: Santosh Chokhani <chokhani@orionsec.com>
CC: "'IETF LTANS'" <ietf-ltans@imc.org>
Subject: Re: MD5, SHA-0
References: <000501c4894f$75b081a0$9a00a8c0@hq.orionsec.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-ietf-ltans@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-ltans/mail-archive/>
List-Unsubscribe: <mailto:ietf-ltans-request@imc.org?body=unsubscribe>
List-ID: <ietf-ltans.imc.org>

Santosh,

> Larry:
> 
> The initial reading is that SHA-1 is relatively safe, but people should move
> to SHA 256 within next 5 years.
> 
> That said, LTANS does need to worry about what happens if the notary has the
> hash of the document.  If the hash gets broken, it dilutes the document
> existence claim.

No. Apply a new time-stamp token with a new hash function.

> I think one alternative is to use the encrypt scheme as ERS folks have
> proposed for trusted archive.  Of course, the caveats in the ERS encryption
> paper will apply.

Avoid any kind of encryption for that purpose.

Denis

> -----Original Message-----
> From: owner-ietf-ltans@mail.imc.org [mailto:owner-ietf-ltans@mail.imc.org]
> On Behalf Of Larry Masinter
> Sent: Wednesday, August 18, 2004 2:26 AM
> To: 'IETF LTANS'
> Subject: MD5, SHA-0
> 
> 
> 
> It's sometimes hard to discern technical details in news articles. Anyone
> have a more reliable source on what happened at Crypto 2004?
> 
> http://news.com.com/Crypto+researchers+abuzz+over+flaws/2100-1002_3-5313655.
> html
> 
> I still haven't understood, for notary services, if
> the notary service doesn't have the original document
> but just the hash, what happens when the hash algorithm
> is compromised?
> 
> Larry




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7NKQO3i031246; Mon, 23 Aug 2004 13:26:24 -0700 (PDT) (envelope-from owner-ietf-ltans@mail.imc.org)
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7NKQOxY031245; Mon, 23 Aug 2004 13:26:24 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f
Received: from host13.websitesource.com (host13.websitesource.com [209.239.35.152]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7NKQOW0031235 for <ietf-ltans@imc.org>; Mon, 23 Aug 2004 13:26:24 -0700 (PDT) (envelope-from chokhani@orionsec.com)
Received: from wchokhani3 (dpvc-138-88-161-20.res.east.verizon.net [138.88.161.20]) by host13.websitesource.com (8.12.10/8.12.10) with ESMTP id i7NKQOod022970; Mon, 23 Aug 2004 16:26:24 -0400
From: "Santosh Chokhani" <chokhani@orionsec.com>
To: "'Larry Masinter'" <LMM@acm.org>, "'IETF LTANS'" <ietf-ltans@imc.org>
Subject: RE: MD5, SHA-0
Date: Mon, 23 Aug 2004 16:26:24 -0400
Message-ID: <000501c4894f$75b081a0$9a00a8c0@hq.orionsec.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.6626
Importance: Normal
In-Reply-To: <0I2M000T7PVZV1@mailsj-v1.corp.adobe.com>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i7NKQOW0031240
Sender: owner-ietf-ltans@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-ltans/mail-archive/>
List-Unsubscribe: <mailto:ietf-ltans-request@imc.org?body=unsubscribe>
List-ID: <ietf-ltans.imc.org>

Larry:

The initial reading is that SHA-1 is relatively safe, but people should move
to SHA 256 within next 5 years.

That said, LTANS does need to worry about what happens if the notary has the
hash of the document.  If the hash gets broken, it dilutes the document
existence claim.

I think one alternative is to use the encrypt scheme as ERS folks have
proposed for trusted archive.  Of course, the caveats in the ERS encryption
paper will apply.

-----Original Message-----
From: owner-ietf-ltans@mail.imc.org [mailto:owner-ietf-ltans@mail.imc.org]
On Behalf Of Larry Masinter
Sent: Wednesday, August 18, 2004 2:26 AM
To: 'IETF LTANS'
Subject: MD5, SHA-0



It's sometimes hard to discern technical details in news articles. Anyone
have a more reliable source on what happened at Crypto 2004?

http://news.com.com/Crypto+researchers+abuzz+over+flaws/2100-1002_3-5313655.
html

I still haven't understood, for notary services, if
the notary service doesn't have the original document
but just the hash, what happens when the hash algorithm
is compromised?

Larry
-- 
http://larry.masinter.net




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7I6Qi8o068627; Tue, 17 Aug 2004 23:26:44 -0700 (PDT) (envelope-from owner-ietf-ltans@mail.imc.org)
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7I6QicY068626; Tue, 17 Aug 2004 23:26:44 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f
Received: from psmtp.com (exprod6ob1.obsmtp.com [12.158.35.211]) by above.proper.com (8.12.11/8.12.9) with SMTP id i7I6Qhk8068619 for <ietf-ltans@imc.org>; Tue, 17 Aug 2004 23:26:43 -0700 (PDT) (envelope-from LMM@acm.org)
Received: from source ([192.150.22.8]) by exprod6ob1.obsmtp.com ([12.158.35.250]) with SMTP; Tue, 17 Aug 2004 23:26:43 PDT
Received: from inner-relay-3.corp.adobe.com (inner-relay-3 [153.32.251.51]) by smtp-relay-8.adobe.com (8.12.10/8.12.10) with ESMTP id i7I6QRJI019759 for <ietf-ltans@imc.org>; Tue, 17 Aug 2004 23:26:32 -0700 (PDT)
Received: from calsj-dev (calsj-dev.corp.adobe.com [153.32.1.193]) by inner-relay-3.corp.adobe.com (8.12.9/8.12.9) with ESMTP id i7I6QRkq009677 for <ietf-ltans@imc.org>; Tue, 17 Aug 2004 23:26:27 -0700 (PDT)
Received: from MasinterT40 ([130.248.176.4]) by mailsj-v1.corp.adobe.com (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep  8 2003)) with ESMTP id <0I2M000T0PVYV1@mailsj-v1.corp.adobe.com> for ietf-ltans@imc.org; Tue, 17 Aug 2004 23:26:27 -0700 (PDT)
Date: Tue, 17 Aug 2004 23:25:55 -0700
From: Larry Masinter <LMM@acm.org>
Subject: MD5, SHA-0
To: "'IETF LTANS'" <ietf-ltans@imc.org>
Message-id: <0I2M000T7PVZV1@mailsj-v1.corp.adobe.com>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1441
X-Mailer: Microsoft Office Outlook, Build 11.0.6353
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7BIT
Thread-index: AcSE7Decf9bkaedGQXu6y0t6EalCLg==
Sender: owner-ietf-ltans@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-ltans/mail-archive/>
List-Unsubscribe: <mailto:ietf-ltans-request@imc.org?body=unsubscribe>
List-ID: <ietf-ltans.imc.org>

It's sometimes hard to discern technical details in news
articles. Anyone have a more reliable source on what
happened at Crypto 2004?

http://news.com.com/Crypto+researchers+abuzz+over+flaws/2100-1002_3-5313655.
html

I still haven't understood, for notary services, if
the notary service doesn't have the original document
but just the hash, what happens when the hash algorithm
is compromised?

Larry
-- 
http://larry.masinter.net



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7DHSwXq041615; Fri, 13 Aug 2004 10:28:58 -0700 (PDT) (envelope-from owner-ietf-ltans@mail.imc.org)
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i7DHSwOV041614; Fri, 13 Aug 2004 10:28:58 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f
Received: from mucmx01.ixos.de (mucmx01.ixos.de [149.235.31.89]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7DHSu2c041604 for <ietf-ltans@imc.org>; Fri, 13 Aug 2004 10:28:56 -0700 (PDT) (envelope-from tobias@ixos.de)
Received: from muc-imc.ixos.de (localhost [127.0.0.1]) by mucmx01.ixos.de (8.12.9/8.12.9) with ESMTP id i7DHStE3003752; Fri, 13 Aug 2004 19:28:55 +0200 (MEST)
Received: by muc_mx.ixos.de with Internet Mail Service (5.5.2657.72) id <P64L4GWN>; Fri, 13 Aug 2004 19:29:20 +0200
Message-ID: <3C1BE8610E44734499EF92FB35F5B07017D5E6@MUCXGC1.opentext.net>
From: Tobias Gondrom <tobias@ixos.de>
To: "'IETF LTANS'" <ietf-ltans@imc.org>
Cc: Carl Wallace <cwallace@orionsec.com>
Subject: FW: LTANS: minutes and presentations from meeting in San Diego
Date: Fri, 13 Aug 2004 19:28:16 +0200
Importance: high
X-Priority: 1
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C4815A.EBCF4E23"
Sender: owner-ietf-ltans@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-ltans/mail-archive/>
List-Unsubscribe: <mailto:ietf-ltans-request@imc.org?body=unsubscribe>
List-ID: <ietf-ltans.imc.org>

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_000_01C4815A.EBCF4E23
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C4815A.EBCF4E23"


------_=_NextPart_001_01C4815A.EBCF4E23
Content-Type: text/plain

Hello,

 

Unfortunately I tried to send the presentation with the mail the first time
and it got stuck in a filter for emails that are too big. (it was only about
200kB) 

So I send now only the minutes and asked Peter to publish the Presentations
as soon as possible on our web page:

http://ltans.edelweb.fr <http://ltans.edelweb.fr/> 

 

best regards

 

            Tobias

            Chair of LTANS

 

 

  _____  

From: Tobias Gondrom 
Sent: Thursday, August 12, 2004 12:43 PM
To: 'IETF LTANS'
Subject: LTANS: minutes and presentations from meeting in San Diego

 

Hello,

 

Attached are the minutes and presentations from our WG meeting in San Diego.

 

Best regards

 

            Tobias

            Chair of LTANS

 


------_=_NextPart_001_01C4815A.EBCF4E23
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" =
xmlns:o=3D"urn:schemas-microsoft-com:office:office" =
xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:st1=3D"urn:schemas-microsoft-com:office:smarttags" =
xmlns=3D"http://www.w3.org/TR/REC-html40">

<head>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">


<meta name=3DGenerator content=3D"Microsoft Word 11 (filtered medium)">
<!--[if !mso]>
<style>
v\:* {behavior:url(#default#VML);}
o\:* {behavior:url(#default#VML);}
w\:* {behavior:url(#default#VML);}
.shape {behavior:url(#default#VML);}
</style>
<![endif]--><o:SmartTagType
 namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags" =
name=3D"City"/>
<o:SmartTagType =
namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"
 name=3D"place"/>
<!--[if !mso]>
<style>
st1\:*{behavior:url(#default#ieooui) }
</style>
<![endif]-->
<style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman";}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{color:purple;
	text-decoration:underline;}
p
	{mso-margin-top-alt:auto;
	margin-right:0in;
	mso-margin-bottom-alt:auto;
	margin-left:0in;
	font-size:12.0pt;
	font-family:"Times New Roman";}
span.EmailStyle18
	{mso-style-type:personal;
	font-family:Arial;
	color:windowtext;}
span.EmailStyle19
	{mso-style-type:personal-reply;
	font-family:Arial;
	color:navy;}
@page Section1
	{size:8.5in 11.0in;
	margin:1.0in 1.25in 1.0in 1.25in;}
div.Section1
	{page:Section1;}
-->
</style>
<!--[if gte mso 9]><xml>
 <o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
 <o:shapelayout v:ext=3D"edit">
  <o:idmap v:ext=3D"edit" data=3D"1" />
 </o:shapelayout></xml><![endif]-->
</head>

<body lang=3DEN-US link=3Dblue vlink=3Dpurple>

<div class=3DSection1>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>Hello,<o:p></o:p></span></font></p>=


<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>=


<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>Unfortunately I tried to send the
presentation with the mail the first time and it got stuck in a filter =
for
emails that are too big. (it was only about 200kB) =
<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>So I send now only the minutes and =
asked
Peter to publish the Presentations as soon as possible on our web =
page:<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'><a =
href=3D"http://ltans.edelweb.fr/">http://ltans.edelweb.fr</a><o:p></o:p>=
</span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>=


<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>best =
regards<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>=


<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Tobias<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Chair of LTANS<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>=


<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>=


<div>

<div class=3DMsoNormal align=3Dcenter style=3D'text-align:center'><font =
size=3D3
face=3D"Times New Roman"><span style=3D'font-size:12.0pt'>

<hr size=3D2 width=3D"100%" align=3Dcenter tabindex=3D-1>

</span></font></div>

<p class=3DMsoNormal><b><font size=3D2 face=3DTahoma><span =
style=3D'font-size:10.0pt;
font-family:Tahoma;font-weight:bold'>From:</span></font></b><font =
size=3D2
face=3DTahoma><span style=3D'font-size:10.0pt;font-family:Tahoma'> =
Tobias Gondrom <br>
<b><span style=3D'font-weight:bold'>Sent:</span></b> Thursday, August =
12, 2004
12:43 PM<br>
<b><span style=3D'font-weight:bold'>To:</span></b> 'IETF LTANS'<br>
<b><span style=3D'font-weight:bold'>Subject:</span></b> LTANS: minutes =
and
presentations from meeting in <st1:place w:st=3D"on"><st1:City =
w:st=3D"on">San
  Diego</st1:City></st1:place></span></font><o:p></o:p></p>

</div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>Hello,<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>Attached are the minutes and presentations from our =
WG
meeting in <st1:place w:st=3D"on"><st1:City w:st=3D"on">San =
Diego</st1:City></st1:place>.<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>Best regards<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;
Tobias<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;
Chair of LTANS<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'><o:p>&nbsp;</o:p></span></font></p>

</div>

</body>

</html>

------_=_NextPart_001_01C4815A.EBCF4E23--

------_=_NextPart_000_01C4815A.EBCF4E23
Content-Type: text/plain;
	name="ltans_meeting_minutes.txt"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment;
	filename="ltans_meeting_minutes.txt"

The LTANS WG met on 8/5 from 1:00PM to 3:00PM PDT.  Approximately 30 =
people attended the meeting. =20

Introduction/Administrivia/Status/etc. (Tobias Gondrom)	               =
-  5 Min.

A. Notary Requirements
1. Opening Presentation of Notary Reqs (Tobias) 	               - 15 =
Min.
2. Further presentations of notary reqs/ideas (Tobias) 	               =
- 10 Min.
	2.1 from Andreas Schmidt (Tobias)			       -  5 Min.
	2.2 OASIS (John Ross)					       - 10 Min.
3. Discussion of notary requirements doc (Larry Masinter)              =
- 30 Min.

B. Long-term Archive Protocol
1. Operation of an Archive Service (Tobias)		               - 10 Min.
2. Presentation of protocol draft from Peter Sylvester (Carl Wallace)  =
- 15 Min.
3. Discussion (Carl & Tobias) 					       - 20 Min.

Introduction/Status
- Tobias discussed document status.  Noted that Long-term Archive =
Requirements and ERS are stable.  Last Call for the Long-Term Archive =
Requirements document is planned for late August.  The Long-term =
Archive Protocol is not yet published.  Notary requirements are in =
early stages.  All documents are behind schedule.


A. Notary Requirements
1. Opening Presentation of Notary Reqs (Tobias)=20
- Tobias provided an overview of notary service functionality as =
described in initial requirements document and noted that a notary =
cannot function without trust (i.e. trust in the human behind the =
service).
- Notary functions were defined as follows: record transactions, record =
events, certification of copy documents, administering of oaths, =
attestation and certification of events.


2. Further presentations of notary reqs/ideas
2.1 from Andreas Schmidt (Tobias)
- Tobias presented slides on behalf of Andreas Schmidt, who is now a =
co-author of the notary requirements document. =20
- Identified the need to address varying legal constructions in various =
countries.  This important enough that it must be addressed in the =
requirements.
- Noted that paper notarization is outside of scope.  Larry pointed out =
that there are several IETF protocols that address paper, including =
internet fax. =20
- Notes that E2E (Electronic-to-electronic) transformations are a core =
functionality of notary services.
- Notion of a "transformation seal" was introduced. =20
- Is catalog of data formats and their suitability for transformation =
out of scope?
- Human inspection may not be avoidable.


2.2 OASIS (John Ross)
- Introduced activities in OASIS relevant to LTANS: Digital Signature =
Services (DSS) and legalXML.  legalXML defines the data structures for =
court filings, for example.  In particular, the human interaction is =
addressed.  DSS defines a generic framework for server-based signature =
generation and verification. =20
- Noted that it is difficult to come up with one solution for =
notarization due to differences in various jurisdictions.  Security =
aspects as separated from the data aspects to define a flexible =
solution that can be adapted from community to community to meet the =
various notarization requirements. =20
- Perhaps a means of working together could be established.  The group =
meets every two weeks with participants phoning in from a variety of =
locations.  Group has some face-to-face meetings and significant degree =
of participation. =20
- There are two documents recently released for comment: DSS Core =
Protocols, Elements and Bindings; XML Timestamping DSS Profile.
- These documents support CMS, XML DSIG and RFC 3161.
- Additionally, there is a requirements document and an FAQ available =
on the group's website.
- Other profiles are nearly ready for publication, including XADES, =
German signature law, Electronic Post Mark (EPM), code signing, =
asynchronous operation, entity seal, policy wise operation and web =
services security.
- OASIS participation requires membership (~$200 for individual =
membership).
- The group is interested in making sure that work done by LTANS is =
complementary and consistent with OASIS work, e.g. make sure there is =
one standard that is adopted. =20
- XADES is the profile related to long-term archive.  It is an XML equiv=
alent of RFC3126.
- Russ was asked if working with OASIS would be a problem.  Resolution =
is to raise issue to IAB and establish a liason.


3. Discussion about proceeding with notary work (Larry Masinter)
- Larry led a discussion of the notary requirements draft. =20
- Initial comments noted issues with the first paragraph, i.e. =
Wikipedia reference for notary definition.  The text needs work to =
establish a global scope for notarization.  Clarification that the =
initial text is not aiming to provide definitions but is simply trying =
to provide some context for the scope is necessary.
- Folks were requested to provide info regarding notary function in =
their parts of the world to the mailing list.
- It was discussed how far OASIS has already available standard for =
notary services: Currently nothing specific, the information related to =
notarization is carried data payload in OASIS, DSS is simply the =
sealing mechanism.
OASIS wants to provide input to the mailinglist (their "legalXML group" =
has possibly a requirements document)
- Discussed must/may/should text in requirements documents.  Next =
version will feature softer uses of such terms.
- Tobias solicited use cases from participants.  What services would be =
required to satisfy notary functions globally.
- In Norway, government acts as a notary.  It's not really a trusted =
third party.  It's trusted by the population, i.e. Norwegians trust =
their government.  The transactions are primarily between individual =
and the government.  Transactions between individuals are notarized by =
private notaries.
- It was noted that it is difficult to imagine that governments =
anywhere require a third party.  Larry pointed out that agencies rely =
on other agencies, which is a similar, e.g. the postal service provides =
a postmark that other agencies rely upon.
- The transaction set specified in the requirments document was =
reviewed.  An open question is what are the kinds of transactions and =
services that must be offered by a notary?  Some in the current list =
may not be suitable, e.g. administration of oaths.  It was suggested =
that the administration of oaths may accumulate more differences than =
some other use cases.
- Section 4 provides the meat of the document.  Editorially the sub-sub =
sections will probably go away since everything is a functional =
requirement. =20
- A review of must/may/should is in order.  The initial draft included =
such terms primarily to elicit opinion.
- Authentication may simply be required in order to exercise a notary.
In some cases the notary needs authentication only to aquire his =
payment, thus not _all_ services may need authentication.
- "Provide services" needs to be made more explicit.  Current text is =
too vague.  How to demonstrate trust?  Perhaps by demonstrating that =
you are someone with a long history of trust.  Does long history of =
trust demonstrate trust?  Demonstration of trust may be outside of =
scope.  Bonding is an example.  The term "trust" is maybe to vague.  =
Replace with notions like proof of identity.
- It's kind of like PGP web of trust.
- The "Operation" requirement is not a protocol requirement but is a =
service requirement.  For example, the notary must know how to perform =
his duties.  How to demonstrate that the notary system is under the =
control of the notary?  Perhaps some certified programs or evaluation =
to support such.  The requirement seems to indicate that someone is =
certified as a notary.  Is this necessary in internet environment?
- In France, notaries are certified for specific purposes after going =
through some legal exercise related to that purpose.  Perhaps a notary =
protocol could provide an indication as to whether there was a human =
notary involved, what the notary is authorized for, who authorized the =
notary, etc.
- The term "notary office" is not defined.

- What is the language for expressing notary capabilities?  There =
should be profiles for notary functions (maybe like OASIS DSS =
profiles).
- For some notarization requirements, there is not a confidentiality =
requirement.  In some cases there may actually be a publicity =
requirement, i.e. notaries that only handle public documents.
- The "Operational Considerations" and "Security Considerations" are =
incomplete.  The Operational Considerations sections needs to address =
topics like access control to the notary itself, denial of service =
attacks that prevent proper service.  The Security Considerations =
sections needs to include a threat analysis and mitigations of those =
threats.  These sections are essentially placeholders.
- Tobias noted that it is not clear to him that there is a need for =
notary services.  The reason for producing the requirements document =
was to elicit input regarding whether such things are needed.  One =
opinion was noted that the group should proceed with notary service =
work owing to the legal challenges and associated technical challenges. =
=20
- John Ross noted that in OASIS some general characteristics had been =
assembled from various requirements from different countries.  Most of =
there research was collected from the legalXML group (i.e. =
non-technical legal folks) to identify the requirements for the =
protocol.  The OASIS group has concentrated on the what is required for =
the seal.
- The entity seal profile from OASIS is the applicable profile (when =
available).
- Show of hands yielded no one supporting notary service protocols, =
some folks who felt the group should not proceed with such work.  =
Probably more "not sures" in the crowd.
- Would real notaries want to replace current practices with IETF =
equivalent?
- Service is only valuable if it is legally honored.
- Is there a way to address such things in a way similar to CA =
policies?

B Long-term Archive Protocol
1. Operation of an Archive Service (Tobias)
- Should there be search functionality? Should there be management of =
attributes?  How much should we stray into content management?
- Discussed the various transactions: submission, retrieval, deletion, =
transfer. =20
- Discussed the functionality that should be provided by an archive =
service. =20

2. Presentation of protocol draft from Peter Sylvester (Carl Wallace)
3. Discussion (Carl & Tobias)
- The possibility of dropping the protocol in favor of bindings to =
existing mechanisms, e.g. WebDAV, was raised.  In particular, this =
would avoid reinventing the wheel for things like searching.
- MIME headers are important component to solution.  For example, =
define a mulitpart archive type.
- May want to access the parts separately. =20
- There were questions as to whether content type info should be =
included in the protocol.  There were opinions for an against.  Future =
clients may not support MIME or the types indicated by the type.  =
Providing a hint is probably preferrable to not providing type.  The =
time of origin and time of archiving may be important clues for =
determing appropriate handler for data at points well into the future.
- Tobias noted that proof of integrity/non-repudiation is the service =
provided by the archive service, e.g. over a blob.  The payload could =
be XML signature, CMS signature or unsigned. =20
- The group will consider dropping the protocol specification as it is =
currently considered and instead focusing on defining bindings between =
evidence data and data, e.g. for WebDAV.

 =09

Action items
- Investigate establishing liason with OASIS group
- Collect details of notary operation from various countries from list =
participants
- Solicit comments on the notary requirements
- Discuss need for archive protocol vs. alternative means.  =
Investigate, in particular, use of WebDAV.
------_=_NextPart_000_01C4815A.EBCF4E23--



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i75ML5Ak040677; Thu, 5 Aug 2004 15:21:05 -0700 (PDT) (envelope-from owner-ietf-ltans@mail.imc.org)
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i75ML5w9040676; Thu, 5 Aug 2004 15:21:05 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f
Received: from host13.websitesource.com (host13.websitesource.com [209.239.35.152]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i75ML42E040670 for <ietf-ltans@imc.org>; Thu, 5 Aug 2004 15:21:04 -0700 (PDT) (envelope-from cwallace@orionsec.com)
Received: from wcwallace (opene-130-129-128-137.ietf60.ietf.org [130.129.128.137]) by host13.websitesource.com (8.12.10/8.12.10) with ESMTP id i75ML87L000878; Thu, 5 Aug 2004 18:21:08 -0400
Message-Id: <200408052221.i75ML87L000878@host13.websitesource.com>
From: "Carl Wallace" <cwallace@orionsec.com>
To: "'Russ Housley \(E-mail\)'" <housley@vigilsec.com>, "'IETF LTANS'" <ietf-ltans@imc.org>
Subject: LTANS meeting summary
Date: Thu, 5 Aug 2004 18:21:07 -0400
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0003_01C47B18.FB19F370"
X-Mailer: Microsoft Office Outlook, Build 11.0.5510
Thread-Index: AcR7OoEDOd4HFJemTly2Lbu1UtEhSg==
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441
Sender: owner-ietf-ltans@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-ltans/mail-archive/>
List-Unsubscribe: <mailto:ietf-ltans-request@imc.org?body=unsubscribe>
List-ID: <ietf-ltans.imc.org>

This is a multi-part message in MIME format.

------=_NextPart_000_0003_01C47B18.FB19F370
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

The LTANS group met on 8/5 from 1:00 to 3:00.  The primary topics of
discussion were Notary Requirements and Long-term Archive Protocol.  

Following a review of document status, Tobias Gondrom provided an
introduction to the Notary Requirements document and presented slides from
Andreas Schmidt highlighting some issues.  John Ross provided information
regarding the work done in OASIS that is relevant to LTANS.  In particular,
the recently published Digital Signature Services specification and work of
the legalXML group were noted.  The legalXML group has a requirements
document that may be of use but is currently in the members-only area of the
OASIS web site.  Russ was asked how to proceed with establishing a working
relationship between the OASIS group and the LTANS group.  The issue will be
raised with the IAB to see if a liason should be established.  Larry led a
review of the notary requirements document.  The requirements will continue
to be discussed on the mailing list prior to circulating a new version of
the document.  The group was asked to provide information regarding notary
requirements in various countries.
	
Tobias presented a diagram describing the functionality of an archive
service.  Carl presented a set of slides provided by Peter Sylvester
regarding the archive protocol.  Framework may be quite similar to work
performed by OASIS (e.g. DSS).  Discussion regarding the protocol questioned
the need for the protocol at all.  Instead, definition of bindings in
various environments should be considered, e.g. WebDAV, JSR170.  

The primary actions before the next IETF meeting are: investigation of OASIS
work, review of notary requirements (e.g. from legalXML, mailing list),
consideration of dropping protocol in favor of bindings to specific
technologies.

Carl and Tobias




------=_NextPart_000_0003_01C47B18.FB19F370
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
6.5.7036.0">
<TITLE>LTANS meeting summary</TITLE>
</HEAD>
<BODY>
<!-- Converted from text/rtf format -->

<P><FONT SIZE=3D2 FACE=3D"Arial">The LTANS group met on 8/5 from 1:00 to =
3:00.&nbsp; The primary topics of discussion were Notary Requirements =
and Long-term Archive Protocol.&nbsp; </FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Following a review of document status, =
Tobias Gondrom provided an introduction to the Notary Requirements =
document and presented slides from Andreas Schmidt highlighting some =
issues.&nbsp; John Ross provided information regarding the work done in =
OASIS that is relevant to LTANS.&nbsp; In particular, the recently =
published Digital Signature Services specification and work of the =
legalXML group were noted.&nbsp; The legalXML group has a requirements =
document that may be of use but is currently in the members-only area of =
the OASIS web site.&nbsp; Russ was asked how to proceed with =
establishing a working relationship between the OASIS group and the =
LTANS group.&nbsp; The issue will be raised with the IAB to see if a =
liason should be established.&nbsp; Larry led a review of the notary =
requirements document.&nbsp; The requirements will continue to be =
discussed on the mailing list prior to circulating a new version of the =
document.&nbsp; The group was asked to provide information regarding =
notary requirements in various countries.</FONT></P>

<P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20

<BR><FONT SIZE=3D2 FACE=3D"Arial">Tobias presented a diagram describing =
the functionality of an archive service.&nbsp; Carl presented a set of =
slides provided by Peter Sylvester regarding the archive protocol.&nbsp; =
Framework may be quite similar to work performed by OASIS (e.g. =
DSS).&nbsp; Discussion regarding the protocol questioned the need for =
the protocol at all.&nbsp; Instead, definition of bindings in various =
environments should be considered, e.g. WebDAV, JSR170.&nbsp; =
</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">The primary actions before the next =
IETF meeting are: investigation of OASIS work, review of notary =
requirements (e.g. from legalXML, mailing list), consideration of =
dropping protocol in favor of bindings to specific =
technologies.</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Carl and Tobias</FONT>
</P>
<BR>
<BR>

</BODY>
</HTML>
------=_NextPart_000_0003_01C47B18.FB19F370--



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i74JvFDZ011591; Wed, 4 Aug 2004 12:57:15 -0700 (PDT) (envelope-from owner-ietf-ltans@mail.imc.org)
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i74JvF4l011590; Wed, 4 Aug 2004 12:57:15 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f
Received: from relay1.san2.attens.com (relay1.san2.attens.com [192.215.81.74]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i74JvFB8011584 for <ietf-ltans@imc.org>; Wed, 4 Aug 2004 12:57:15 -0700 (PDT) (envelope-from cwallace@orionsec.com)
Received: from wcwallace (0127ahost69.starwoodbroadband.com [12.105.246.69]) by relay1.san2.attens.com (8.11.6/8.9.3) with ESMTP id i74JujB19352; Wed, 4 Aug 2004 19:56:46 GMT
Message-Id: <200408041956.i74JujB19352@relay1.san2.attens.com>
From: "Carl Wallace" <cwallace@orionsec.com>
To: "'Denis Pinkas'" <Denis.Pinkas@bull.net>, "'IETF LTANS'" <ietf-ltans@imc.org>
Subject: RE: Comments on LTANS documents
Date: Wed, 4 Aug 2004 15:56:45 -0400
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook, Build 11.0.5510
Thread-Index: AcRuLohy/wxuPNXrRNSnLbvhoxCqGwMLPxGQ
In-Reply-To: <40FCCB23.9060709@bull.net>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441
Sender: owner-ietf-ltans@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-ltans/mail-archive/>
List-Unsubscribe: <mailto:ietf-ltans-request@imc.org?body=unsubscribe>
List-ID: <ietf-ltans.imc.org>

Denis,

Thanks for your review of the document set.  We will address your comments
on the archive requirements document in the next version.  A few comments
are in-line below.

Carl

<snip>
> As far as the WHO is concerned, there are:
> 
>     1) the person or the application who did the deposit,
> 
>     2) the persons or the applications allowed to retrieve the data
>        (not necessarily the same as 1))
> 
>     3) the persons or the applications wishing to make sure that
>        some data originates from a given Archiving Unit (Arch-Unit)
>        under the responsibility of a given Archiving Authority
>        (Arch-A) and has been stored by it at a given point of time.
> 
> The difference between the above "players" should be 
> introduced in the documents.

The current text addresses each of 1, 2 and 3 as submitter, retriever and
arbitrator.  There are at least two outstanding roles: folks who can search
and folks who can manage a particular entry in an archive (e.g. shorten the
retention period).
 
<snip>
 
> 
> 3. When a person or an application makes deposit, it is of primary 
> importance that it gets back a "proof of deposit" from an 
> Arch-Unit. In case 
> the deposited data would be lost, then the Arch-A would be 
> responsible from 
> the loss.
> 
> Note that AFNOR has done some work to standardize different 
> kinds of proof, 
> including a "proof of deposit" with a full description of the 
> data structure 
> of that proof using ASN.1. This work should be published soon 
> as an AFNOR 
> Experimental Standard.
> 
> The concept of a "proof of deposit" should be introduced in 
> the documents.

The concept is present in the document in 4.1.1: 

	"Following submission, the service must provide a value that can be
   used to retrieve the archived data and/or associated evidence."

	"The acknowledgement of a successful submission should permit the
   submitter to verify that the correct data was received by the service
   for preservation."

"Proof of deposit" is a more descriptive way to label the concept.

> 
> 4. The deposit is made for a given archiving time period. 
> This period cannot 
> be shortened, unless the person who made the deposit signs a document 
> allowing the Arch-A to do so. In case the person who did the deposit 
> complains later on, then the Arch-A would be able to 
> demonstrate that the 
> archiving period has been shortened.
> 
> This concept should be introduced in the documents.

I don't think the requirements doc (or possibly any of the docs) should
mandate that the submitter is the only entity who should be allowed to
perform this operation.  I agree that concepts related to management of
entries in an archive need to be better addressed.
 
> 
> 5. The documents states that " a long-term archive service 
> provides material 
> needed to demonstrate the existence and integrity of data 
> object". This 
> definition is far from sufficient, since, it is missing two 
> dimensions:
> 
>      1) the fact to demonstrate that the archive was made
>        *at a given time*,

True.

> 
>      2) the fact to demonstrate that the archived data originates
>         *from a given Arch-Unit and Arch-A*.

While there is no subdivision similar to "Arch-Unit" and "Arch-A" in the
doc, the notion of identifying the archive service provider in the evidence
is present in 4.1.1.
 
> A better definition is present in section 4.3.1.
> 
> 
> 6. A major component which is not sufficiently described is 
> the Archive 
> Policy (Arch-Pol). The components of an Arch-Pol should be 
> first identified, 
> before attempting to define any data structure or protocol. 
> Section 4.4.2 
> should grow from 3 lines to one or two pages and should be 
> introduced much 
> earlier in the document.

Agree that elements of policy remain largely unexplored in this group and
need attention.

> 
> 7. One of the several aspects to be developed about the 
> Arch-Pol would be 
> how to relate the Arch-Pol under which the document is 
> retrieved 30 years 
> later to the initial Arch-Pol under which the document has be 
> deposited. 
> These policies cannot be the same, since, for example Time-Stamping 
> Authorities used 30 years later could not be known initially. 
> There may be a 
> chain of Arch-Pol to consider.

For most (all?) pieces of evidence, the notion has been to include the data
in the evidence structure itself (e.g. certs/crls/trust anchors).  Is there
any reason not to treat policy in a similar way?  Policy may be another
"special" type of data similar to trust anchors that an archive must handle.
I don't think using a different (or simply rekeyed) TSA constitutes a change
in policy.  Policy chains may require manual consideration.
 
> 
> 8. One of the several aspects to be developed about the 
> Arch-Pol would be 
> the policy for the "automatic" maintenance of archived data.
> 
> One obvious possibility is to time-stamp the archived data at 
> the time of 
> the deposit. One or more time-stamps tokens (TST) may be 
> applied (more than 
> one time-stamp token is not addressed in the documents).
> 
> For the maintenance of these TSTs, there are then two options:
> 
>      a) apply a new TST before the end of the validity period of the
>         TSU certificate and then capture the CRL of the CA which has
>         produced the TSU certificate in order to demonstrate that the
>         TSU certificate was not revoked at the time the new TST was
>         applied (this point is not addressed in any of the current
>         two documents).
> 
>      b) rely on the Certificate Policy of the CA which has produced
>         the TSU certificate, which will impose a specific 
> protection for
>         the TSU private key (key generation mandatory within 
> a security
>         module and no key export possible, mandatory 
> zeroization of the
>         private key at the end of the private key usage period. Once
>         the TSU certificate has expired, then the private key from the
>         TSU cannot be compromised anymore, except using brute force
>         attacks. In practice, the Archiving Unit will need to capture
>         the revocation status of the TSU certificate (usually a CRL),
>         once the TSU certificate has expired, in order to demonstrate
>         that the TSU certificate was not revoked at the end of the
>         validity period of the TSU certificate (this point is not
>         addressed in any of the current two documents).
> 

I'm not sure this is material that belongs in the requirements document.
Certainly the triggers related to refresh operations (if used) need to be
addressed somewhere - probably in the spec defining the mechanism.   
 
> 9. When an archived data is retrieved, with the proof it was 
> archived at a 
> given time, then the proof that the last TST is still valid has to be 
> produced. In practice this means (for case a) above) that the 
> *current* CRL 
> of the last TSU has to be produced (this point is not 
> addressed in any of 
> the current two documents).

Correct.  Additionally, same thing holds true for trust anchor usage (i.e.
most recent timestamp is validated to a current TA as opposed to historical
TA).  As above, this will most likely be addressed in a specification
document rather than in the requirements document.

<snip>

> 14. Transfer from one archive service to another one may only 
> apply for the 
> same or compatible Archive Policies (Arch-Pol).

Why?  The value of data (or financial standing of the data sponsor) may
change over time such that it is OK to use less rigorous archive methods,
i.e. different and non-compatible policies.  This seems more like a policy
instantiation than something for the the requirements doc.

> 
> 15. Disclosing or not the archived data to the Arch-Unit is 
> an interesting 
> topic. Three cases should be identified:
> 
>      1) the archived data is public data,
> 
>      2) the archived data is private data, and only a hash of it
>         is communicated,

A hash may only be transferred to a TSA but an Arch-Unit/TAA/AS/SAS would
receive or already possess the data (either encrypted or plaintext).

<snip> 
> 16. The documents states "where groups of data objects are submitted, 
> non-repudiation proof [of what ?] must still be available for 
> each archived 
> data separately". This is not a MUST. This MAY be a feature.

Do you mean multi-object submission is a may or the ability to verify each
separately is a may?  I think the statement in the doc is correct.
 
<snip>



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i74JG76h007805; Wed, 4 Aug 2004 12:16:07 -0700 (PDT) (envelope-from owner-ietf-ltans@mail.imc.org)
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i74JG7f5007804; Wed, 4 Aug 2004 12:16:07 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f
Received: from relay1.san2.attens.com (relay1.san2.attens.com [192.215.81.74]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i74JG2g3007797 for <ietf-ltans@imc.org>; Wed, 4 Aug 2004 12:16:02 -0700 (PDT) (envelope-from cwallace@orionsec.com)
Received: from wcwallace (0127ahost69.starwoodbroadband.com [12.105.246.69]) by relay1.san2.attens.com (8.11.6/8.9.3) with ESMTP id i74JFuB22347; Wed, 4 Aug 2004 19:15:59 GMT
Message-Id: <200408041915.i74JFuB22347@relay1.san2.attens.com>
From: "Carl Wallace" <cwallace@orionsec.com>
To: "'Ernst G Giessmann'" <ErnstG.Giessmann@t-systems.com>, <ietf-ltans@imc.org>
Subject: RE: Comments on LTANS documents
Date: Wed, 4 Aug 2004 15:15:56 -0400
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook, Build 11.0.5510
Thread-Index: AcR0t8I/NNCkKBXHSae6MgqrHkjF/QFn4yuA
In-Reply-To: <4107C240.5090000@t-systems.com>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441
Sender: owner-ietf-ltans@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-ltans/mail-archive/>
List-Unsubscribe: <mailto:ietf-ltans-request@imc.org?body=unsubscribe>
List-ID: <ietf-ltans.imc.org>

<large snip>
> Agree. We must differentiate between searching and 
> retrieving. But it is important to identify unambigously the 
> point of retrieval, otherwise you may get two different 
> documents from two different sources both claiming that they 
> are the archived documents.

Why is it important to unambiguously identify the point of retrieval?  The
point of retrieval might change over time.  Do you mean unambiguously
identify the data object to retrieve?