Re: [ltans] WG Action: Conclusion of Long-Term Archive and Notary Services (ltans)

Tobias Gondrom <> Sat, 23 July 2011 13:33 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 070E521F8751 for <>; Sat, 23 Jul 2011 06:33:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -95.362
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id NMnPfdjQHETx for <>; Sat, 23 Jul 2011 06:33:23 -0700 (PDT)
Received: from ( []) by (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;; 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 ? ( by with (DHE-RSA-AES256-SHA encrypted) SMTP; 23 Jul 2011 15:32:26 +0200
Message-ID: <>
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
References: <> <>
In-Reply-To: <>
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-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


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