From carl@redhoundsoftware.com Wed Jul 13 14:42:40 2011 Return-Path: X-Original-To: ltans@ietfa.amsl.com Delivered-To: ltans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0D4611E8102 for ; Wed, 13 Jul 2011 14:42:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.202 X-Spam-Level: X-Spam-Status: No, score=-2.202 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U3DxZiMPNXiE for ; Wed, 13 Jul 2011 14:42:36 -0700 (PDT) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id B0C2211E8191 for ; Wed, 13 Jul 2011 14:42:36 -0700 (PDT) Received: by qwc23 with SMTP id 23so4362178qwc.31 for ; Wed, 13 Jul 2011 14:42:36 -0700 (PDT) Received: by 10.229.241.2 with SMTP id lc2mr1358332qcb.126.1310593355089; Wed, 13 Jul 2011 14:42:35 -0700 (PDT) Received: from [192.168.1.5] (pool-108-28-152-64.washdc.fios.verizon.net [108.28.152.64]) by mx.google.com with ESMTPS id f7sm1595755qco.22.2011.07.13.14.42.33 (version=SSLv3 cipher=OTHER); Wed, 13 Jul 2011 14:42:34 -0700 (PDT) User-Agent: Microsoft-MacOutlook/14.12.0.110505 Date: Wed, 13 Jul 2011 17:42:30 -0400 From: Carl Wallace To: Message-ID: Thread-Topic: [saag] Harber and Stornetta Expiry In-Reply-To: Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3393423754_9572356" Subject: [ltans] FW: [saag] Harber and Stornetta Expiry X-BeenThere: ltans@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: LTANS Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jul 2011 21:42:40 -0000 > 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. --B_3393423754_9572356 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit This may be of interest to folks on this list. From: Phillip Hallam-Baker Date: Wed, 13 Jul 2011 16:44:10 -0400 To: Subject: [saag] Harber and Stornetta Expiry > Is anyone interested in getting together to discuss possibilities for IETF > activities in the wake of the expiry (in at least some jurisdictions) of the > above patent? > > Harber and Stornatta is the chained digest patent that provides a means of > proving that a document was digested after date X and before date Y. In brief > each has is chained into the next and the result periodically published in the > classified section of the NYT. This allows a proof that the digest was > performed in the interval between two successive hashes. > > The reason this is of immediate practical interest is the problem of > 'unhistory'. As a lot of the primary collection and storage mechanisms for > historical data become digital there is more and more scope for falsifying > them. > > With an ordinary time stamp authority the question 'can we trust Alice not to > modify the document' becomes 'can we trust the TSA not to collude with Alice'. > There is an improvement but it is still a thin chain of trust. I would like to > see the task of falsification be made much harder. > > When only one TSA had the technology there was no particular advantage to > using it over a regular notary service either. The NYT will probably stop > being printed in a few years time, libraries will certainly stop keeping paper > copies (many have already) so the claim of permanency is being undermined in > any case. Now there is an opportunity to do something more interesting. > > > The technology is one thing, but to make it useful we need a social > infrastructure to support it. The value of this approach above and beyond an > ordinary TSA comes from having hundreds of independent agencies all providing > services and auditing/hashing each other. > > So imagine a situation where there is a 'tier1' of providers which all > undertake to provide a daily digest value that is fed into the digests of each > of the others. It is now impossible for any individual provider to default > without that default being seen globally. > > > -- > Website: http://hallambaker.com/ > > _______________________________________________ saag mailing list > saag@ietf.org https://www.ietf.org/mailman/listinfo/saag --B_3393423754_9572356 Content-type: text/html; charset="US-ASCII" Content-transfer-encoding: quoted-printable
This may be of interest to f= olks on this list.

From: Phillip Hallam-Baker <hallam@gmail= .com>
Date: Wed, 13 Jul 201= 1 16:44:10 -0400
To: <saag@ietf.org>
Subject: [saag] Harber and Stornetta Expiry

Is anyone interested in get= ting together to discuss possibilities for IETF activities in the wake of th= e expiry (in at least some jurisdictions) of the above patent?

Harber and Stornatta is the chained digest patent that provides a mean= s of proving that a document was digested after date X and before date Y. In= brief each has is chained into the next and the result periodically publish= ed in the classified section of the NYT. This allows a proof that the digest= was performed in the interval between two successive hashes.

=
The reason this is of immediate practical interest is the problem= of 'unhistory'. As a lot of the primary collection and storage mechanisms f= or historical data become digital there is more and more scope for falsifyin= g them.

With an ordinary time stamp authority the q= uestion 'can we trust Alice not to modify the document' becomes 'can we trus= t the TSA not to collude with Alice'. There is an improvement but it is stil= l a thin chain of trust. I would like to see the task of falsification be ma= de much harder.

When only one TSA had the technolog= y there was no particular advantage to using it over a regular notary servic= e either. The NYT will probably stop being printed in a few years time, libr= aries will certainly stop keeping paper copies (many have already) so the cl= aim of permanency is being undermined in any case. Now there is an opportuni= ty to do something more interesting.


The technology is one thing, but to make it useful we need a social infrast= ructure to support it. The value of this approach above and beyond an ordina= ry TSA comes from having hundreds of independent agencies all providing serv= ices and auditing/hashing each other. 

So= imagine a situation where there is a 'tier1' of providers which all underta= ke to provide a daily digest value that is fed into the digests of each of t= he others. It is now impossible for any individual provider to default witho= ut that default being seen globally.


--
Web= site: http://hallambaker.com/

<= /div> _______________________________________________ saag mailing list saag@ietf.org https://www.ietf.org/m= ailman/listinfo/saag
--B_3393423754_9572356-- From hallam@gmail.com Thu Jul 14 12:35:28 2011 Return-Path: X-Original-To: ltans@ietfa.amsl.com Delivered-To: ltans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7999621F8C45 for ; Thu, 14 Jul 2011 12:35:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.899 X-Spam-Level: X-Spam-Status: No, score=-2.899 tagged_above=-999 required=5 tests=[AWL=-0.541, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_LWSHORTT=1.24] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w2Z-y4P+d-hP for ; Thu, 14 Jul 2011 12:35:24 -0700 (PDT) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 11ADD21F8C41 for ; Thu, 14 Jul 2011 12:35:24 -0700 (PDT) Received: by gxk19 with SMTP id 19so283367gxk.31 for ; Thu, 14 Jul 2011 12:35:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; bh=ZpqroB0dIUmfQH2qUXbJOGMygbKI2aOQ8SGoiOsy3QE=; b=LB/JKRBFp/ANVTJX6f6SqRRxTyartRWhsyjPxp47kjkzWW3vYfvMfU8GlbrkABu8c9 WaYby207pqgrMEGi28uNZS5bEfeda5VnoalE3vHWgzPKaRHlC3RjjEy6IViGFXlM+Kvr 68OfVZpuAY/yyPZ5BkAPlmWCSv+wDnezjikL0= MIME-Version: 1.0 Received: by 10.101.162.11 with SMTP id p11mr2557552ano.159.1310672123482; Thu, 14 Jul 2011 12:35:23 -0700 (PDT) Received: by 10.100.93.12 with HTTP; Thu, 14 Jul 2011 12:35:23 -0700 (PDT) Date: Thu, 14 Jul 2011 15:35:23 -0400 Message-ID: From: Phillip Hallam-Baker To: ltans@ietf.org Content-Type: multipart/alternative; boundary=001636ed6c7f5651cc04a80ca2c7 Subject: [ltans] Harber and Stornetta expiry X-BeenThere: ltans@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: LTANS Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jul 2011 19:35:28 -0000 --001636ed6c7f5651cc04a80ca2c7 Content-Type: text/plain; charset=ISO-8859-1 I understand that LTANS is winding down, are any people interested in discussing opportunities in the wake of the above expiry? As I see it the advantage to the linked digest option is that it can be used to prevent default by TSAs and to provide robustness in the case that a TSA should fail. That is of course inevitable when looking at keeping records for centuries. In particular I think there is an opportunity here for a scheme where documents were fixed with relation to two timelines. The document itself would be fixed relative to a short term timeline maintained by a chosen TSA. the TSA timeline would then be periodically (e.g. every hour) be fixed relative to a meta timeline kept across multiple TSAs. Forging the long term archive would require a massive multi-party default. If we can make the number of parties number in the millions default becomes inconceivable. -- Website: http://hallambaker.com/ --001636ed6c7f5651cc04a80ca2c7 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I understand that LTANS is winding down, are any people interested in discu= ssing opportunities in the wake of the above expiry?

As = I see it the advantage to the linked digest option is that it can be used t= o prevent default by TSAs and to provide robustness in the case that a TSA = should fail. That is of course inevitable when looking at keeping records f= or centuries.=A0


In particular I think there is an opport= unity here for a scheme where documents were fixed with relation to two tim= elines. The document itself would be fixed relative to a short term timelin= e maintained by a chosen TSA. the TSA timeline would then be periodically (= e.g. every hour) be fixed relative to a meta timeline kept across multiple = TSAs.=A0

Forging the long term archive would require a massive m= ulti-party default. If we can make the number of parties number in the mill= ions default becomes inconceivable.

--001636ed6c7f5651cc04a80ca2c7-- From tobias.gondrom@gondrom.org Sun Jul 17 13:28:32 2011 Return-Path: X-Original-To: ltans@ietfa.amsl.com Delivered-To: ltans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6062C21F8686 for ; Sun, 17 Jul 2011 13:28:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -94.741 X-Spam-Level: X-Spam-Status: No, score=-94.741 tagged_above=-999 required=5 tests=[AWL=-0.620, BAYES_00=-2.599, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_IPADDR=2.426, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RDNS_DYNAMIC=0.1, SARE_LWSHORTT=1.24, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pq2cVUxsXFFE for ; Sun, 17 Jul 2011 13:28:31 -0700 (PDT) Received: from lvps83-169-7-107.dedicated.hosteurope.de (lvps83-169-7-107.dedicated.hosteurope.de [83.169.7.107]) by ietfa.amsl.com (Postfix) with ESMTP id 5CF1B21F85B8 for ; Sun, 17 Jul 2011 13:28:31 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=gondrom.org; b=c8OwwG4yrYRUbhamDj0V8AlPHKuuhpJRQXi6MO1VI2isl0l4MM3ET5zRNNz3XdmBwkzlv8uYBbv/nJECXdzZUzkN8LPFA8A15g/WIN5AG9nUIJyQUJT4WbKJetKj7P0J; h=Received:Received:Message-ID:Date:From:User-Agent:MIME-Version:To:Subject:X-Priority:References:In-Reply-To:Content-Type; Received: (qmail 23585 invoked from network); 17 Jul 2011 22:28:21 +0200 Received: from 94-194-102-93.zone8.bethere.co.uk (HELO ?192.168.1.64?) (94.194.102.93) by lvps83-169-7-107.dedicated.hosteurope.de with (DHE-RSA-AES256-SHA encrypted) SMTP; 17 Jul 2011 22:28:21 +0200 Message-ID: <4E2345E5.8050606@gondrom.org> Date: Sun, 17 Jul 2011 21:28:21 +0100 From: Tobias Gondrom User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:5.0) Gecko/20110627 Thunderbird/5.0 MIME-Version: 1.0 To: ltans@ietf.org X-Priority: 4 (Low) References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------060101010906060605070605" Subject: Re: [ltans] Harber and Stornetta expiry X-BeenThere: ltans@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: LTANS Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Jul 2011 20:28:32 -0000 This is a multi-part message in MIME format. --------------060101010906060605070605 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit (Yes, ltans is close to completion. The last bit we wait for is formal publication of RFC 6283, which should happen Monday or Tuesday.) I read about the scheme you describe below. Although I can see certain value in the linked hash chain, personally I am not sure the additional value is significant enough compared to let's say using multiple redundant TS (which does not require any coordination between TSAs). From most of the current business scenarios I've seen the past months and years, I would probably not expect a big push for the approach (which of course is only my personal data set and does not exclude there could be some business need out there). Best regards, Tobias On 14/07/11 20:35, Phillip Hallam-Baker wrote: > I understand that LTANS is winding down, are any people interested in > discussing opportunities in the wake of the above expiry? > > As I see it the advantage to the linked digest option is that it can > be used to prevent default by TSAs and to provide robustness in the > case that a TSA should fail. That is of course inevitable when looking > at keeping records for centuries. > > > In particular I think there is an opportunity here for a scheme where > documents were fixed with relation to two timelines. The document > itself would be fixed relative to a short term timeline maintained by > a chosen TSA. the TSA timeline would then be periodically (e.g. every > hour) be fixed relative to a meta timeline kept across multiple TSAs. > > Forging the long term archive would require a massive multi-party > default. If we can make the number of parties number in the millions > default becomes inconceivable. > > > -- > Website: http://hallambaker.com/ > > > > _______________________________________________ > ltans mailing list > ltans@ietf.org > https://www.ietf.org/mailman/listinfo/ltans --------------060101010906060605070605 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit (Yes, ltans is close to completion. The last bit we wait for is formal publication of RFC 6283, which should happen Monday or Tuesday.)

I read about the scheme you describe below.
Although I can see certain value in the linked hash chain, personally I am not sure the additional value is significant enough compared to let's say using multiple redundant TS (which does not require any coordination between TSAs).

From most of the current business scenarios I've seen the past months and years, I would probably not expect a big push for the approach (which of course is only my personal data set and does not exclude there could be some business need out there).

Best regards, Tobias




On 14/07/11 20:35, Phillip Hallam-Baker wrote:
I understand that LTANS is winding down, are any people interested in discussing opportunities in the wake of the above expiry?

As I see it the advantage to the linked digest option is that it can be used to prevent default by TSAs and to provide robustness in the case that a TSA should fail. That is of course inevitable when looking at keeping records for centuries. 


In particular I think there is an opportunity here for a scheme where documents were fixed with relation to two timelines. The document itself would be fixed relative to a short term timeline maintained by a chosen TSA. the TSA timeline would then be periodically (e.g. every hour) be fixed relative to a meta timeline kept across multiple TSAs. 

Forging the long term archive would require a massive multi-party default. If we can make the number of parties number in the millions default becomes inconceivable.



_______________________________________________
ltans mailing list
ltans@ietf.org
https://www.ietf.org/mailman/listinfo/ltans

--------------060101010906060605070605-- From peter.sylvester@edelweb.fr Mon Jul 18 03:03:16 2011 Return-Path: X-Original-To: ltans@ietfa.amsl.com Delivered-To: ltans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA00221F8B8C for ; Mon, 18 Jul 2011 03:03:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[AWL=-0.620, BAYES_00=-2.599, HTML_MESSAGE=0.001, SARE_LWSHORTT=1.24] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yfAvIGpneeeS for ; Mon, 18 Jul 2011 03:03:13 -0700 (PDT) Received: from mx1.on-x.com (mx1.on-x.com [92.103.215.13]) by ietfa.amsl.com (Postfix) with ESMTP id C0C1621F8BA1 for ; Mon, 18 Jul 2011 03:03:11 -0700 (PDT) Received: from varuna.puteaux.on-x (varuna.puteaux.on-x [192.168.10.6]) by mx1.on-x.com (Postfix) with ESMTP id 3F6FD7FE1 for ; Mon, 18 Jul 2011 12:03:10 +0200 (CEST) Received: from smtps.on-x.com (mintaka.puteaux.on-x [192.168.14.11]) by varuna.puteaux.on-x (Postfix) with ESMTP id E11C71702E for ; Mon, 18 Jul 2011 12:03:07 +0200 (CEST) Received: from [192.168.18.186] (unknown [192.168.18.186]) by smtps.on-x.com (Postfix) with ESMTP id E8EA3782B for ; Mon, 18 Jul 2011 12:03:07 +0200 (CEST) Message-ID: <4E24055E.5040505@edelweb.fr> Date: Mon, 18 Jul 2011 12:05:18 +0200 From: Peter Sylvester User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.17) Gecko/20110516 Thunderbird/3.1.10 MIME-Version: 1.0 To: ltans@ietf.org References: <4E2345E5.8050606@gondrom.org> In-Reply-To: <4E2345E5.8050606@gondrom.org> Content-Type: multipart/alternative; boundary="------------080109070502070409020807" Subject: Re: [ltans] Harber and Stornetta expiry X-BeenThere: ltans@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: LTANS Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jul 2011 10:03:17 -0000 This is a multi-part message in MIME format. --------------080109070502070409020807 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit The purpose of hash linking schemes is to link time stamps together and to be able to verify them without the need of any cryptographic key which have the tendency to have their secrecy evaporate. On 07/17/2011 10:28 PM, Tobias Gondrom wrote: > (Yes, ltans is close to completion. The last bit we wait for is formal > publication of RFC 6283, which should happen Monday or Tuesday.) > > I read about the scheme you describe below. > Although I can see certain value in the linked hash chain, personally > I am not sure the additional value is significant enough compared to > let's say using multiple redundant TS (which does not require any > coordination between TSAs). > > From most of the current business scenarios I've seen the past months > and years, I would probably not expect a big push for the approach > (which of course is only my personal data set and does not exclude > there could be some business need out there). > > Best regards, Tobias > > > > > On 14/07/11 20:35, Phillip Hallam-Baker wrote: >> I understand that LTANS is winding down, are any people interested in >> discussing opportunities in the wake of the above expiry? >> >> As I see it the advantage to the linked digest option is that it can >> be used to prevent default by TSAs and to provide robustness in the >> case that a TSA should fail. That is of course inevitable when >> looking at keeping records for centuries. >> >> >> In particular I think there is an opportunity here for a scheme where >> documents were fixed with relation to two timelines. The document >> itself would be fixed relative to a short term timeline maintained by >> a chosen TSA. the TSA timeline would then be periodically (e.g. every >> hour) be fixed relative to a meta timeline kept across multiple TSAs. >> >> Forging the long term archive would require a massive multi-party >> default. If we can make the number of parties number in the millions >> default becomes inconceivable. >> >> >> -- >> Website: http://hallambaker.com/ >> >> >> >> _______________________________________________ >> ltans mailing list >> ltans@ietf.org >> https://www.ietf.org/mailman/listinfo/ltans > > > _______________________________________________ > ltans mailing list > ltans@ietf.org > https://www.ietf.org/mailman/listinfo/ltans --------------080109070502070409020807 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit The purpose of hash linking schemes is to link time stamps together and
to be able to verify them without the need of any cryptographic key
which have the tendency to have their secrecy evaporate.  


On 07/17/2011 10:28 PM, Tobias Gondrom wrote:
(Yes, ltans is close to completion. The last bit we wait for is formal publication of RFC 6283, which should happen Monday or Tuesday.)

I read about the scheme you describe below.
Although I can see certain value in the linked hash chain, personally I am not sure the additional value is significant enough compared to let's say using multiple redundant TS (which does not require any coordination between TSAs).

From most of the current business scenarios I've seen the past months and years, I would probably not expect a big push for the approach (which of course is only my personal data set and does not exclude there could be some business need out there).

Best regards, Tobias




On 14/07/11 20:35, Phillip Hallam-Baker wrote:
I understand that LTANS is winding down, are any people interested in discussing opportunities in the wake of the above expiry?

As I see it the advantage to the linked digest option is that it can be used to prevent default by TSAs and to provide robustness in the case that a TSA should fail. That is of course inevitable when looking at keeping records for centuries. 


In particular I think there is an opportunity here for a scheme where documents were fixed with relation to two timelines. The document itself would be fixed relative to a short term timeline maintained by a chosen TSA. the TSA timeline would then be periodically (e.g. every hour) be fixed relative to a meta timeline kept across multiple TSAs. 

Forging the long term archive would require a massive multi-party default. If we can make the number of parties number in the millions default becomes inconceivable.



_______________________________________________
ltans mailing list
ltans@ietf.org
https://www.ietf.org/mailman/listinfo/ltans



_______________________________________________
ltans mailing list
ltans@ietf.org
https://www.ietf.org/mailman/listinfo/ltans

--------------080109070502070409020807-- From hallam@gmail.com Mon Jul 18 05:07:58 2011 Return-Path: X-Original-To: ltans@ietfa.amsl.com Delivered-To: ltans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5BFEC21F8BB7 for ; Mon, 18 Jul 2011 05:07:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.497 X-Spam-Level: X-Spam-Status: No, score=-3.497 tagged_above=-999 required=5 tests=[AWL=0.101, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fussDEcJJq3e for ; Mon, 18 Jul 2011 05:07:54 -0700 (PDT) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id D8DEA21F8BBB for ; Mon, 18 Jul 2011 05:07:53 -0700 (PDT) Received: by gyd5 with SMTP id 5so1428067gyd.31 for ; Mon, 18 Jul 2011 05:07:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=PdZtbiY13uzC2l2uZYtofdycFdiG0Rpgc+3Wdt+tlYY=; b=nJ3Wea1AOmzkulafF44FgsbSRpOFvNcESFqeoEmcuGnYCkJMiQSBgKDI9ZkhtTgdxC 5WJy9UQAeeFmwFNEn4ZNWF83TonyFENssTsSgNH5vvVQaKIEUkyfwifB0h49DXgCsjei 2TVlmhMJ0ZGQtJVs9i4qz3e9ohtScbwW43opA= MIME-Version: 1.0 Received: by 10.101.175.36 with SMTP id c36mr5367710anp.93.1310990873374; Mon, 18 Jul 2011 05:07:53 -0700 (PDT) Received: by 10.100.134.9 with HTTP; Mon, 18 Jul 2011 05:07:53 -0700 (PDT) In-Reply-To: <4E24055E.5040505@edelweb.fr> References: <4E2345E5.8050606@gondrom.org> <4E24055E.5040505@edelweb.fr> Date: Mon, 18 Jul 2011 08:07:53 -0400 Message-ID: From: Phillip Hallam-Baker To: Peter Sylvester Content-Type: multipart/alternative; boundary=001636c5be694fae3404a856d9c7 Cc: ltans@ietf.org Subject: Re: [ltans] Harber and Stornetta expiry X-BeenThere: ltans@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: LTANS Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jul 2011 12:07:58 -0000 --001636c5be694fae3404a856d9c7 Content-Type: text/plain; charset=ISO-8859-1 On Mon, Jul 18, 2011 at 6:05 AM, Peter Sylvester wrote: > ** > The purpose of hash linking schemes is to link time stamps together and > to be able to verify them without the need of any cryptographic key > which have the tendency to have their secrecy evaporate. > Its not the secrecy that worries me, its the ability to state with confidence that the TSA will be around after the commercial incentive is gone. Its pretty easy to build a business case to support a registry of digital signatures on mortgage notes to last 30-50 odd years. There is a lot of money at stake and there will always be someone collecting on the note. The problem is that we only have this type of business models for a small number of signatures and they are pretty boring applications. That still leaves open the question of how we make digital libraries as authentic and trustworthy as paper ones used to be. Print is dead. In 100 years time nobody will be printing books other than for religious or sentimental reasons. People can argue about whether that should happen but it is very clear that it will happen. A couple of years ago GM went bankrupt. A couple of weeks ago the worlds largest circulation tabloid went out of business despite robust profits. How can we say with confidence that a TSA is going to be around in 100 years time? > > -- Website: http://hallambaker.com/ --001636c5be694fae3404a856d9c7 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Mon, Jul 18, 2011 at 6:05 AM, Peter S= ylvester <peter.sylvester@edelweb.fr> wrote:
=20 =20 =20
The purpose of hash linking schemes is to link time stamps together and
to be able to verify them without the need of any cryptographic key
which have the tendency to have their secrecy evaporate. =A0=A0

Its not the secrecy that worries me, its the= ability to state with confidence that the TSA will be around after the com= mercial incentive is gone.

Its pretty easy to build a business case to support a r= egistry of digital signatures on mortgage notes to last 30-50 odd years. Th= ere is a lot of money at stake and there will always be someone collecting = on the note.

The problem is that we only have this type of business = models for a small number of signatures and they are pretty boring applicat= ions. That still leaves open the question of how we make digital libraries = as authentic and trustworthy as paper ones used to be.

Print is dead. In 100 years time nobody will be printin= g books other than for religious or sentimental reasons. People can argue a= bout whether that should happen but it is very clear that it will happen.

A couple of years ago GM went bankrupt. A couple of wee= ks ago the worlds largest circulation tabloid went out of business despite = robust profits. How can we say with confidence that a TSA is going to be ar= ound in 100 years time?

=A0
=A0
--
Website: <= a href=3D"http://hallambaker.com/">http://hallambaker.com/

--001636c5be694fae3404a856d9c7-- From tobias.gondrom@gondrom.org Mon Jul 18 08:39:12 2011 Return-Path: X-Original-To: ltans@ietfa.amsl.com Delivered-To: ltans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 21D3E21F8BB4 for ; Mon, 18 Jul 2011 08:39:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -95.206 X-Spam-Level: X-Spam-Status: No, score=-95.206 tagged_above=-999 required=5 tests=[AWL=0.155, BAYES_00=-2.599, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_IPADDR=2.426, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RDNS_DYNAMIC=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JgdODsFeQZxN for ; Mon, 18 Jul 2011 08:39:08 -0700 (PDT) Received: from lvps83-169-7-107.dedicated.hosteurope.de (lvps83-169-7-107.dedicated.hosteurope.de [83.169.7.107]) by ietfa.amsl.com (Postfix) with ESMTP id C6B3121F8B17 for ; Mon, 18 Jul 2011 08:39:07 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=gondrom.org; b=R66WbljI8Eb4MRQdiyuJn5IbAB5oEniAqZN6NE4DnXJqBYwA65r5AnILY40RJUWSZklVo3O2MXTvxcHVvcolSnWhORuBWm7Y6pzTkAnaZArcu8UAFl6qAO9lhJw6K04P; h=Received:Received:Message-ID:Date:From:User-Agent:MIME-Version:To:Subject:X-Priority:References:In-Reply-To:Content-Type; Received: (qmail 12197 invoked from network); 18 Jul 2011 17:38:58 +0200 Received: from 94-194-102-93.zone8.bethere.co.uk (HELO ?192.168.1.64?) (94.194.102.93) by lvps83-169-7-107.dedicated.hosteurope.de with (DHE-RSA-AES256-SHA encrypted) SMTP; 18 Jul 2011 17:38:58 +0200 Message-ID: <4E245391.8060705@gondrom.org> Date: Mon, 18 Jul 2011 16:38:57 +0100 From: Tobias Gondrom User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:5.0) Gecko/20110627 Thunderbird/5.0 MIME-Version: 1.0 To: ltans@ietf.org X-Priority: 4 (Low) References: <4E2345E5.8050606@gondrom.org> <4E24055E.5040505@edelweb.fr> In-Reply-To: Content-Type: multipart/alternative; boundary="------------060009040101010502030501" Subject: Re: [ltans] Harber and Stornetta expiry X-BeenThere: ltans@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: LTANS Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jul 2011 15:39:12 -0000 This is a multi-part message in MIME format. --------------060009040101010502030501 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Well, not to be boring: the mentioned scenario is exactly one of the reasons why we did ERS (rfc4998) and XMLERS (rfc6283) - to be able to renew before or in case of a trust anchor goes bust. Best regards, Tobias On 18/07/11 13:07, Phillip Hallam-Baker wrote: > > > On Mon, Jul 18, 2011 at 6:05 AM, Peter Sylvester > > wrote: > > The purpose of hash linking schemes is to link time stamps > together and > to be able to verify them without the need of any cryptographic key > which have the tendency to have their secrecy evaporate. > > > Its not the secrecy that worries me, its the ability to state with > confidence that the TSA will be around after the commercial incentive > is gone. > > Its pretty easy to build a business case to support a registry of > digital signatures on mortgage notes to last 30-50 odd years. There is > a lot of money at stake and there will always be someone collecting on > the note. > > The problem is that we only have this type of business models for a > small number of signatures and they are pretty boring applications. > That still leaves open the question of how we make digital libraries > as authentic and trustworthy as paper ones used to be. > > Print is dead. In 100 years time nobody will be printing books other > than for religious or sentimental reasons. People can argue about > whether that should happen but it is very clear that it will happen. > > A couple of years ago GM went bankrupt. A couple of weeks ago the > worlds largest circulation tabloid went out of business despite robust > profits. How can we say with confidence that a TSA is going to be > around in 100 years time? > > -- > Website: http://hallambaker.com/ > > > > _______________________________________________ > ltans mailing list > ltans@ietf.org > https://www.ietf.org/mailman/listinfo/ltans --------------060009040101010502030501 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Well,
not to be boring: the mentioned scenario is exactly one of the reasons why we did ERS (rfc4998) and XMLERS (rfc6283) - to be able to renew before or in case of a trust anchor goes bust.

Best regards, Tobias




On 18/07/11 13:07, Phillip Hallam-Baker wrote:


On Mon, Jul 18, 2011 at 6:05 AM, Peter Sylvester <peter.sylvester@edelweb.fr> wrote:
The purpose of hash linking schemes is to link time stamps together and
to be able to verify them without the need of any cryptographic key
which have the tendency to have their secrecy evaporate.   

Its not the secrecy that worries me, its the ability to state with confidence that the TSA will be around after the commercial incentive is gone.

Its pretty easy to build a business case to support a registry of digital signatures on mortgage notes to last 30-50 odd years. There is a lot of money at stake and there will always be someone collecting on the note.

The problem is that we only have this type of business models for a small number of signatures and they are pretty boring applications. That still leaves open the question of how we make digital libraries as authentic and trustworthy as paper ones used to be.

Print is dead. In 100 years time nobody will be printing books other than for religious or sentimental reasons. People can argue about whether that should happen but it is very clear that it will happen.

A couple of years ago GM went bankrupt. A couple of weeks ago the worlds largest circulation tabloid went out of business despite robust profits. How can we say with confidence that a TSA is going to be around in 100 years time?

 
 
--
Website: http://hallambaker.com/



_______________________________________________
ltans mailing list
ltans@ietf.org
https://www.ietf.org/mailman/listinfo/ltans

--------------060009040101010502030501-- From peter.sylvester@edelweb.fr Mon Jul 18 08:43:12 2011 Return-Path: X-Original-To: ltans@ietfa.amsl.com Delivered-To: ltans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 554FC21F8C57 for ; Mon, 18 Jul 2011 08:43:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.443 X-Spam-Level: X-Spam-Status: No, score=-2.443 tagged_above=-999 required=5 tests=[AWL=0.155, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fbHQtfFFxO-1 for ; Mon, 18 Jul 2011 08:43:11 -0700 (PDT) Received: from mx1.on-x.com (mx1.on-x.com [92.103.215.13]) by ietfa.amsl.com (Postfix) with ESMTP id 252F321F8BB7 for ; Mon, 18 Jul 2011 08:43:02 -0700 (PDT) Received: from varuna.puteaux.on-x (varuna.puteaux.on-x [192.168.10.6]) by mx1.on-x.com (Postfix) with ESMTP id 176957F77; Mon, 18 Jul 2011 17:43:01 +0200 (CEST) Received: from smtps.on-x.com (mintaka.puteaux.on-x [192.168.14.11]) by varuna.puteaux.on-x (Postfix) with ESMTP id D2C4E1702C; Mon, 18 Jul 2011 17:43:00 +0200 (CEST) Received: from [192.168.18.186] (unknown [192.168.18.186]) by smtps.on-x.com (Postfix) with ESMTP id B9B5C782B; Mon, 18 Jul 2011 17:43:00 +0200 (CEST) Message-ID: <4E245508.1020902@edelweb.fr> Date: Mon, 18 Jul 2011 17:45:12 +0200 From: Peter Sylvester User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.17) Gecko/20110516 Thunderbird/3.1.10 MIME-Version: 1.0 To: Phillip Hallam-Baker References: <4E2345E5.8050606@gondrom.org> <4E24055E.5040505@edelweb.fr> In-Reply-To: Content-Type: multipart/alternative; boundary="------------070301060904050606070801" Cc: ltans@ietf.org Subject: Re: [ltans] Harber and Stornetta expiry X-BeenThere: ltans@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: LTANS Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jul 2011 15:43:12 -0000 This is a multi-part message in MIME format. --------------070301060904050606070801 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi On 07/18/2011 02:07 PM, Phillip Hallam-Baker wrote: > > > On Mon, Jul 18, 2011 at 6:05 AM, Peter Sylvester > > wrote: > > The purpose of hash linking schemes is to link time stamps > together and > to be able to verify them without the need of any cryptographic key > which have the tendency to have their secrecy evaporate. > > > Its not the secrecy that worries me, its the ability to state with > confidence that the TSA will be around after the commercial incentive > is gone. Do you mean by 'staying around': - being able to issue time stamps - being able to ensure that no one can create a correct timestamp (in the past) because no one ensure that the TSA key was destroyed. - having some means to ask someone whether a given time stamp was really created 10 years ago (by some TSA). - ... - ... ? > > Its pretty easy to build a business case to support a registry of > digital signatures on mortgage notes to last 30-50 odd years. There is > a lot of money at stake and there will always be someone collecting on > the note. these signature are less important than some actual money transfer that is done? > > The problem is that we only have this type of business models for a > small number of signatures and they are pretty boring applications. > That still leaves open the question of how we make digital libraries > as authentic and trustworthy as paper ones used to be. Paper is less authentic as one belives, but I agree, the physical characteristics of paper allow to have some trust in the integrity, and additional measures like seals, the paper types itselfs stamps, etc contribute. Sometime that way of writing ... one third of decrees of prpriety for the church issued by CharleMagne are false. > > Print is dead. In 100 years time nobody will be printing books other > than for religious or sentimental reasons. People can argue about > whether that should happen but it is very clear that it will happen. I avoid predicting things, especially those in the future. :-) > > A couple of years ago GM went bankrupt. A couple of weeks ago the > worlds largest circulation tabloid went out of business despite robust > profits. How can we say with confidence that a TSA is going to be > around in 100 years time? What confidence do you need for a TSA? If I read RFC 3161, .... regards --------------070301060904050606070801 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Hi

On 07/18/2011 02:07 PM, Phillip Hallam-Baker wrote:


On Mon, Jul 18, 2011 at 6:05 AM, Peter Sylvester <peter.sylvester@edelweb.fr> wrote:
The purpose of hash linking schemes is to link time stamps together and
to be able to verify them without the need of any cryptographic key
which have the tendency to have their secrecy evaporate.   

Its not the secrecy that worries me, its the ability to state with confidence that the TSA will be around after the commercial incentive is gone.
Do you mean by 'staying around':
  - being able to issue time stamps
  - being able to ensure that no one can create a correct timestamp (in the past)
    because no one ensure that the TSA key was destroyed.
 -  having some means to ask someone whether a given time stamp was
    really created 10 years ago (by some TSA).
 - ...
 - ... ?


Its pretty easy to build a business case to support a registry of digital signatures on mortgage notes to last 30-50 odd years. There is a lot of money at stake and there will always be someone collecting on the note.
these signature are less important than some actual money transfer that is done?


The problem is that we only have this type of business models for a small number of signatures and they are pretty boring applications. That still leaves open the question of how we make digital libraries as authentic and trustworthy as paper ones used to be.
Paper is less authentic as one belives, but I agree, the physical characteristics of paper allow
to have some trust in the integrity, and additional measures like seals, the paper types itselfs
stamps, etc contribute. Sometime that way of writing ... one third of decrees of prpriety for
the church issued by CharleMagne are false.


Print is dead. In 100 years time nobody will be printing books other than for religious or sentimental reasons. People can argue about whether that should happen but it is very clear that it will happen.
I avoid predicting things, especially those in the future. :-)

A couple of years ago GM went bankrupt. A couple of weeks ago the worlds largest circulation tabloid went out of business despite robust profits. How can we say with confidence that a TSA is going to be around in 100 years time?
What confidence do you need for a TSA?

If I read RFC 3161, ....

regards


--------------070301060904050606070801-- From tglassey@earthlink.net Mon Jul 18 08:51:21 2011 Return-Path: X-Original-To: ltans@ietfa.amsl.com Delivered-To: ltans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 987ED21F8B8C for ; Mon, 18 Jul 2011 08:51:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.458 X-Spam-Level: X-Spam-Status: No, score=-3.458 tagged_above=-999 required=5 tests=[AWL=-2.100, BAYES_00=-2.599, HTML_MESSAGE=0.001, SARE_LWSHORTT=1.24] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8IMP+AsdkCmJ for ; Mon, 18 Jul 2011 08:51:17 -0700 (PDT) Received: from elasmtp-galgo.atl.sa.earthlink.net (elasmtp-galgo.atl.sa.earthlink.net [209.86.89.61]) by ietfa.amsl.com (Postfix) with ESMTP id 5BE5721F8B88 for ; Mon, 18 Jul 2011 08:51:17 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=A92rivnb0Bju5rOKbGek0+E6SABCwlrnG9tLFmC3PYdANv5XA8ubvD0Gj6LC9TiR; h=Received:Message-ID:Date:From:User-Agent:MIME-Version:To:Subject:References:In-Reply-To:Content-Type:X-ELNK-Trace:X-Originating-IP; Received: from [207.111.209.5] (helo=[192.168.1.100]) by elasmtp-galgo.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1Qiq6G-0000RE-Rb for ltans@ietf.org; Mon, 18 Jul 2011 11:51:16 -0400 Message-ID: <4E245693.20001@earthlink.net> Date: Mon, 18 Jul 2011 08:51:47 -0700 From: todd glassey User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.18) Gecko/20110616 Lightning/1.0b2 Thunderbird/3.1.11 MIME-Version: 1.0 To: ltans@ietf.org References: <4E2345E5.8050606@gondrom.org> In-Reply-To: <4E2345E5.8050606@gondrom.org> Content-Type: multipart/alternative; boundary="------------050905030203080306020607" X-ELNK-Trace: 01b7a7e171bdf5911aa676d7e74259b7b3291a7d08dfec79e140a1d279c84802c9cef3ae0b30e9b4350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 207.111.209.5 Subject: Re: [ltans] Harber and Stornetta expiry X-BeenThere: ltans@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: LTANS Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jul 2011 15:51:21 -0000 This is a multi-part message in MIME format. --------------050905030203080306020607 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 7/17/2011 1:28 PM, Tobias Gondrom wrote: > (Yes, ltans is close to completion. The last bit we wait for is formal > publication of RFC 6283, which should happen Monday or Tuesday.) > > I read about the scheme you describe below. > Although I can see certain value in the linked hash chain, personally > I am not sure the additional value is significant enough compared to > let's say using multiple redundant TS (which does not require any > coordination between TSAs). > > From most of the current business scenarios I've seen the past months > and years, I would probably not expect a big push for the approach > (which of course is only my personal data set and does not exclude > there could be some business need out there). > > Best regards, Tobias I want to start a new NTP Time Stamping WG which uses the existing NTP protocol as a transport for timestamps and content validation services. As to why this is necessary - the issue is in the Trust Factors and Uniform Time Service models which all involve the hosting OS as the intermediary between the various protocols and their services. This is a failure of many of the IETF's efforts, but hey it is what it is... That said - NTP as both a time distribution vector, time verification vector and content controller is a natural fit. Any interests? Todd Glassey > > > > > On 14/07/11 20:35, Phillip Hallam-Baker wrote: >> I understand that LTANS is winding down, are any people interested in >> discussing opportunities in the wake of the above expiry? >> >> As I see it the advantage to the linked digest option is that it can >> be used to prevent default by TSAs and to provide robustness in the >> case that a TSA should fail. That is of course inevitable when >> looking at keeping records for centuries. >> >> >> In particular I think there is an opportunity here for a scheme where >> documents were fixed with relation to two timelines. The document >> itself would be fixed relative to a short term timeline maintained by >> a chosen TSA. the TSA timeline would then be periodically (e.g. every >> hour) be fixed relative to a meta timeline kept across multiple TSAs. >> >> Forging the long term archive would require a massive multi-party >> default. If we can make the number of parties number in the millions >> default becomes inconceivable. >> >> >> -- >> Website: http://hallambaker.com/ >> >> >> >> _______________________________________________ >> ltans mailing list >> ltans@ietf.org >> https://www.ietf.org/mailman/listinfo/ltans > > > _______________________________________________ > ltans mailing list > ltans@ietf.org > https://www.ietf.org/mailman/listinfo/ltans -- Todd S. Glassey This is from my personal email account and any materials from this account come with personal disclaimers. Further I OPT OUT of any and all commercial emailings. --------------050905030203080306020607 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 7/17/2011 1:28 PM, Tobias Gondrom wrote:
(Yes, ltans is close to completion. The last bit we wait for is formal publication of RFC 6283, which should happen Monday or Tuesday.)

I read about the scheme you describe below.
Although I can see certain value in the linked hash chain, personally I am not sure the additional value is significant enough compared to let's say using multiple redundant TS (which does not require any coordination between TSAs).

From most of the current business scenarios I've seen the past months and years, I would probably not expect a big push for the approach (which of course is only my personal data set and does not exclude there could be some business need out there).

Best regards, Tobias

I want to start a new NTP Time Stamping WG which uses the existing NTP protocol as a transport for timestamps and content validation services. As to why this is necessary - the issue is in the Trust Factors and Uniform Time Service models which all involve the hosting OS as the intermediary between the various protocols and their services. This is a failure of many of the IETF's efforts, but hey it is what it is...

That said - NTP as both a time distribution vector, time verification vector and content controller is a natural fit.

Any interests?

Todd Glassey




On 14/07/11 20:35, Phillip Hallam-Baker wrote:
I understand that LTANS is winding down, are any people interested in discussing opportunities in the wake of the above expiry?

As I see it the advantage to the linked digest option is that it can be used to prevent default by TSAs and to provide robustness in the case that a TSA should fail. That is of course inevitable when looking at keeping records for centuries. 


In particular I think there is an opportunity here for a scheme where documents were fixed with relation to two timelines. The document itself would be fixed relative to a short term timeline maintained by a chosen TSA. the TSA timeline would then be periodically (e.g. every hour) be fixed relative to a meta timeline kept across multiple TSAs. 

Forging the long term archive would require a massive multi-party default. If we can make the number of parties number in the millions default becomes inconceivable.



_______________________________________________
ltans mailing list
ltans@ietf.org
https://www.ietf.org/mailman/listinfo/ltans



_______________________________________________
ltans mailing list
ltans@ietf.org
https://www.ietf.org/mailman/listinfo/ltans



-- 
Todd S. Glassey
This is from my personal email account and any materials from this account come with personal disclaimers. 

Further I OPT OUT of any and all commercial emailings.
--------------050905030203080306020607-- From peter.sylvester@edelweb.fr Mon Jul 18 08:55:42 2011 Return-Path: X-Original-To: ltans@ietfa.amsl.com Delivered-To: ltans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E2A721F8CBB for ; Mon, 18 Jul 2011 08:55:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.474 X-Spam-Level: X-Spam-Status: No, score=-2.474 tagged_above=-999 required=5 tests=[AWL=0.124, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L4CzRBBiuIvT for ; Mon, 18 Jul 2011 08:55:42 -0700 (PDT) Received: from mx1.on-x.com (mx1.on-x.com [92.103.215.13]) by ietfa.amsl.com (Postfix) with ESMTP id 55E0221F8CB1 for ; Mon, 18 Jul 2011 08:55:41 -0700 (PDT) Received: from varuna.puteaux.on-x (varuna.puteaux.on-x [192.168.10.6]) by mx1.on-x.com (Postfix) with ESMTP id BB8187EF5 for ; Mon, 18 Jul 2011 17:55:40 +0200 (CEST) Received: from smtps.on-x.com (mintaka.puteaux.on-x [192.168.14.11]) by varuna.puteaux.on-x (Postfix) with ESMTP id 6B7F51702C for ; Mon, 18 Jul 2011 17:55:40 +0200 (CEST) Received: from [192.168.18.186] (unknown [192.168.18.186]) by smtps.on-x.com (Postfix) with ESMTP id 81D3B782B for ; Mon, 18 Jul 2011 17:55:40 +0200 (CEST) Message-ID: <4E245800.604@edelweb.fr> Date: Mon, 18 Jul 2011 17:57:52 +0200 From: Peter Sylvester User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.17) Gecko/20110516 Thunderbird/3.1.10 MIME-Version: 1.0 To: ltans@ietf.org References: <4E2345E5.8050606@gondrom.org> <4E24055E.5040505@edelweb.fr> <4E245391.8060705@gondrom.org> In-Reply-To: <4E245391.8060705@gondrom.org> Content-Type: multipart/alternative; boundary="------------030308070007070603070102" Subject: Re: [ltans] Harber and Stornetta expiry X-BeenThere: ltans@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: LTANS Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jul 2011 15:55:42 -0000 This is a multi-part message in MIME format. --------------030308070007070603070102 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 07/18/2011 05:38 PM, Tobias Gondrom wrote: > Well, > not to be boring: the mentioned scenario is exactly one of the reasons > why we did ERS (rfc4998) and XMLERS (rfc6283) - to be able to renew > before or in case of a trust anchor goes bust. > > Best regards, Tobias Indeed. --------------030308070007070603070102 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 07/18/2011 05:38 PM, Tobias Gondrom wrote:
Well,
not to be boring: the mentioned scenario is exactly one of the reasons why we did ERS (rfc4998) and XMLERS (rfc6283) - to be able to renew before or in case of a trust anchor goes bust.

Best regards, Tobias

Indeed.

--------------030308070007070603070102-- From hallam@gmail.com Mon Jul 18 09:30:46 2011 Return-Path: X-Original-To: ltans@ietfa.amsl.com Delivered-To: ltans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 18D0521F8BD1 for ; Mon, 18 Jul 2011 09:30:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.504 X-Spam-Level: X-Spam-Status: No, score=-4.504 tagged_above=-999 required=5 tests=[AWL=1.094, BAYES_00=-2.599, GB_I_LETTER=-2, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bkeEyZRSDo8K for ; Mon, 18 Jul 2011 09:30:41 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id 80AE421F8B52 for ; Mon, 18 Jul 2011 09:30:41 -0700 (PDT) Received: by ywp31 with SMTP id 31so1588252ywp.31 for ; Mon, 18 Jul 2011 09:30:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=U4R5GX78lXY4RRK6ZwDaXU/VcDIXUbPKusl6npHbRHg=; b=bHFbVYtkVB4WeSFQ6OoPRNiJyESVq87mX+vJNM3vUZN8dSVO1iAdzc0puGqc8XVPFK 9ncYAJ3Yux+1a9d9p0GFjr+ll1BI9t3/RsMCUM/kXfL/yZFrZsSlKqM1wkpbC253uaHP 0nE0e7HamSSbFfxqd9Krzz98aU0/is6B4FTY8= MIME-Version: 1.0 Received: by 10.101.43.3 with SMTP id v3mr5552512anj.137.1311006640088; Mon, 18 Jul 2011 09:30:40 -0700 (PDT) Received: by 10.100.134.9 with HTTP; Mon, 18 Jul 2011 09:30:40 -0700 (PDT) In-Reply-To: <4E245508.1020902@edelweb.fr> References: <4E2345E5.8050606@gondrom.org> <4E24055E.5040505@edelweb.fr> <4E245508.1020902@edelweb.fr> Date: Mon, 18 Jul 2011 12:30:40 -0400 Message-ID: From: Phillip Hallam-Baker To: Peter Sylvester Content-Type: multipart/alternative; boundary=001636ed722614a81904a85a85a9 Cc: ltans@ietf.org Subject: Re: [ltans] Harber and Stornetta expiry X-BeenThere: ltans@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: LTANS Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jul 2011 16:30:46 -0000 --001636ed722614a81904a85a85a9 Content-Type: text/plain; charset=ISO-8859-1 On Mon, Jul 18, 2011 at 11:45 AM, Peter Sylvester < peter.sylvester@edelweb.fr> wrote: > ** > Hi > > > On 07/18/2011 02:07 PM, Phillip Hallam-Baker wrote: > > > > On Mon, Jul 18, 2011 at 6:05 AM, Peter Sylvester < > peter.sylvester@edelweb.fr> wrote: > >> The purpose of hash linking schemes is to link time stamps together and >> to be able to verify them without the need of any cryptographic key >> which have the tendency to have their secrecy evaporate. >> > > Its not the secrecy that worries me, its the ability to state with > confidence that the TSA will be around after the commercial incentive is > gone. > > Do you mean by 'staying around': > - being able to issue time stamps > - being able to ensure that no one can create a correct timestamp (in the > past) > because no one ensure that the TSA key was destroyed. > - having some means to ask someone whether a given time stamp was > really created 10 years ago (by some TSA). > - ... > I mean we can't depend on them being around in 100 or 1000 years time. We do depend on paper being around that long. Its pretty easy to build a business case to support a registry of digital > signatures on mortgage notes to last 30-50 odd years. There is a lot of > money at stake and there will always be someone collecting on the note. > > these signature are less important than some actual money transfer that is > done? > Yes, the question of who owes money to whom is pretty piffling in the long run of events. nobody will care in 100 years time. The question of who wrote the protocols of the elders of Zion, the Zinoviev letter, etc, those are rather more important. He who controls the past controls the present and he who controls the present controls the future. Falsification of historical records is a social issue and requires social infrastructure. Photoshop forgeries are becoming better and better. But the real danger is that we have now reached the point where genuine evidence is dismissed as photoshoped. Print is dead. In 100 years time nobody will be printing books other than > for religious or sentimental reasons. People can argue about whether that > should happen but it is very clear that it will happen. > > I avoid predicting things, especially those in the future. :-) > Do you want the future of history to depend on the survival of print? A couple of years ago GM went bankrupt. A couple of weeks ago the worlds > largest circulation tabloid went out of business despite robust profits. How > can we say with confidence that a TSA is going to be around in 100 years > time? > > What confidence do you need for a TSA? > > If I read RFC 3161, .... > If money is involved, it is an easy problem. -- Website: http://hallambaker.com/ --001636ed722614a81904a85a85a9 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Mon, Jul 18, 2011 at 11:45 AM, Peter = Sylvester <peter.sylvester@edelweb.fr> wrote:
=20 =20 =20
Hi


On 07/18/2011 02:07 PM, Phillip Hallam-Baker wrote:


On Mon, Jul 18, 2011 at 6:05 AM, Peter Sylvester <peter.sylvester@edelweb.fr> wrote:
The purpose of hash linking schemes is to link time stamps together and
to be able to verify them without the need of any cryptographic key
which have the tendency to have their secrecy evaporate. =A0=A0=

Its not the secrecy that worries me, its the ability to state with confidence that the TSA will be around after the commercial incentive is gone.
Do you mean by 'staying around':
=A0 - being able to issue time stamps
=A0 - being able to ensure that no one can create a correct timestamp (in the past)
=A0=A0=A0 because no one ensure that the TSA key was destroyed.
=A0-=A0 having some means to ask someone whether a given time stamp was=
=A0=A0=A0 really created 10 years ago (by some TSA).
=A0- ...=A0 =A0 =A0

I mean we can= 't depend on them being around in 100 or 1000 years time. We do depend = on paper being around that long.

=20
Its pretty easy to build a business case to support a registry of digital signatures on mortgage notes to last 30-50 odd years. There is a lot of money at stake and there will always be someone collecting on the note.
these signature are less important than some actual money transfer that is done?=A0

Yes, the questio= n of who owes money to whom is pretty piffling in the long run of events. n= obody will care in 100 years time.

The question of= who wrote the protocols of the elders of Zion, the Zinoviev letter, etc, t= hose are rather more important.

He who controls the past controls the present and he wh= o controls the present controls the future. Falsification of historical rec= ords is a social issue and requires social infrastructure.

Photoshop forgeries are becoming better and better. But the real= danger is that we have now reached the point where genuine evidence is dis= missed as photoshoped.
=A0

=20
Print is dead. In 100 years time nobody will be printing books other than for religious or sentimental reasons. People can argue about whether that should happen but it is very clear that it will happen.
I avoid predicting things, especially those in the future. :-)

Do you want the future of history to depend o= n the survival of print?

=20
A couple of years ago GM went bankrupt. A couple of weeks ago the worlds largest circulation tabloid went out of business despite robust profits. How can we say with confidence that a TSA is going to be around in 100 years time?
What confidence do you need for a TSA?

If I read RFC 3161, ....

If m= oney is involved, it is an easy problem. =A0

--
Website:= http://hallambaker.com/

--001636ed722614a81904a85a85a9-- From tglassey@earthlink.net Mon Jul 18 10:31:43 2011 Return-Path: X-Original-To: ltans@ietfa.amsl.com Delivered-To: ltans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2864121F8AA8 for ; Mon, 18 Jul 2011 10:31:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.815 X-Spam-Level: X-Spam-Status: No, score=-3.815 tagged_above=-999 required=5 tests=[AWL=-1.217, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vzq13Ozf1ljG for ; Mon, 18 Jul 2011 10:31:39 -0700 (PDT) Received: from elasmtp-mealy.atl.sa.earthlink.net (elasmtp-mealy.atl.sa.earthlink.net [209.86.89.69]) by ietfa.amsl.com (Postfix) with ESMTP id 1E2CC21F84A5 for ; Mon, 18 Jul 2011 10:31:39 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=iF4FzyGoKbTq3nLU05S0UunaxwKWe1J2fE0WEfiOR3uNqhgR1TCObnLMdGMQQnb5; h=Received:Message-ID:Date:From:User-Agent:MIME-Version:To:Subject:References:In-Reply-To:Content-Type:X-ELNK-Trace:X-Originating-IP; Received: from [207.111.209.5] (helo=[192.168.1.100]) by elasmtp-mealy.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1QirfO-0000wa-IG for ltans@ietf.org; Mon, 18 Jul 2011 13:31:38 -0400 Message-ID: <4E246E19.7000703@earthlink.net> Date: Mon, 18 Jul 2011 10:32:09 -0700 From: todd glassey User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.18) Gecko/20110616 Lightning/1.0b2 Thunderbird/3.1.11 MIME-Version: 1.0 To: ltans@ietf.org References: <4E2345E5.8050606@gondrom.org> <4E24055E.5040505@edelweb.fr> In-Reply-To: Content-Type: multipart/alternative; boundary="------------090501000707070001020600" X-ELNK-Trace: 01b7a7e171bdf5911aa676d7e74259b7b3291a7d08dfec79dfb321815be83f8f9dea217c4f2441f0350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 207.111.209.5 Subject: Re: [ltans] Harber and Stornetta expiry X-BeenThere: ltans@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: LTANS Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jul 2011 17:31:43 -0000 This is a multi-part message in MIME format. --------------090501000707070001020600 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 7/18/2011 5:07 AM, Phillip Hallam-Baker wrote: > > > On Mon, Jul 18, 2011 at 6:05 AM, Peter Sylvester > > wrote: > > The purpose of hash linking schemes is to link time stamps > together and > to be able to verify them without the need of any cryptographic key > which have the tendency to have their secrecy evaporate. > > > Its not the secrecy that worries me, its the ability to state with > confidence that the TSA will be around after the commercial incentive > is gone. > > Its pretty easy to build a business case to support a registry of > digital signatures on mortgage notes to last 30-50 odd years. There is > a lot of money at stake and there will always be someone collecting on > the note. > > The problem is that we only have this type of business models for a > small number of signatures and they are pretty boring applications. > That still leaves open the question of how we make digital libraries > as authentic and trustworthy as paper ones used to be. > > Print is dead. In 100 years time nobody will be printing books other > than for religious or sentimental reasons. People can argue about > whether that should happen but it is very clear that it will happen. > > A couple of years ago GM went bankrupt. A couple of weeks ago the > worlds largest circulation tabloid went out of business despite robust > profits. How can we say with confidence that a TSA is going to be > around in 100 years time? By making it a government service so it is not tied to the marketspace... Why do you think Certichron does what it does - by the way - we just opened the 10th NIST Server we operate! Todd > > -- > Website: http://hallambaker.com/ > > > _______________________________________________ > ltans mailing list > ltans@ietf.org > https://www.ietf.org/mailman/listinfo/ltans -- Todd S. Glassey This is from my personal email account and any materials from this account come with personal disclaimers. Further I OPT OUT of any and all commercial emailings. --------------090501000707070001020600 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 7/18/2011 5:07 AM, Phillip Hallam-Baker wrote:


On Mon, Jul 18, 2011 at 6:05 AM, Peter Sylvester <peter.sylvester@edelweb.fr> wrote:
The purpose of hash linking schemes is to link time stamps together and
to be able to verify them without the need of any cryptographic key
which have the tendency to have their secrecy evaporate.   

Its not the secrecy that worries me, its the ability to state with confidence that the TSA will be around after the commercial incentive is gone.

Its pretty easy to build a business case to support a registry of digital signatures on mortgage notes to last 30-50 odd years. There is a lot of money at stake and there will always be someone collecting on the note.

The problem is that we only have this type of business models for a small number of signatures and they are pretty boring applications. That still leaves open the question of how we make digital libraries as authentic and trustworthy as paper ones used to be.

Print is dead. In 100 years time nobody will be printing books other than for religious or sentimental reasons. People can argue about whether that should happen but it is very clear that it will happen.

A couple of years ago GM went bankrupt. A couple of weeks ago the worlds largest circulation tabloid went out of business despite robust profits. How can we say with confidence that a TSA is going to be around in 100 years time?

By making it a government service so it is not tied to the marketspace...

Why do you think Certichron does what it does - by the way - we just opened the 10th NIST Server we operate!

Todd


 
 
--
Website: http://hallambaker.com/


_______________________________________________
ltans mailing list
ltans@ietf.org
https://www.ietf.org/mailman/listinfo/ltans



-- 
Todd S. Glassey
This is from my personal email account and any materials from this account come with personal disclaimers. 

Further I OPT OUT of any and all commercial emailings.
--------------090501000707070001020600-- From hallam@gmail.com Mon Jul 18 10:37:09 2011 Return-Path: X-Original-To: ltans@ietfa.amsl.com Delivered-To: ltans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 82A1F21F8B52 for ; Mon, 18 Jul 2011 10:37:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.502 X-Spam-Level: X-Spam-Status: No, score=-3.502 tagged_above=-999 required=5 tests=[AWL=0.096, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n3zlU9pLe33e for ; Mon, 18 Jul 2011 10:37:05 -0700 (PDT) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id 64C6621F8511 for ; Mon, 18 Jul 2011 10:37:05 -0700 (PDT) Received: by gyd5 with SMTP id 5so1623208gyd.31 for ; Mon, 18 Jul 2011 10:37:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=A5dOQ/DK2kyMfXdfYZZuUrEcUg2PMVRXhDqq7o++mBw=; b=YpEPlflqZSoNLqoafnc12oW9UtL5sLpVypi8y9F8p2fgYiAMnvJjBv0iHhcQoOUAkL K6cKgn8/u/zP9fbMVwV8dv+l22VD7ERyhLf4yM5LVzK7kuUgaREa8OulejrGjr7+akCp xr8Ug5YM4tAjTI4+CSCoeP2D22swQjggt3SBw= MIME-Version: 1.0 Received: by 10.100.74.38 with SMTP id w38mr5696699ana.5.1311010624783; Mon, 18 Jul 2011 10:37:04 -0700 (PDT) Received: by 10.100.134.9 with HTTP; Mon, 18 Jul 2011 10:37:04 -0700 (PDT) In-Reply-To: <4E246E19.7000703@earthlink.net> References: <4E2345E5.8050606@gondrom.org> <4E24055E.5040505@edelweb.fr> <4E246E19.7000703@earthlink.net> Date: Mon, 18 Jul 2011 13:37:04 -0400 Message-ID: From: Phillip Hallam-Baker To: todd glassey Content-Type: multipart/alternative; boundary=001636b2b3029646e804a85b728c Cc: ltans@ietf.org Subject: Re: [ltans] Harber and Stornetta expiry X-BeenThere: ltans@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: LTANS Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jul 2011 17:37:09 -0000 --001636b2b3029646e804a85b728c Content-Type: text/plain; charset=ISO-8859-1 How do we know governments will last that long? Very few institutions have existed more than a few hundred years without major changes in function and structure. Oxford was founded as a religious community and only made training for the priesthood the primary purpose in the middle ages. The idea of being a general purpose educator comes from the Victorian era. What I like about the Harber & Stornetta approach is that it allows multiple archives to be bound together in ways that makes their integrity interdependent. On Mon, Jul 18, 2011 at 1:32 PM, todd glassey wrote: > ** > On 7/18/2011 5:07 AM, Phillip Hallam-Baker wrote: > > > > On Mon, Jul 18, 2011 at 6:05 AM, Peter Sylvester < > peter.sylvester@edelweb.fr> wrote: > >> The purpose of hash linking schemes is to link time stamps together and >> to be able to verify them without the need of any cryptographic key >> which have the tendency to have their secrecy evaporate. >> > > Its not the secrecy that worries me, its the ability to state with > confidence that the TSA will be around after the commercial incentive is > gone. > > Its pretty easy to build a business case to support a registry of digital > signatures on mortgage notes to last 30-50 odd years. There is a lot of > money at stake and there will always be someone collecting on the note. > > The problem is that we only have this type of business models for a small > number of signatures and they are pretty boring applications. That still > leaves open the question of how we make digital libraries as authentic and > trustworthy as paper ones used to be. > > Print is dead. In 100 years time nobody will be printing books other than > for religious or sentimental reasons. People can argue about whether that > should happen but it is very clear that it will happen. > > A couple of years ago GM went bankrupt. A couple of weeks ago the worlds > largest circulation tabloid went out of business despite robust profits. How > can we say with confidence that a TSA is going to be around in 100 years > time? > > > By making it a government service so it is not tied to the marketspace... > > Why do you think Certichron does what it does - by the way - we just opened > the 10th NIST Server we operate! > > Todd > > > > > >> >> > -- > Website: http://hallambaker.com/ > > > _______________________________________________ > ltans mailing listltans@ietf.orghttps://www.ietf.org/mailman/listinfo/ltans > > > > -- > Todd S. Glassey > This is from my personal email account and any materials from this account come with personal disclaimers. > > Further I OPT OUT of any and all commercial emailings. > > > _______________________________________________ > ltans mailing list > ltans@ietf.org > https://www.ietf.org/mailman/listinfo/ltans > > -- Website: http://hallambaker.com/ --001636b2b3029646e804a85b728c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable How do we know governments will last that long?

Very few= institutions have existed more than a few hundred years without major chan= ges in function and structure. Oxford was founded as a religious community = and only made training for the priesthood the primary purpose in the middle= ages. The idea of being a general purpose educator comes from the Victoria= n era.


What I like about the Harber & Storn= etta approach is that it allows multiple archives to be bound together in w= ays that makes their integrity interdependent.



On Mon, Jul 18, 2011 at 1:32 PM, to= dd glassey <= tglassey@earthlink.net> wrote:
=20 =20 =20
On 7/18/2011 5:07 AM, Phillip Hallam-Baker wrote:


On Mon, Jul 18, 2011 at 6:05 AM, Peter Sylvester <peter.sylvester@edelweb.fr> wrote:
The purpose of hash linking schemes is to link time stamps together and
to be able to verify them without the need of any cryptographic key
which have the tendency to have their secrecy evaporate. =A0=A0=

Its not the secrecy that worries me, its the ability to state with confidence that the TSA will be around after the commercial incentive is gone.

Its pretty easy to build a business case to support a registry of digital signatures on mortgage notes to last 30-50 odd years. There is a lot of money at stake and there will always be someone collecting on the note.

The problem is that we only have this type of business models for a small number of signatures and they are pretty boring applications. That still leaves open the question of how we make digital libraries as authentic and trustworthy as paper ones used to be.

Print is dead. In 100 years time nobody will be printing books other than for religious or sentimental reasons. People can argue about whether that should happen but it is very clear that it will happen.

A couple of years ago GM went bankrupt. A couple of weeks ago the worlds largest circulation tabloid went out of business despite robust profits. How can we say with confidence that a TSA is going to be around in 100 years time?

By making it a government service so it is not tied to the marketspace...

Why do you think Certichron does what it does - by the way - we just opened the 10th NIST Server we operate!

Todd



=A0
=A0
--
Website: http:/= /hallambaker.com/


_______________________________________________
ltans mailing list
ltans@ietf.org
h=
ttps://www.ietf.org/mailman/listinfo/ltans



--=20
Todd S. Glassey
This is from my personal email account and any materials from this account =
come with personal disclaimers.=20

Further I OPT OUT of any and all commercial emailings.=20

_______________________________________________
ltans mailing list
ltans@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/ltans




--
Website: http://hallambaker.com/

--001636b2b3029646e804a85b728c-- From tglassey@earthlink.net Mon Jul 18 11:13:36 2011 Return-Path: X-Original-To: ltans@ietfa.amsl.com Delivered-To: ltans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C94F221F8B47 for ; Mon, 18 Jul 2011 11:13:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.641 X-Spam-Level: X-Spam-Status: No, score=-3.641 tagged_above=-999 required=5 tests=[AWL=-1.043, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Feg7FnDUwf30 for ; Mon, 18 Jul 2011 11:13:33 -0700 (PDT) Received: from elasmtp-spurfowl.atl.sa.earthlink.net (elasmtp-spurfowl.atl.sa.earthlink.net [209.86.89.66]) by ietfa.amsl.com (Postfix) with ESMTP id A7D7321F8B4C for ; Mon, 18 Jul 2011 11:13:32 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=cWrE4BTHugJyY+HMOjuZfbAmwTYB9dUN3BeKZaddgFoiVjQfli/3azl84YL6Gmhl; h=Received:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:X-ELNK-Trace:X-Originating-IP; Received: from [207.111.209.5] (helo=[192.168.1.100]) by elasmtp-spurfowl.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1QisJv-0001hc-KR; Mon, 18 Jul 2011 14:13:32 -0400 Message-ID: <4E2477EA.7040906@earthlink.net> Date: Mon, 18 Jul 2011 11:14:02 -0700 From: todd glassey User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.18) Gecko/20110616 Lightning/1.0b2 Thunderbird/3.1.11 MIME-Version: 1.0 To: Phillip Hallam-Baker References: <4E2345E5.8050606@gondrom.org> <4E24055E.5040505@edelweb.fr> <4E246E19.7000703@earthlink.net> In-Reply-To: Content-Type: multipart/alternative; boundary="------------010608020102070301040704" X-ELNK-Trace: 01b7a7e171bdf5911aa676d7e74259b7b3291a7d08dfec79b3d9bad13f24ff78d9cc74f00c8b5050350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 207.111.209.5 Cc: ltans@ietf.org Subject: Re: [ltans] Harber and Stornetta expiry X-BeenThere: ltans@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: LTANS Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jul 2011 18:13:36 -0000 This is a multi-part message in MIME format. --------------010608020102070301040704 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 7/18/2011 10:37 AM, Phillip Hallam-Baker wrote: > How do we know governments will last that long? > > PHB - this isn't about building perfection - its about building a specific set of end-use solutions - something the IETF is uniquely incompetent at IMHO. Before ANYTHING happens - the use models and how their to be controlled has to be formally inked. Building them after the fact is more than stupid and ignorant - its the IETF Way. Todd G. > > Very few institutions have existed more than a few hundred years > without major changes in function and structure. Oxford was founded as > a religious community and only made training for the priesthood the > primary purpose in the middle ages. The idea of being a general > purpose educator comes from the Victorian era. > > > What I like about the Harber & Stornetta approach is that it allows > multiple archives to be bound together in ways that makes their > integrity interdependent. > > > > On Mon, Jul 18, 2011 at 1:32 PM, todd glassey > wrote: > > On 7/18/2011 5:07 AM, Phillip Hallam-Baker wrote: >> >> >> On Mon, Jul 18, 2011 at 6:05 AM, Peter Sylvester >> > >> wrote: >> >> The purpose of hash linking schemes is to link time stamps >> together and >> to be able to verify them without the need of any >> cryptographic key >> which have the tendency to have their secrecy evaporate. >> >> >> Its not the secrecy that worries me, its the ability to state >> with confidence that the TSA will be around after the commercial >> incentive is gone. >> >> Its pretty easy to build a business case to support a registry of >> digital signatures on mortgage notes to last 30-50 odd years. >> There is a lot of money at stake and there will always be someone >> collecting on the note. >> >> The problem is that we only have this type of business models for >> a small number of signatures and they are pretty boring >> applications. That still leaves open the question of how we make >> digital libraries as authentic and trustworthy as paper ones used >> to be. >> >> Print is dead. In 100 years time nobody will be printing books >> other than for religious or sentimental reasons. People can argue >> about whether that should happen but it is very clear that it >> will happen. >> >> A couple of years ago GM went bankrupt. A couple of weeks ago the >> worlds largest circulation tabloid went out of business despite >> robust profits. How can we say with confidence that a TSA is >> going to be around in 100 years time? > > By making it a government service so it is not tied to the > marketspace... > > Why do you think Certichron does what it does - by the way - we > just opened the 10th NIST Server we operate! > > Todd > > >> >> -- >> Website: http://hallambaker.com/ >> >> >> _______________________________________________ >> ltans mailing list >> ltans@ietf.org >> https://www.ietf.org/mailman/listinfo/ltans > > > -- > Todd S. Glassey > This is from my personal email account and any materials from this account come with personal disclaimers. > > Further I OPT OUT of any and all commercial emailings. > > > _______________________________________________ > ltans mailing list > ltans@ietf.org > https://www.ietf.org/mailman/listinfo/ltans > > > > > -- > Website: http://hallambaker.com/ > -- Todd S. Glassey This is from my personal email account and any materials from this account come with personal disclaimers. Further I OPT OUT of any and all commercial emailings. --------------010608020102070301040704 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 7/18/2011 10:37 AM, Phillip Hallam-Baker wrote:
How do we know governments will last that long?


PHB - this isn't about building perfection - its about building a specific set of end-use solutions - something the IETF is uniquely incompetent at IMHO.

Before ANYTHING happens - the use models and how their to be controlled has to be formally inked.  Building them after the fact is more than stupid and ignorant - its the IETF Way.

Todd G.

Very few institutions have existed more than a few hundred years without major changes in function and structure. Oxford was founded as a religious community and only made training for the priesthood the primary purpose in the middle ages. The idea of being a general purpose educator comes from the Victorian era.


What I like about the Harber & Stornetta approach is that it allows multiple archives to be bound together in ways that makes their integrity interdependent.



On Mon, Jul 18, 2011 at 1:32 PM, todd glassey <tglassey@earthlink.net> wrote:
On 7/18/2011 5:07 AM, Phillip Hallam-Baker wrote:


On Mon, Jul 18, 2011 at 6:05 AM, Peter Sylvester <peter.sylvester@edelweb.fr> wrote:
The purpose of hash linking schemes is to link time stamps together and
to be able to verify them without the need of any cryptographic key
which have the tendency to have their secrecy evaporate.   

Its not the secrecy that worries me, its the ability to state with confidence that the TSA will be around after the commercial incentive is gone.

Its pretty easy to build a business case to support a registry of digital signatures on mortgage notes to last 30-50 odd years. There is a lot of money at stake and there will always be someone collecting on the note.

The problem is that we only have this type of business models for a small number of signatures and they are pretty boring applications. That still leaves open the question of how we make digital libraries as authentic and trustworthy as paper ones used to be.

Print is dead. In 100 years time nobody will be printing books other than for religious or sentimental reasons. People can argue about whether that should happen but it is very clear that it will happen.

A couple of years ago GM went bankrupt. A couple of weeks ago the worlds largest circulation tabloid went out of business despite robust profits. How can we say with confidence that a TSA is going to be around in 100 years time?

By making it a government service so it is not tied to the marketspace...

Why do you think Certichron does what it does - by the way - we just opened the 10th NIST Server we operate!

Todd



 
 
--
Website: http://hallambaker.com/


_______________________________________________
ltans mailing list
ltans@ietf.org
https://www.ietf.org/mailman/listinfo/ltans



-- 
Todd S. Glassey
This is from my personal email account and any materials from this account come with personal disclaimers. 

Further I OPT OUT of any and all commercial emailings.

_______________________________________________
ltans mailing list
ltans@ietf.org
https://www.ietf.org/mailman/listinfo/ltans




--
Website: http://hallambaker.com/



-- 
Todd S. Glassey
This is from my personal email account and any materials from this account come with personal disclaimers. 

Further I OPT OUT of any and all commercial emailings.
--------------010608020102070301040704-- From wwwrun@rfc-editor.org Tue Jul 19 16:47:54 2011 Return-Path: X-Original-To: ltans@ietfa.amsl.com Delivered-To: ltans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D53CB21F84DC; Tue, 19 Jul 2011 16:47:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.157 X-Spam-Level: X-Spam-Status: No, score=-102.157 tagged_above=-999 required=5 tests=[AWL=-0.157, BAYES_00=-2.599, J_CHICKENPOX_93=0.6, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xCOAaVlKIKwj; Tue, 19 Jul 2011 16:47:54 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:1112:1::2f]) by ietfa.amsl.com (Postfix) with ESMTP id 7E89521F84D8; Tue, 19 Jul 2011 16:47:47 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 7285D98C508; Tue, 19 Jul 2011 16:47:47 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20110719234747.7285D98C508@rfc-editor.org> Date: Tue, 19 Jul 2011 16:47:47 -0700 (PDT) Cc: ltans@ietf.org, rfc-editor@rfc-editor.org Subject: [ltans] RFC 6283 on Extensible Markup Language Evidence Record Syntax (XMLERS) X-BeenThere: ltans@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: LTANS Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jul 2011 23:47:54 -0000 A new Request for Comments is now available in online RFC libraries. RFC 6283 Title: Extensible Markup Language Evidence Record Syntax (XMLERS) Author: A. Jerman Blazic, S. Saljic, T. Gondrom Status: Standards Track Stream: IETF Date: July 2011 Mailbox: aljosa@setcce.si, svetlana.saljic@setcce.si, tobias.gondrom@gondrom.org Pages: 43 Characters: 99031 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-ltans-xmlers-11.txt URL: http://www.rfc-editor.org/rfc/rfc6283.txt In many scenarios, users must be able to demonstrate the (time of) existence, integrity, and validity of data including signed data for long or undetermined periods of time. This document specifies XML syntax and processing rules for creating evidence for long-term non- repudiation of existence and integrity of data. The Extensible Markup Language Evidence Record Syntax XMLERS provides alternative syntax and processing rules to the ASN.1 (Abstract Syntax Notation One) ERS (Evidence Record Syntax) (RFC 4998) syntax by using XML. [STANDARDS-TRACK] This document is a product of the Long-Term Archive and Notary Services Working Group of the IETF. This is now a Proposed Standard Protocol. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From turners@ieca.com Tue Jul 19 17:05:08 2011 Return-Path: X-Original-To: ltans@ietfa.amsl.com Delivered-To: ltans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B20C21F862F for ; Tue, 19 Jul 2011 17:05:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.076 X-Spam-Level: X-Spam-Status: No, score=-102.076 tagged_above=-999 required=5 tests=[AWL=-0.078, BAYES_00=-2.599, J_CHICKENPOX_93=0.6, UNPARSEABLE_RELAY=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mPadn6sDT8Kb for ; Tue, 19 Jul 2011 17:05:04 -0700 (PDT) Received: from nm15.bullet.mail.sp2.yahoo.com (nm15.bullet.mail.sp2.yahoo.com [98.139.91.85]) by ietfa.amsl.com (Postfix) with SMTP id 7963E21F8551 for ; Tue, 19 Jul 2011 17:04:58 -0700 (PDT) Received: from [98.139.91.67] by nm15.bullet.mail.sp2.yahoo.com with NNFMP; 20 Jul 2011 00:04:55 -0000 Received: from [98.139.91.11] by tm7.bullet.mail.sp2.yahoo.com with NNFMP; 20 Jul 2011 00:04:55 -0000 Received: from [127.0.0.1] by omp1011.mail.sp2.yahoo.com with NNFMP; 20 Jul 2011 00:04:55 -0000 X-Yahoo-Newman-Id: 809888.8742.bm@omp1011.mail.sp2.yahoo.com Received: (qmail 81056 invoked from network); 20 Jul 2011 00:04:55 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1311120295; bh=UfQYN/ALkfF4mQjLDrC5WUrdfvrW+mu5Q9Qrrjye9TA=; h=X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:Received:Message-ID:Date:From:User-Agent:MIME-Version:To:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=F1gUaKPrrzksg23HOVn7Tmc2VepteALhUSTxDIQpMgYEJBzYlF5K7aaLYlFK0gPAtkZZXIXzYKIDoR/BjF7n3/3oQJkwUW0H2MxmuwZ5MigAuktXRKWPLiC4BizD0h3vHVA9IibN7PoWmPDq/7Hp1XKPlYD8pzyuabNW/mD6T+8= X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: O_rsSroVM1lYuPpHE7jtbrXDEuweZaRmLNLXah27Dj1l99G Hn86s5ZY3qjBm9NUhVgjNUpBlFQc0C.vv.HL6gQnHmCJCakfg1dwUg21EiEa 11_H2Yxi.LmbeyNJ2PngTYgdyPt_c6Op9jm6UExuqO1qR4FwbXMQ0PEZlll_ 8fDBn9ufADmbjT.04AuYu_qa606qIPx8qsHMDeklktdFF9F7p0Ea_MBCVnOb iQ7nLcieW2cWE99_Nck1x7RrhByLqFGIplAk.urK9YXKFouihL8ABzE_687L EaQBM7UWd8qQJm_K7zT_DNervwTUw2XsI9LLhacqmqtg3UIWdjcrnDZjsQn1 YZkAOm0uOH7F9hQYYux6Bgno- X-Yahoo-SMTP: ZrP3VLSswBDL75pF8ymZHDSu9B.vcMfDPgLJ Received: from thunderfish.westell.com (turners@96.241.0.190 with plain) by smtp111.biz.mail.mud.yahoo.com with SMTP; 19 Jul 2011 17:04:55 -0700 PDT Message-ID: <4E261BA6.4000604@ieca.com> Date: Tue, 19 Jul 2011 20:04:54 -0400 From: Sean Turner User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: ltans@ietf.org References: <20110719234747.7285D98C508@rfc-editor.org> In-Reply-To: <20110719234747.7285D98C508@rfc-editor.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [ltans] RFC 6283 on Extensible Markup Language Evidence Record Syntax (XMLERS) X-BeenThere: ltans@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: LTANS Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jul 2011 00:05:08 -0000 Congrats! spt On 7/19/11 7:47 PM, rfc-editor@rfc-editor.org wrote: > > A new Request for Comments is now available in online RFC libraries. > > > RFC 6283 > > Title: Extensible Markup Language Evidence Record > Syntax (XMLERS) > Author: A. Jerman Blazic, S. Saljic, > T. Gondrom > Status: Standards Track > Stream: IETF > Date: July 2011 > Mailbox: aljosa@setcce.si, > svetlana.saljic@setcce.si, > tobias.gondrom@gondrom.org > Pages: 43 > Characters: 99031 > Updates/Obsoletes/SeeAlso: None > > I-D Tag: draft-ietf-ltans-xmlers-11.txt > > URL: http://www.rfc-editor.org/rfc/rfc6283.txt > > In many scenarios, users must be able to demonstrate the (time of) > existence, integrity, and validity of data including signed data for > long or undetermined periods of time. This document specifies XML > syntax and processing rules for creating evidence for long-term non- > repudiation of existence and integrity of data. The Extensible Markup > Language Evidence Record Syntax XMLERS provides alternative syntax and > processing rules to the ASN.1 (Abstract Syntax Notation One) ERS > (Evidence Record Syntax) (RFC 4998) syntax by using XML. [STANDARDS-TRACK] > > This document is a product of the Long-Term Archive and Notary Services Working Group of the IETF. > > This is now a Proposed Standard Protocol. > > STANDARDS TRACK: This document specifies an Internet standards track > protocol for the Internet community,and requests discussion and suggestions > for improvements. Please refer to the current edition of the Internet > Official Protocol Standards (STD 1) for the standardization state and > status of this protocol. Distribution of this memo is unlimited. > > This announcement is sent to the IETF-Announce and rfc-dist lists. > To subscribe or unsubscribe, see > http://www.ietf.org/mailman/listinfo/ietf-announce > http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist > > For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. > For downloading RFCs, see http://www.rfc-editor.org/rfc.html. > > Requests for special distribution should be addressed to either the > author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless > specifically noted otherwise on the RFC itself, all RFCs are for > unlimited distribution. > > > The RFC Editor Team > Association Management Solutions, LLC > > > _______________________________________________ > ltans mailing list > ltans@ietf.org > https://www.ietf.org/mailman/listinfo/ltans > From wwwrun@ietfa.amsl.com Tue Jul 19 18:28:54 2011 Return-Path: X-Original-To: ltans@ietf.org Delivered-To: ltans@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 30) id 177B011E808B; Tue, 19 Jul 2011 18:28:54 -0700 (PDT) From: IESG Secretary To: IETF Announcement list Content-Type: text/plain; charset="utf-8" Mime-Version: 1.0 Message-Id: <20110720012854.177B011E808B@ietfa.amsl.com> Date: Tue, 19 Jul 2011 18:28:54 -0700 (PDT) Cc: tobias.gondrom@gondrom.org, ltans@ietf.org Subject: [ltans] WG Action: Conclusion of Long-Term Archive and Notary Services (ltans) X-BeenThere: ltans@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: LTANS Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jul 2011 01:28:54 -0000 The Long-Term Archive and Notary Services (ltans) working group in the Security Area has concluded. The IESG contact persons are Sean Turner and Stephen Farrell. The ltans working group has completed its primary charter items, and is officially closing. The mailing list will be retained for future discussions involving ltans. The list archive will also be retained. The ltans working group was primarily focused on defining requirements, data structures and protocols for the secure usage of archive and notary services. In total the working group published five RFCs, including Long-Term Archive Service Requirements (RFC 4810), Evidence Record Syntax (ERS) (RFC 4998), Using the Server-Based Certificate Validation Protocol (SCVP) to Convey Long-Term Evidence Records (RFC 5276), Data Structure for the Security Suitability of Cryptographic Algorithms (DSSC) (RFC 5698), and Extensible Markup Language Evidence Record Syntax (RFC 6283). We would like to thank all of the IETF participants who have contributed to the various documents produced by the ltans working group and to the successful completion of these deliverables. We especially thank Carl Wallace and Tobias Gondrom who have chaired the working group from its inception. From tglassey@earthlink.net Wed Jul 20 07:48:45 2011 Return-Path: X-Original-To: ltans@ietfa.amsl.com Delivered-To: ltans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5387521F89BA; Wed, 20 Jul 2011 07:48:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.511 X-Spam-Level: X-Spam-Status: No, score=-3.511 tagged_above=-999 required=5 tests=[AWL=-0.912, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hdrsEa+b4WDJ; Wed, 20 Jul 2011 07:48:40 -0700 (PDT) Received: from elasmtp-curtail.atl.sa.earthlink.net (elasmtp-curtail.atl.sa.earthlink.net [209.86.89.64]) by ietfa.amsl.com (Postfix) with ESMTP id 9284B21F889F; Wed, 20 Jul 2011 07:48:34 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=pVODcioVWOFJW5gsXA10jqdX8/1fjSeH1fnh33GSxmohLj6HdMJQYW12aHf6Efry; h=Received:Message-ID:Date:From:User-Agent:MIME-Version:To:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP; Received: from [207.111.209.5] (helo=[192.168.1.100]) by elasmtp-curtail.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1QjY4f-0007wI-WA; Wed, 20 Jul 2011 10:48:34 -0400 Message-ID: <4E26EAE1.9050307@earthlink.net> Date: Wed, 20 Jul 2011 07:49:05 -0700 From: todd glassey User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.18) Gecko/20110616 Lightning/1.0b2 Thunderbird/3.1.11 MIME-Version: 1.0 To: ltans@ietf.org, chair@IETF.org References: <20110720012854.177B011E808B@ietfa.amsl.com> In-Reply-To: <20110720012854.177B011E808B@ietfa.amsl.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 01b7a7e171bdf5911aa676d7e74259b7b3291a7d08dfec794bc7cf3a2a1e5d338e918ffbba6988ba350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 207.111.209.5 Subject: Re: [ltans] WG Action: Conclusion of Long-Term Archive and Notary Services (ltans) X-BeenThere: ltans@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: LTANS Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jul 2011 14:48:45 -0000 On 7/19/2011 6:28 PM, IESG Secretary wrote: > The Long-Term Archive and Notary Services (ltans) working group in the > Security Area has concluded. The IESG contact persons are Sean Turner > and Stephen Farrell. So there is actually no Notary's process in any of this code. No Notarial signing ceremony and more importantly no Notarial Organization as a sponsor... As such - and since the term NOTORIAL pertains to a legal standing, i.e. as in 'from an act from a commissioned Notary Public" - something this protocol has none of the representing it as a replacement or extension of a commissioned Notary Public is a form of fraud. No I am not kidding... If you dont believe me look at California's Apostilles Page for certifications issued under the Notary's Commission to perform signings. What you will see is that a Notary is similar to the term Judge, when used in an official context it applies to a person appointed under the Notarial commission of the issuing State or Entity. http://www.sos.ca.gov/business/notary/authentication.htm which of course are further controlled under the International Definition of the Apostilles under the Hague Convention - read it at http://www.hcch.net/index_en.php?act=text.display&tid=37 The real issue here (and the sad one) is how much human effort went into this effort after the WG members were made aware of these legal issues with their work, and how far from the mark based on a simple reading of these documents that the WG ultimately landed. Todd Glassey > The ltans working group has completed its primary charter items, and is > officially closing. The mailing list will be retained for future > discussions involving ltans. The list archive will also be retained. > > The ltans working group was primarily focused on defining requirements, > data structures and protocols for the secure usage of archive and notary > services. In total the working group published five RFCs, including > Long-Term Archive Service Requirements (RFC 4810), Evidence Record > Syntax (ERS) (RFC 4998), Using the Server-Based Certificate Validation > Protocol (SCVP) to Convey Long-Term Evidence Records (RFC 5276), Data > Structure for the Security Suitability of Cryptographic Algorithms > (DSSC) (RFC 5698), and Extensible Markup Language Evidence Record Syntax > (RFC 6283). > > We would like to thank all of the IETF participants who have contributed > to the various documents produced by the ltans working group and to the > successful completion of these deliverables. We especially thank Carl > Wallace and Tobias Gondrom who have chaired the working group from its > inception. > _______________________________________________ > ltans mailing list > ltans@ietf.org > https://www.ietf.org/mailman/listinfo/ltans > -- Todd S. Glassey This is from my personal email account and any materials from this account come with personal disclaimers. Further I OPT OUT of any and all commercial emailings. From carl@redhoundsoftware.com Wed Jul 20 08:12:39 2011 Return-Path: X-Original-To: ltans@ietfa.amsl.com Delivered-To: ltans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9553B21F89BE; Wed, 20 Jul 2011 08:12:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.459 X-Spam-Level: X-Spam-Status: No, score=-3.459 tagged_above=-999 required=5 tests=[AWL=0.140, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PFoJME+cXE5K; Wed, 20 Jul 2011 08:12:39 -0700 (PDT) Received: from mail-qy0-f172.google.com (mail-qy0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id D04A821F8915; Wed, 20 Jul 2011 08:12:38 -0700 (PDT) Received: by qyk9 with SMTP id 9so3563956qyk.10 for ; Wed, 20 Jul 2011 08:12:36 -0700 (PDT) Received: by 10.224.18.76 with SMTP id v12mr7360978qaa.338.1311174756250; Wed, 20 Jul 2011 08:12:36 -0700 (PDT) Received: from [192.168.1.5] (pool-173-79-132-155.washdc.fios.verizon.net [173.79.132.155]) by mx.google.com with ESMTPS id cd4sm291545qab.12.2011.07.20.08.12.33 (version=SSLv3 cipher=OTHER); Wed, 20 Jul 2011 08:12:34 -0700 (PDT) User-Agent: Microsoft-MacOutlook/14.12.0.110505 Date: Wed, 20 Jul 2011 11:12:31 -0400 From: Carl Wallace To: todd glassey , , Message-ID: Thread-Topic: [ltans] WG Action: Conclusion of Long-Term Archive and Notary Services (ltans) In-Reply-To: <4E26EAE1.9050307@earthlink.net> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Subject: Re: [ltans] WG Action: Conclusion of Long-Term Archive and Notary Services (ltans) X-BeenThere: ltans@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: LTANS Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jul 2011 15:12:39 -0000 On 7/20/11 10:49 AM, "todd glassey" wrote: >On 7/19/2011 6:28 PM, IESG Secretary wrote: >> The Long-Term Archive and Notary Services (ltans) working group in the >> Security Area has concluded. The IESG contact persons are Sean Turner >> and Stephen Farrell. >So there is actually no Notary's process in any of this code. Correct. In accord with the charter, a requirements gathering effort for potential notary-related work was conducted. The results were reviewed by the working group and work on notary-related standards was suspended at IETF 65 due to lack of interest in pursuing the topic. From tglassey@earthlink.net Wed Jul 20 09:10:05 2011 Return-Path: X-Original-To: ltans@ietfa.amsl.com Delivered-To: ltans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D23E821F8AE9; Wed, 20 Jul 2011 09:10:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.41 X-Spam-Level: X-Spam-Status: No, score=-3.41 tagged_above=-999 required=5 tests=[AWL=-0.811, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g3D8A4gVVamK; Wed, 20 Jul 2011 09:10:05 -0700 (PDT) Received: from elasmtp-spurfowl.atl.sa.earthlink.net (elasmtp-spurfowl.atl.sa.earthlink.net [209.86.89.66]) by ietfa.amsl.com (Postfix) with ESMTP id ED82421F8AEF; Wed, 20 Jul 2011 09:10:04 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=sjC+amCRv18k5FcGQoExYxrWQdK/S1vVG5j9LLpcr4jLN3W3q/LAYbWgpdgEbXZI; h=Received:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP; Received: from [207.111.209.5] (helo=[192.168.1.100]) by elasmtp-spurfowl.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1QjZLG-0002qR-Q1; Wed, 20 Jul 2011 12:09:46 -0400 Message-ID: <4E26FDEA.1050706@earthlink.net> Date: Wed, 20 Jul 2011 09:10:18 -0700 From: todd glassey User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.18) Gecko/20110616 Lightning/1.0b2 Thunderbird/3.1.11 MIME-Version: 1.0 To: Carl Wallace References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 01b7a7e171bdf5911aa676d7e74259b7b3291a7d08dfec79d791b5eadc187472f3a932c83dd41435350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 207.111.209.5 Cc: chair@IETF.org, ltans@ietf.org Subject: Re: [ltans] WG Action: Conclusion of Long-Term Archive and Notary Services (ltans) X-BeenThere: ltans@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: LTANS Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jul 2011 16:10:05 -0000 On 7/20/2011 8:12 AM, Carl Wallace wrote: > On 7/20/11 10:49 AM, "todd glassey" wrote: > >> On 7/19/2011 6:28 PM, IESG Secretary wrote: >>> The Long-Term Archive and Notary Services (ltans) working group in the >>> Security Area has concluded. The IESG contact persons are Sean Turner >>> and Stephen Farrell. >> So there is actually no Notary's process in any of this code. > Correct. In accord with the charter, a requirements gathering effort for > potential notary-related work was conducted. From who - the engineers working on the protocol??? - do any of them have legal backgrounds which would be competent to advise here? Will any of their sponsors take legal culpability for those parties actions? You see my point? Its time for accountability here in the IETF to be real. > The results were reviewed by > the working group and work on notary-related standards was suspended at > IETF 65 due to lack of interest in pursuing the topic. Which means that the terms and any reference to the concept of "Legal Document Control" per the apostles practices have to be cleansed from these works. i.e. someone with a redline needs to cut out all references to Notary anything. That said, it means simply that this WG isnt done and that until those issues are completed, that NONE of the works can be finalized... or that they can and must all be pulled - since the IETF itself becomes a party to the fraud of misrepresenting its IP's as 'replacing legal roles' in the Human population. The IETF has never made a legal statement about any of its protocols before LTANS, but I think that by using the Legal Term "NOTARY" in both the WG's title and its operating practices, it opens the IETF to this review. t. -- Todd S. Glassey This is from my personal email account and any materials from this account come with personal disclaimers. Further I OPT OUT of any and all commercial emailings. From carl@redhoundsoftware.com Wed Jul 20 09:32:10 2011 Return-Path: X-Original-To: ltans@ietfa.amsl.com Delivered-To: ltans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A4E0B21F85AA; Wed, 20 Jul 2011 09:32:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.483 X-Spam-Level: X-Spam-Status: No, score=-3.483 tagged_above=-999 required=5 tests=[AWL=0.116, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xlO4YsiFs-GV; Wed, 20 Jul 2011 09:32:10 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id E8DFB21F85A4; Wed, 20 Jul 2011 09:32:09 -0700 (PDT) Received: by vws12 with SMTP id 12so364971vws.31 for ; Wed, 20 Jul 2011 09:32:09 -0700 (PDT) Received: by 10.220.209.133 with SMTP id gg5mr2253800vcb.150.1311179529323; Wed, 20 Jul 2011 09:32:09 -0700 (PDT) Received: from [192.168.1.5] (pool-173-79-132-155.washdc.fios.verizon.net [173.79.132.155]) by mx.google.com with ESMTPS id bp11sm118615vcb.0.2011.07.20.09.32.07 (version=SSLv3 cipher=OTHER); Wed, 20 Jul 2011 09:32:08 -0700 (PDT) User-Agent: Microsoft-MacOutlook/14.12.0.110505 Date: Wed, 20 Jul 2011 12:32:04 -0400 From: Carl Wallace To: todd glassey Message-ID: Thread-Topic: [ltans] WG Action: Conclusion of Long-Term Archive and Notary Services (ltans) In-Reply-To: <4E26FDEA.1050706@earthlink.net> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: chair@IETF.org, ltans@ietf.org Subject: Re: [ltans] WG Action: Conclusion of Long-Term Archive and Notary Services (ltans) X-BeenThere: ltans@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: LTANS Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jul 2011 16:32:10 -0000 The good news is that none of the 5 completed specs address notary-related concepts. Each spec addresses fairly narrow concepts consistent with the backgrounds of the volunteers contributing the work. While it may be unfortunate that the term notary appears in the working group name, the notary concept was from the inception of the working group considered to be a topic area that would not necessarily result in new standards. On 7/20/11 12:10 PM, "todd glassey" wrote: >On 7/20/2011 8:12 AM, Carl Wallace wrote: >> On 7/20/11 10:49 AM, "todd glassey" wrote: >> >>> On 7/19/2011 6:28 PM, IESG Secretary wrote: >>>> The Long-Term Archive and Notary Services (ltans) working group in the >>>> Security Area has concluded. The IESG contact persons are Sean Turner >>>> and Stephen Farrell. >>> So there is actually no Notary's process in any of this code. >> Correct. In accord with the charter, a requirements gathering effort >>for >> potential notary-related work was conducted. > From who - the engineers working on the protocol??? - do any of them >have legal backgrounds which would be competent to advise here? Will any >of their sponsors take legal culpability for those parties actions? You >see my point? > >Its time for accountability here in the IETF to be real. >> The results were reviewed by >> the working group and work on notary-related standards was suspended at >> IETF 65 due to lack of interest in pursuing the topic. > >Which means that the terms and any reference to the concept of "Legal >Document Control" per the apostles practices have to be cleansed from >these works. i.e. someone with a redline needs to cut out all >references to Notary anything. That said, it means simply that this WG >isnt done and that until those issues are completed, that NONE of the >works can be finalized... or that they can and must all be pulled - >since the IETF itself becomes a party to the fraud of misrepresenting >its IP's as 'replacing legal roles' in the Human population. > >The IETF has never made a legal statement about any of its protocols >before LTANS, but I think that by using the Legal Term "NOTARY" in both >the WG's title and its operating practices, it opens the IETF to this >review. > >t. > > > >-- >Todd S. Glassey >This is from my personal email account and any materials from this >account come with personal disclaimers. > >Further I OPT OUT of any and all commercial emailings. > From hallam@gmail.com Wed Jul 20 09:48:15 2011 Return-Path: X-Original-To: ltans@ietfa.amsl.com Delivered-To: ltans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F7B921F8A4F; Wed, 20 Jul 2011 09:48:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.514 X-Spam-Level: X-Spam-Status: No, score=-3.514 tagged_above=-999 required=5 tests=[AWL=0.084, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XWfJWoQtlw9U; Wed, 20 Jul 2011 09:48:10 -0700 (PDT) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 650D221F8AF5; Wed, 20 Jul 2011 09:48:10 -0700 (PDT) Received: by gxk19 with SMTP id 19so212679gxk.31 for ; Wed, 20 Jul 2011 09:48:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=3GW+JfN943bQ1zzJ4qme0TZof6QvXL635aVsG+3Td58=; b=pFBzf3IgrSFDdG+V1YnvvDDpnHeQsyxY3aJldRT/eXg8EW5u56PMZFaHyanpHrTRrg 1CgSNN2ONJKJDw19Nja4T3DxiuuUByaGBqgYzKFww2YWUo8ApABpOx3N4H6Kh8GDzlPh Dr/59uRYSY90oL3CQmkhOELEy0bqY/5Xbu1+Q= MIME-Version: 1.0 Received: by 10.100.75.12 with SMTP id x12mr8216660ana.27.1311180489803; Wed, 20 Jul 2011 09:48:09 -0700 (PDT) Received: by 10.100.202.5 with HTTP; Wed, 20 Jul 2011 09:48:09 -0700 (PDT) In-Reply-To: References: <4E26FDEA.1050706@earthlink.net> Date: Wed, 20 Jul 2011 12:48:09 -0400 Message-ID: From: Phillip Hallam-Baker To: Carl Wallace Content-Type: multipart/alternative; boundary=001636b2af5354c96e04a882ffce Cc: chair@ietf.org, ltans@ietf.org Subject: Re: [ltans] WG Action: Conclusion of Long-Term Archive and Notary Services (ltans) X-BeenThere: ltans@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: LTANS Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jul 2011 16:48:15 -0000 --001636b2af5354c96e04a882ffce Content-Type: text/plain; charset=ISO-8859-1 Exactly, a WG should do something right or not at all. In this case they choose not at all. That is fine with me. Todd seems to be giving some pretty good reasons to not do notary. What I am interested in is probably a little speculative. I would like to have a form of data repository that we could establish some pretty good expectations of it surviving for a very long time and for the integrity of the data within it to be witnessed by a sufficiently large set of witnesses that forgery is implausible. On Wed, Jul 20, 2011 at 12:32 PM, Carl Wallace wrote: > The good news is that none of the 5 completed specs address notary-related > concepts. Each spec addresses fairly narrow concepts consistent with the > backgrounds of the volunteers contributing the work. While it may be > unfortunate that the term notary appears in the working group name, the > notary concept was from the inception of the working group considered to > be a topic area that would not necessarily result in new standards. > > On 7/20/11 12:10 PM, "todd glassey" wrote: > > >On 7/20/2011 8:12 AM, Carl Wallace wrote: > >> On 7/20/11 10:49 AM, "todd glassey" wrote: > >> > >>> On 7/19/2011 6:28 PM, IESG Secretary wrote: > >>>> The Long-Term Archive and Notary Services (ltans) working group in the > >>>> Security Area has concluded. The IESG contact persons are Sean Turner > >>>> and Stephen Farrell. > >>> So there is actually no Notary's process in any of this code. > >> Correct. In accord with the charter, a requirements gathering effort > >>for > >> potential notary-related work was conducted. > > From who - the engineers working on the protocol??? - do any of them > >have legal backgrounds which would be competent to advise here? Will any > >of their sponsors take legal culpability for those parties actions? You > >see my point? > > > >Its time for accountability here in the IETF to be real. > >> The results were reviewed by > >> the working group and work on notary-related standards was suspended at > >> IETF 65 due to lack of interest in pursuing the topic. > > > >Which means that the terms and any reference to the concept of "Legal > >Document Control" per the apostles practices have to be cleansed from > >these works. i.e. someone with a redline needs to cut out all > >references to Notary anything. That said, it means simply that this WG > >isnt done and that until those issues are completed, that NONE of the > >works can be finalized... or that they can and must all be pulled - > >since the IETF itself becomes a party to the fraud of misrepresenting > >its IP's as 'replacing legal roles' in the Human population. > > > >The IETF has never made a legal statement about any of its protocols > >before LTANS, but I think that by using the Legal Term "NOTARY" in both > >the WG's title and its operating practices, it opens the IETF to this > >review. > > > >t. > > > > > > > >-- > >Todd S. Glassey > >This is from my personal email account and any materials from this > >account come with personal disclaimers. > > > >Further I OPT OUT of any and all commercial emailings. > > > > > _______________________________________________ > ltans mailing list > ltans@ietf.org > https://www.ietf.org/mailman/listinfo/ltans > -- Website: http://hallambaker.com/ --001636b2af5354c96e04a882ffce Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Exactly, a WG should do something right or not at all. In this case they ch= oose not at all. That is fine with me.

Todd seems to be = giving some pretty good reasons to not do notary.


What I am interested in is probably a little speculative. I = would like to have a form of data repository that we could establish some p= retty good expectations of it surviving for a very long time and for the in= tegrity of the data within it to be witnessed by a sufficiently large set o= f witnesses that forgery is implausible.



On Wed, Jul 20= , 2011 at 12:32 PM, Carl Wallace <carl@redhoundsoftware.com> wrote:
The good news is that none of the 5 completed specs address notary-related<= br> concepts. =A0Each spec addresses fairly narrow concepts consistent with the=
backgrounds of the volunteers contributing the work. =A0While it may be
unfortunate that the term notary appears in the working group name, the
notary concept was from the inception of the working group considered to be a topic area that would not necessarily result in new standards.

On 7/20/11 12:10 PM, "todd glassey" <tglassey@earthlink.net> wrote:

>On 7/20/2011 8:12 AM, Carl Wallace wrote:
>> On 7/20/11 10:49 AM, "todd glassey"<tglassey@earthlink.net> =A0wrote:
>>
>>> On 7/19/2011 6:28 PM, IESG Secretary wrote:
>>>> The Long-Term Archive and Notary Services (ltans) working = group in the
>>>> Security Area has concluded. The IESG contact persons are = Sean Turner
>>>> and Stephen Farrell.
>>> So there is actually no Notary's process in any of this co= de.
>> Correct. =A0In accord with the charter, a requirements gathering e= ffort
>>for
>> potential notary-related work was conducted.
> From who - the engineers working on the protocol??? - do any of them >have legal backgrounds which would be competent to advise here? Will an= y
>of their sponsors take legal culpability for those parties actions? =A0= You
>see my point?
>
>Its time for accountability here in the IETF to be real.
>> The results were reviewed by
>> the working group and work on notary-related standards was suspend= ed at
>> IETF 65 due to lack of interest in pursuing the topic.
>
>Which means that the terms and any reference to the concept of "Le= gal
>Document Control" per the apostles practices have to be cleansed f= rom
>these works. =A0i.e. someone with a redline needs to cut out all
>references to Notary anything. That said, it means simply that this WG<= br> >isnt done and that until those issues are completed, that NONE of the >works can be finalized... or that they can and must all be pulled -
>since the IETF itself becomes a party to the fraud of misrepresenting >its IP's as 'replacing legal roles' in the Human population= .
>
>The IETF has never made a legal statement about any of its protocols >before LTANS, but I think that by using the Legal Term "NOTARY&quo= t; in both
>the WG's title and its operating practices, it opens the IETF to th= is
>review.
>
>t.
>
>
>
>--
>Todd S. Glassey
>This is from my personal email account and any materials from this
>account come with personal disclaimers.
>
>Further I OPT OUT of any and all commercial emailings.
>


_______________________________________________
ltans mailing list
ltans@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/ltans



--
Website: http://hallambaker.com/

--001636b2af5354c96e04a882ffce-- From tglassey@earthlink.net Wed Jul 20 12:03:34 2011 Return-Path: X-Original-To: ltans@ietfa.amsl.com Delivered-To: ltans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1CF6121F84AC; Wed, 20 Jul 2011 12:03:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.329 X-Spam-Level: X-Spam-Status: No, score=-3.329 tagged_above=-999 required=5 tests=[AWL=-0.730, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wn-Vc7DcgUHV; Wed, 20 Jul 2011 12:03:33 -0700 (PDT) Received: from elasmtp-scoter.atl.sa.earthlink.net (elasmtp-scoter.atl.sa.earthlink.net [209.86.89.67]) by ietfa.amsl.com (Postfix) with ESMTP id F331B21F84AE; Wed, 20 Jul 2011 12:02:42 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=MxoTkX3R9jHhwgVRTM4W2GKBqHe3MNvJRXurBTB95+6ZDJwElkm/p45naE1KCdon; h=Received:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP; Received: from [207.111.209.5] (helo=[192.168.1.100]) by elasmtp-scoter.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1Qjc2c-0001LY-CU; Wed, 20 Jul 2011 15:02:42 -0400 Message-ID: <4E272671.4070105@earthlink.net> Date: Wed, 20 Jul 2011 12:03:13 -0700 From: todd glassey User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.18) Gecko/20110616 Lightning/1.0b2 Thunderbird/3.1.11 MIME-Version: 1.0 To: Carl Wallace References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 01b7a7e171bdf5911aa676d7e74259b7b3291a7d08dfec797cc8c18208eee8e92d807f146b1dc492350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 207.111.209.5 Cc: chair@IETF.org, ltans@ietf.org Subject: Re: [ltans] WG Action: Conclusion of Long-Term Archive and Notary Services (ltans) X-BeenThere: ltans@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: LTANS Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jul 2011 19:03:34 -0000 On 7/20/2011 9:32 AM, Carl Wallace wrote: > The good news is that none of the 5 completed specs address notary-related > concepts. Each spec addresses fairly narrow concepts consistent with the > backgrounds of the volunteers contributing the work. Yes as a solution which is represented through the name and charter of the WG to have implications or use as a notarial resource... i.e. that they are formally a part of a Notarial Solution which they are not. If there is no assertion to constrain Notarial splendor in this code or its process uses, then the N word needs to be washed from everything- including anything that would through search engines allow an idiot not trained in the art to come to the belief that this code cannot be used in its current form for notarial anything... > While it may be > unfortunate that the term notary appears in the working group name, the > notary concept was from the inception of the working group considered to > be a topic area that would not necessarily result in new standards. The problem comes this creates comes not from the IETF actions but from those which are from relying parties. The title representing that this WG was chartered and produced work which is constrained under that magic N word is still binding. The issue is the use of a term of art which has legal implications and the intentional vagueness so that people will interpret or subliminally equate this with Notarial Apostilles which it simple isn't. I think the effort and practice was excellent for a very specific set of very limited uses, and that the protocol and its defined practice components like most other IETF works lacks any use-specification for the intent of the developers in how this protocol should be used specifically. This is a very common game played in the IETF by techies who want to build the biggest dick they possibly can swing in public and bluntly its pretty offensive. Look, you may think this is a nothing issue, but as a contributor you are contained by it and the use of it in administering this WG... Its all about transparency and its time the IETF got a serious dose of sunshine... Todd > On 7/20/11 12:10 PM, "todd glassey" wrote: > >> On 7/20/2011 8:12 AM, Carl Wallace wrote: >>> On 7/20/11 10:49 AM, "todd glassey" wrote: >>> >>>> On 7/19/2011 6:28 PM, IESG Secretary wrote: >>>>> The Long-Term Archive and Notary Services (ltans) working group in the >>>>> Security Area has concluded. The IESG contact persons are Sean Turner >>>>> and Stephen Farrell. >>>> So there is actually no Notary's process in any of this code. >>> Correct. In accord with the charter, a requirements gathering effort >>> for >>> potential notary-related work was conducted. >> From who - the engineers working on the protocol??? - do any of them >> have legal backgrounds which would be competent to advise here? Will any >> of their sponsors take legal culpability for those parties actions? You >> see my point? >> >> Its time for accountability here in the IETF to be real. >>> The results were reviewed by >>> the working group and work on notary-related standards was suspended at >>> IETF 65 due to lack of interest in pursuing the topic. >> Which means that the terms and any reference to the concept of "Legal >> Document Control" per the apostles practices have to be cleansed from >> these works. i.e. someone with a redline needs to cut out all >> references to Notary anything. That said, it means simply that this WG >> isnt done and that until those issues are completed, that NONE of the >> works can be finalized... or that they can and must all be pulled - >> since the IETF itself becomes a party to the fraud of misrepresenting >> its IP's as 'replacing legal roles' in the Human population. >> >> The IETF has never made a legal statement about any of its protocols >> before LTANS, but I think that by using the Legal Term "NOTARY" in both >> the WG's title and its operating practices, it opens the IETF to this >> review. >> >> t. >> >> >> >> -- >> Todd S. Glassey >> This is from my personal email account and any materials from this >> account come with personal disclaimers. >> >> Further I OPT OUT of any and all commercial emailings. >> > > -- Todd S. Glassey This is from my personal email account and any materials from this account come with personal disclaimers. Further I OPT OUT of any and all commercial emailings. From tglassey@earthlink.net Wed Jul 20 12:04:54 2011 Return-Path: X-Original-To: ltans@ietfa.amsl.com Delivered-To: ltans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F26F21F847D; Wed, 20 Jul 2011 12:04:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.262 X-Spam-Level: X-Spam-Status: No, score=-3.262 tagged_above=-999 required=5 tests=[AWL=-0.664, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zjnA2UP3Ejvn; Wed, 20 Jul 2011 12:04:50 -0700 (PDT) Received: from elasmtp-banded.atl.sa.earthlink.net (elasmtp-banded.atl.sa.earthlink.net [209.86.89.70]) by ietfa.amsl.com (Postfix) with ESMTP id C8EB321F8450; Wed, 20 Jul 2011 12:04:44 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=fFp+V/N+F10QFQ3t47hkdC97z8f731pC9n++O4IKI221GGjAHSCgl6JC8deZrqr8; h=Received:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:X-ELNK-Trace:X-Originating-IP; Received: from [207.111.209.5] (helo=[192.168.1.100]) by elasmtp-banded.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1Qjc4Z-0005UZ-OC; Wed, 20 Jul 2011 15:04:44 -0400 Message-ID: <4E2726EB.8030002@earthlink.net> Date: Wed, 20 Jul 2011 12:05:15 -0700 From: todd glassey User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.18) Gecko/20110616 Lightning/1.0b2 Thunderbird/3.1.11 MIME-Version: 1.0 To: Phillip Hallam-Baker References: <4E26FDEA.1050706@earthlink.net> In-Reply-To: Content-Type: multipart/alternative; boundary="------------040600020703000806070807" X-ELNK-Trace: 01b7a7e171bdf5911aa676d7e74259b7b3291a7d08dfec79ea18772e16d46dd8df832c666ce14ec3350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 207.111.209.5 Cc: chair@ietf.org, ltans@ietf.org Subject: Re: [ltans] WG Action: Conclusion of Long-Term Archive and Notary Services (ltans) X-BeenThere: ltans@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: LTANS Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jul 2011 19:04:54 -0000 This is a multi-part message in MIME format. --------------040600020703000806070807 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 7/20/2011 9:48 AM, Phillip Hallam-Baker wrote: > Exactly, a WG should do something right or not at all. In this case > they choose not at all. That is fine with me. The problem is they didnt remove the SCOPE STATEMENT from the WG Name and so now whenever a search is done for those documents they are tied to the term NOTARIAL even though they have nothing to do with it... Todd > > Todd seems to be giving some pretty good reasons to not do notary. > > > What I am interested in is probably a little speculative. I would like > to have a form of data repository that we could establish some pretty > good expectations of it surviving for a very long time and for the > integrity of the data within it to be witnessed by a sufficiently > large set of witnesses that forgery is implausible. > > > > On Wed, Jul 20, 2011 at 12:32 PM, Carl Wallace > > wrote: > > The good news is that none of the 5 completed specs address > notary-related > concepts. Each spec addresses fairly narrow concepts consistent > with the > backgrounds of the volunteers contributing the work. While it may be > unfortunate that the term notary appears in the working group > name, the > notary concept was from the inception of the working group > considered to > be a topic area that would not necessarily result in new standards. > > On 7/20/11 12:10 PM, "todd glassey" > wrote: > > >On 7/20/2011 8:12 AM, Carl Wallace wrote: > >> On 7/20/11 10:49 AM, "todd glassey" > wrote: > >> > >>> On 7/19/2011 6:28 PM, IESG Secretary wrote: > >>>> The Long-Term Archive and Notary Services (ltans) working > group in the > >>>> Security Area has concluded. The IESG contact persons are > Sean Turner > >>>> and Stephen Farrell. > >>> So there is actually no Notary's process in any of this code. > >> Correct. In accord with the charter, a requirements gathering > effort > >>for > >> potential notary-related work was conducted. > > From who - the engineers working on the protocol??? - do any of them > >have legal backgrounds which would be competent to advise here? > Will any > >of their sponsors take legal culpability for those parties > actions? You > >see my point? > > > >Its time for accountability here in the IETF to be real. > >> The results were reviewed by > >> the working group and work on notary-related standards was > suspended at > >> IETF 65 due to lack of interest in pursuing the topic. > > > >Which means that the terms and any reference to the concept of "Legal > >Document Control" per the apostles practices have to be cleansed from > >these works. i.e. someone with a redline needs to cut out all > >references to Notary anything. That said, it means simply that > this WG > >isnt done and that until those issues are completed, that NONE of the > >works can be finalized... or that they can and must all be pulled - > >since the IETF itself becomes a party to the fraud of misrepresenting > >its IP's as 'replacing legal roles' in the Human population. > > > >The IETF has never made a legal statement about any of its protocols > >before LTANS, but I think that by using the Legal Term "NOTARY" > in both > >the WG's title and its operating practices, it opens the IETF to this > >review. > > > >t. > > > > > > > >-- > >Todd S. Glassey > >This is from my personal email account and any materials from this > >account come with personal disclaimers. > > > >Further I OPT OUT of any and all commercial emailings. > > > > > _______________________________________________ > ltans mailing list > ltans@ietf.org > https://www.ietf.org/mailman/listinfo/ltans > > > > > -- > Website: http://hallambaker.com/ > -- Todd S. Glassey This is from my personal email account and any materials from this account come with personal disclaimers. Further I OPT OUT of any and all commercial emailings. --------------040600020703000806070807 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 7/20/2011 9:48 AM, Phillip Hallam-Baker wrote:
Exactly, a WG should do something right or not at all. In this case they choose not at all. That is fine with me.
The problem is they didnt remove the SCOPE STATEMENT from the WG Name and so now whenever a search is done for those documents they are tied to the term NOTARIAL even though they have nothing to do with it...

Todd

Todd seems to be giving some pretty good reasons to not do notary.


What I am interested in is probably a little speculative. I would like to have a form of data repository that we could establish some pretty good expectations of it surviving for a very long time and for the integrity of the data within it to be witnessed by a sufficiently large set of witnesses that forgery is implausible.



On Wed, Jul 20, 2011 at 12:32 PM, Carl Wallace <carl@redhoundsoftware.com> wrote:
The good news is that none of the 5 completed specs address notary-related
concepts.  Each spec addresses fairly narrow concepts consistent with the
backgrounds of the volunteers contributing the work.  While it may be
unfortunate that the term notary appears in the working group name, the
notary concept was from the inception of the working group considered to
be a topic area that would not necessarily result in new standards.

On 7/20/11 12:10 PM, "todd glassey" <tglassey@earthlink.net> wrote:

>On 7/20/2011 8:12 AM, Carl Wallace wrote:
>> On 7/20/11 10:49 AM, "todd glassey"<tglassey@earthlink.net>  wrote:
>>
>>> On 7/19/2011 6:28 PM, IESG Secretary wrote:
>>>> The Long-Term Archive and Notary Services (ltans) working group in the
>>>> Security Area has concluded. The IESG contact persons are Sean Turner
>>>> and Stephen Farrell.
>>> So there is actually no Notary's process in any of this code.
>> Correct.  In accord with the charter, a requirements gathering effort
>>for
>> potential notary-related work was conducted.
> From who - the engineers working on the protocol??? - do any of them
>have legal backgrounds which would be competent to advise here? Will any
>of their sponsors take legal culpability for those parties actions?  You
>see my point?
>
>Its time for accountability here in the IETF to be real.
>> The results were reviewed by
>> the working group and work on notary-related standards was suspended at
>> IETF 65 due to lack of interest in pursuing the topic.
>
>Which means that the terms and any reference to the concept of "Legal
>Document Control" per the apostles practices have to be cleansed from
>these works.  i.e. someone with a redline needs to cut out all
>references to Notary anything. That said, it means simply that this WG
>isnt done and that until those issues are completed, that NONE of the
>works can be finalized... or that they can and must all be pulled -
>since the IETF itself becomes a party to the fraud of misrepresenting
>its IP's as 'replacing legal roles' in the Human population.
>
>The IETF has never made a legal statement about any of its protocols
>before LTANS, but I think that by using the Legal Term "NOTARY" in both
>the WG's title and its operating practices, it opens the IETF to this
>review.
>
>t.
>
>
>
>--
>Todd S. Glassey
>This is from my personal email account and any materials from this
>account come with personal disclaimers.
>
>Further I OPT OUT of any and all commercial emailings.
>


_______________________________________________
ltans mailing list
ltans@ietf.org
https://www.ietf.org/mailman/listinfo/ltans



--
Website: http://hallambaker.com/



-- 
Todd S. Glassey
This is from my personal email account and any materials from this account come with personal disclaimers. 

Further I OPT OUT of any and all commercial emailings.
--------------040600020703000806070807-- From tobias.gondrom@gondrom.org Sat Jul 23 06:33:24 2011 Return-Path: X-Original-To: ltans@ietfa.amsl.com Delivered-To: ltans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 070E521F8751 for ; Sat, 23 Jul 2011 06:33:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -95.362 X-Spam-Level: X-Spam-Status: No, score=-95.362 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_IPADDR=2.426, HELO_EQ_DE=0.35, RDNS_DYNAMIC=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NMnPfdjQHETx for ; Sat, 23 Jul 2011 06:33:23 -0700 (PDT) Received: from lvps83-169-7-107.dedicated.hosteurope.de (lvps83-169-7-107.dedicated.hosteurope.de [83.169.7.107]) by ietfa.amsl.com (Postfix) with ESMTP id 68D7121F874F for ; Sat, 23 Jul 2011 06:33:22 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=gondrom.org; b=SosK4HjJoJOg+wDDf5hfchz+jdoLAK0stCyHy6fPQLPqZC8Y5Xxb3ldlbRQCcEJwYQXHqry4A6yW6PUQCHrSEXV113OidXweomcELfFaqDTUq2WGe/7aCoXDBe2zhZbL; h=Received:Received:Message-ID:Date:From:User-Agent:MIME-Version:To:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding; Received: (qmail 11625 invoked from network); 23 Jul 2011 15:32:26 +0200 Received: from unknown (HELO ?172.17.9.73?) (207.134.107.2) by lvps83-169-7-107.dedicated.hosteurope.de with (DHE-RSA-AES256-SHA encrypted) SMTP; 23 Jul 2011 15:32:26 +0200 Message-ID: <4E2ACD6C.3080906@gondrom.org> Date: Sat, 23 Jul 2011 14:32:28 +0100 From: Tobias Gondrom User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:5.0) Gecko/20110627 Thunderbird/5.0 MIME-Version: 1.0 To: ltans@ietf.org References: <4E272671.4070105@earthlink.net> In-Reply-To: <4E272671.4070105@earthlink.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [ltans] WG Action: Conclusion of Long-Term Archive and Notary Services (ltans) X-BeenThere: ltans@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: LTANS Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Jul 2011 13:33:24 -0000 Todd, thank you for your input. The working group name and charter do not hold legal implications and the word "notary" in technical terms is no more "magic" than any other word. The WG tried to identify notary specific requirements and possible solutions, but as Carl explained we discontinued the notary path due to missing input on the requirements document up to IETF65 (and btw. that included all sources: neither technical nor legal experts did participate sufficiently to continue with that). There is no need to wash the word "notary" from the charter or WG name, because the charter still documents that the WG aspired and tried to address issues in this realm, though unsuccessfully in this case. Please note, that this is not bijective, i.e. although all work of a WG must be included in the charter, but not everything lined out in the charter and worked on in the WG must result in a RFC. Kind regards, Tobias Ps.: and on a personal note: though the WG did not address notary requirements in specific, I would not be surprised to see Timestamps and ERS, XMLERS and ers-scvp or dssc be useful and valuable supporting elements in systems deployed in notary offices in the future or even today. On 20/07/11 20:03, todd glassey wrote: > On 7/20/2011 9:32 AM, Carl Wallace wrote: >> The good news is that none of the 5 completed specs address >> notary-related >> concepts. Each spec addresses fairly narrow concepts consistent with >> the >> backgrounds of the volunteers contributing the work. > Yes as a solution which is represented through the name and charter of > the WG to have implications or use as a notarial resource... i.e. that > they are formally a part of a Notarial Solution which they are not. If > there is no assertion to constrain Notarial splendor in this code or > its process uses, then the N word needs to be washed from everything- > including anything that would through search engines allow an idiot > not trained in the art to come to the belief that this code cannot be > used in its current form for notarial anything... >> While it may be >> unfortunate that the term notary appears in the working group name, the >> notary concept was from the inception of the working group considered to >> be a topic area that would not necessarily result in new standards. > > The problem comes this creates comes not from the IETF actions but > from those which are from relying parties. The title representing that > this WG was chartered and produced work which is constrained under > that magic N word is still binding. The issue is the use of a term of > art which has legal implications and the intentional vagueness so that > people will interpret or subliminally equate this with Notarial > Apostilles which it simple isn't. > > I think the effort and practice was excellent for a very specific set > of very limited uses, and that the protocol and its defined practice > components like most other IETF works lacks any use-specification for > the intent of the developers in how this protocol should be used > specifically. This is a very common game played in the IETF by techies > who want to build the biggest dick they possibly can swing in public > and bluntly its pretty offensive. > > > > Look, you may think this is a nothing issue, but as a contributor you > are contained by it and the use of it in administering this WG... > > Its all about transparency and its time the IETF got a serious dose of > sunshine... > > Todd > >> On 7/20/11 12:10 PM, "todd glassey" wrote: >> >>> On 7/20/2011 8:12 AM, Carl Wallace wrote: >>>> On 7/20/11 10:49 AM, "todd glassey" wrote: >>>> >>>>> On 7/19/2011 6:28 PM, IESG Secretary wrote: >>>>>> The Long-Term Archive and Notary Services (ltans) working group >>>>>> in the >>>>>> Security Area has concluded. The IESG contact persons are Sean >>>>>> Turner >>>>>> and Stephen Farrell. >>>>> So there is actually no Notary's process in any of this code. >>>> Correct. In accord with the charter, a requirements gathering effort >>>> for >>>> potential notary-related work was conducted. >>> From who - the engineers working on the protocol??? - do any of them >>> have legal backgrounds which would be competent to advise here? Will >>> any >>> of their sponsors take legal culpability for those parties actions? >>> You >>> see my point? >>> >>> Its time for accountability here in the IETF to be real. >>>> The results were reviewed by >>>> the working group and work on notary-related standards was >>>> suspended at >>>> IETF 65 due to lack of interest in pursuing the topic. >>> Which means that the terms and any reference to the concept of "Legal >>> Document Control" per the apostles practices have to be cleansed from >>> these works. i.e. someone with a redline needs to cut out all >>> references to Notary anything. That said, it means simply that this WG >>> isnt done and that until those issues are completed, that NONE of the >>> works can be finalized... or that they can and must all be pulled - >>> since the IETF itself becomes a party to the fraud of misrepresenting >>> its IP's as 'replacing legal roles' in the Human population. >>> >>> The IETF has never made a legal statement about any of its protocols >>> before LTANS, but I think that by using the Legal Term "NOTARY" in both >>> the WG's title and its operating practices, it opens the IETF to this >>> review. >>> >>> t. >>> >>> >>> >>> -- >>> Todd S. Glassey >>> This is from my personal email account and any materials from this >>> account come with personal disclaimers. >>> >>> Further I OPT OUT of any and all commercial emailings. >>> >> >> > >