Subject: RE: Use of "TAA" acronym (was Comments on LTANS documents)

From: Peter Sylvester <[email-masked]>
Date: Sat, 31 Jul 2004 15:51:35 +0200 (MEST)

> I hope we do not remove the "T" or "A" since "TA" is Trust Anchor" and "AA"
> is "Attribute Authority"
> 

Waht about replacing Authority with Service.

Trust(ed/worthy) Archive Service = TAS , in French = heap.

---

From: "Carl Wallace" <[email-masked]>
Date: Sat, 31 Jul 2004 10:11:33 -0400

I prefer your Secure Archive Service suggestion.   Maybe TAA or TAS could
represent a specific type of SAS that provides trusted key material.  This
would give terms that somewhat mirror the types of trust we have discussed
investing in these services:

	- trusted time source = TSA
	- trusted key material source = TAA
	- secure preservation = SAS

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Peter Sylvester
> Sent: Saturday, July 31, 2004 9:52 AM
> To: [email-masked]; [email-masked]
> Subject: RE: Use of "TAA" acronym (was Comments on LTANS documents)
> 
>

---

From: Larry Masinter <[email-masked]>
Date: Sat, 31 Jul 2004 11:23:15 -0700

I think I wasn't clear about my opinion on this subject,
so, for what it is worth:

(a) I think choices of wording in a document should be
left up to the editor; the working group can make suggestions
and complain when the meaning is unclear or misleading, but
in the end, it is an editorial function. Usually, word choices
can't be made alone, there are many different terms in
the document, we shouldn't spend a lot of working group
time making suggestions about what they should be.

(b) THAT SAID, personally, I prefer to avoid acronyms unless
they're really necessary. I haven't seen the necessity of
having a TAA or an SAS or a TS or whatever, when we can
write it out,

  "Archive Service" and "Notary Service"

For that matter, I prefer to try to use neutral terms
"Archive Service", and then note that it would be good
if the Archive Service were trusted, than to add the description
to the label and then later on try to provide procedures
for deciding whether the Archive Service we're talking to
can be (or can't be) trusted.

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

---

From: Jeff Williams <[email-masked]>
Date: Sat, 31 Jul 2004 19:10:20 -0700

Larry and all,

  I like acronyms for good purposes as long as there is a
dictionary for describing them as they apply to the IETF or
whom/whatever entity uses them.  It may be time for the
IETF to seriously building such a dictionary for IETF
acronyms or acronyms use by the IETF?

> can be (or can't be) trusted.

Regards,

--
Jeffrey A. Williams
Spokesman for INEGroup LLA. - (Over 134k members/stakeholders strong!)
"Be precise in the use of words and expect precision from others" -
    Pierre Abelard

"If the probability be called P; the injury, L; and the burden, B;
liability depends upon whether B is less than L multiplied by
P: i.e., whether B is less than PL."
United States v. Carroll Towing  (159 F.2d 169 [2d Cir. 1947]
===============================================================
Updated 1/26/04
CSO/DIR. Internet Network Eng. SR. Eng. Network data security
IDNS. div. of Information Network Eng.  INEG. INC.
E-Mail [email-masked]
 Registered Email addr with the USPS
Contact Number: 214-244-4827

Date: Sat, 31 Jul 2004 19:10:20 -0700
From: Jeff Williams <[email-masked]>
Organization: INEGroup Spokesman
To: Larry Masinter <[email-masked]>
CC: [email-masked]
Subject: Re: Use of "TAA" acronym (was Comments on LTANS documents)
Sender: [email-masked]

Larry and all,

  I like acronyms for good purposes as long as there is a
dictionary for describing them as they apply to the IETF or
whom/whatever entity uses them.  It may be time for the
IETF to seriously building such a dictionary for IETF
acronyms or acronyms use by the IETF?

> can be (or can't be) trusted.

Regards,

--
Jeffrey A. Williams
Spokesman for INEGroup LLA. - (Over 134k members/stakeholders strong!)
"Be precise in the use of words and expect precision from others" -
    Pierre Abelard

"If the probability be called P; the injury, L; and the burden, B;
liability depends upon whether B is less than L multiplied by
P: i.e., whether B is less than PL."
United States v. Carroll Towing  (159 F.2d 169 [2d Cir. 1947]
===============================================================
Updated 1/26/04
CSO/DIR. Internet Network Eng. SR. Eng. Network data security
IDNS. div. of Information Network Eng.  INEG. INC.
E-Mail [email-masked]
 Registered Email addr with the USPS
Contact Number: 214-244-4827

Date: Sat, 31 Jul 2004 19:05:05 -0700
From: Jeff Williams <[email-masked]>
Organization: INEGroup Spokesman
To: Larry Masinter <[email-masked]>
CC: "'IETF LTANS'" <[email-masked]>
Subject: Re: Use of RFC 2119 terms in requirements docs (was RE: Comments on LTANS documents)
Sender: [email-masked]

Larry and all,

Larry Masinter wrote:

> (assuming everyone is on the ltans mailing list and doesn't
>  want to get two copies)
>
> Jeff,
>
> I can't tell, from your message, whether you are in favor or opposed
> to the use of RFC 2119 keywords in our document.

  I am FOR them if, and only if, the meanings of them are understood and
defined clearly, which in RFC 2119 they are not from my past experiences,
which I outlined in my previous post on this thread...

>
>
> In the case of these particular documents, I wonder a little
> about their positioning.

  Agreed.

> It would seem that the business of
> the IETF isn't so much to define the functional characteristics
> of a long-term archive or a notary service 'must be', but rather
> to define an Internet protocol for accessing such service

  Also agreed here but I think we all must understand and be
cognizant of the fact that how notary service is accessed via
any protocol is directly linked to the service operation itself...
Note: I hope I am not being so brief here as to be misunderstood
or misconstrued?

>
>
> >From that point of view, it's important to define what a
> long-term archive service does, what it's important characteristics
> are, and to define what a notary service might do, so that
> we can then define a standard protocol for accessing those
> services.
>
> But there's no point in defining what an archive service MUST
> do, except where it comes to its network interface. We can hardly
> mandate, oh, putting the service in a physically secure location,
> at least in the IETF. Perhaps if you're intending to purchase
> an archive service and writing an RFP, you'd want to use these
> kinds of terms, because you'll be judging compliance of your
> purchase against this.

Yes understood.

>
>
> The charter says:
>
> # The objective of the LTANS working group is to define requirements, data
> # structures and protocols for the secure usage of the necessary archive
> # and notary services.

  Right.

>
>
> and let me emphasize "THE SECURE USAGE OF".  Some of the 'requirements'
> in these documents seem to be requirements on the services themselves,
> and not on the protocol for accessing them.

  Yes "Some"!

>
>
> For example, just to take the first MUST in
> draft-ietf-ltans-notareqs-00.txt
>
> #  The notary service has to record private transactions, e.g.
> #  transactions of ownership. Additionally to the recording it MUST
> #  be able to guarantee and provide documentation that all necessary
> #  information has been provided to all involved parties.
>
> This 'MUST' is not a protocol requirement. In many circumstances,
> it's not even something that is possible to evaluate. I don't
> think we will be in the business of judging the mechanisms by
> which operations that function as a 'notary service' have realistic
> means of guaranteeing what they say they guarantee.

  Ok also understood here as well...  Nicely put as well..

>
>
> If there's a protocol requirement, it's that the protocol needs
> some way of COMMUNICATING the notary service's statement of
> guarantee. A guarantee is never a 100% guarantee anyway, there
> are usually conditions and circumstances. Should the protocol
> allow for those, or are they communicated out of band? I think
> that's the design question before us.

IMHO the protocol should provide for these conditions and circumstances
as they are known today and than reviewed as part of the continuing
development
of the protocol.  I recognize of course that this makes designing the protocol

very much more difficult and complex, but we don't live or operate in a
simple world either, hence that being a real consideration is why I have this
opinion.

>
>
> On the other hand, to pick another (not upper case) 'must' from
> draft-ietf-ltans-reqs-01.txt,
>
> #   Submitters must be able to specify an archivation period.
>
> It's not clear that this is a reasonable requirement to be
> 'MUST', since it doesn't say what are reasonable
> ranges, or whether a service must support all ranges, or
> is free to ignore the archivation period.

  Also agreed and in part why I have trouble in how these "Terms"
as used and/or potentially interpreted...  Therefore a need to define
them as they are intended or ARE used is necessary IMHO...

> Is it possible
> to have a long term archive service which doesn't support
> deletion, for which all records are kept 'forever'?

  Yes, why not..  Whether or not keeping these records forever
is a wise or good idea is another matter that IMHO is outside the
scope really of the protocol design...

> > From: Jeff Williams [mailto:[email-masked]]
> > Sent: Saturday, July 31, 2004 1:41 AM
> > To: Larry Masinter
> > Cc: 'Denis Pinkas'; 'IETF LTANS'; [email-masked]
> > Subject: Re: Use of RFC 2119 terms in requirements docs (was
> > RE: Comments on LTANS documents)
> >
> > Larry and all,
> >
> >   The use of certain terms and what the really mean as opposed to what
> > they are considered amongst IETF/IAB self selected "Officials" is
> > often times jux opposed as indicated in RFC 2119 as you rightly
> > point out indirectly.  Yet these debates/discussions have also been
> > previously discussed hotly debated over two years ago on the
> > "poised" IEFT forum by a number of active participant, including
> > myself.
> >
> > Larry Masinter wrote:
> >
> > > Denis Pinkas wrote:
> > >
> > > # 1. Since the document is a requirements document, it should use a
> > > # terminology in accordance with RFC 2119 and use the
> > following key words:
> > > # "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
> > "SHOULD", "SHOULD
> > > # NOT", "RECOMMENDED", "MAY", and "OPTIONAL".
> > >
> > > There's been considerable discussion in the 'newtrk' group
> > > about the use of RFC 2119 terms for requirements documents.
> > > See  http://darkwing.uoregon.edu/~llynch/newtrk/msg00322.html
> > > and the following discussion.
> > >
> > > Personally, I'm uncomfortable with the use of 2119 in requirements
> > > documents, and have worked to avoid it in more recent requirements
> > > documents I've worked on.  It doesn't make the document
> > > clearer, and the choices are usually fairly arbitrary.
> > >
> > > Larry
> > > --
> > Regards,
> > Jeffrey A. Williams
> > Spokesman for INEGroup LLA. - (Over 134k members/stakeholders strong!)
> > "Be precise in the use of words and expect precision from others" -
> >     Pierre Abelard
> >
> > "If the probability be called P; the injury, L; and the burden, B;
> > liability depends upon whether B is less than L multiplied by
> > P: i.e., whether B is less than PL."
> > United States v. Carroll Towing  (159 F.2d 169 [2d Cir. 1947]
> > ===============================================================
> > Updated 1/26/04
> > CSO/DIR. Internet Network Eng. SR. Eng. Network data security
> > IDNS. div. of Information Network Eng.  INEG. INC.
> > E-Mail [email-masked]
> >  Registered Email addr with the USPS
> > Contact Number: 214-244-4827
> >
> >

Regards,

--
Jeffrey A. Williams
Spokesman for INEGroup LLA. - (Over 134k members/stakeholders strong!)
"Be precise in the use of words and expect precision from others" -
    Pierre Abelard

"If the probability be called P; the injury, L; and the burden, B;
liability depends upon whether B is less than L multiplied by
P: i.e., whether B is less than PL."
United States v. Carroll Towing  (159 F.2d 169 [2d Cir. 1947]
===============================================================
Updated 1/26/04
CSO/DIR. Internet Network Eng. SR. Eng. Network data security
IDNS. div. of Information Network Eng.  INEG. INC.
E-Mail [email-masked]
 Registered Email addr with the USPS
Contact Number: 214-244-4827

Date: Sat, 31 Jul 2004 11:23:15 -0700
From: Larry Masinter <[email-masked]>
Subject: RE: Use of "TAA" acronym (was Comments on LTANS documents)
To: [email-masked]
Sender: [email-masked]

Larry

Date: Sat, 31 Jul 2004 11:15:10 -0700
From: Larry Masinter <[email-masked]>
Subject: RE: Use of RFC 2119 terms in requirements docs (was RE: Comments on LTANS documents)
To: "'IETF LTANS'" <[email-masked]>
Sender: [email-masked]

(assuming everyone is on the ltans mailing list and doesn't
 want to get two copies)

Jeff,

I can't tell, from your message, whether you are in favor or opposed
to the use of RFC 2119 keywords in our document.

In the case of these particular documents, I wonder a little
about their positioning. It would seem that the business of
the IETF isn't so much to define the functional characteristics
of a long-term archive or a notary service 'must be', but rather
to define an Internet protocol for accessing such services.

>From that point of view, it's important to define what a
long-term archive service does, what it's important characteristics
are, and to define what a notary service might do, so that
we can then define a standard protocol for accessing those
services.

But there's no point in defining what an archive service MUST
do, except where it comes to its network interface. We can hardly
mandate, oh, putting the service in a physically secure location,
at least in the IETF. Perhaps if you're intending to purchase
an archive service and writing an RFP, you'd want to use these
kinds of terms, because you'll be judging compliance of your
purchase against this.

The charter says:

# The objective of the LTANS working group is to define requirements, data
# structures and protocols for the secure usage of the necessary archive
# and notary services.

and let me emphasize "THE SECURE USAGE OF".  Some of the 'requirements'
in these documents seem to be requirements on the services themselves,
and not on the protocol for accessing them.

For example, just to take the first MUST in 
draft-ietf-ltans-notareqs-00.txt

#  The notary service has to record private transactions, e.g. 
#  transactions of ownership. Additionally to the recording it MUST 
#  be able to guarantee and provide documentation that all necessary 
#  information has been provided to all involved parties. 

This 'MUST' is not a protocol requirement. In many circumstances,
it's not even something that is possible to evaluate. I don't
think we will be in the business of judging the mechanisms by
which operations that function as a 'notary service' have realistic
means of guaranteeing what they say they guarantee.

If there's a protocol requirement, it's that the protocol needs
some way of COMMUNICATING the notary service's statement of
guarantee. A guarantee is never a 100% guarantee anyway, there
are usually conditions and circumstances. Should the protocol
allow for those, or are they communicated out of band? I think
that's the design question before us.

On the other hand, to pick another (not upper case) 'must' from
draft-ietf-ltans-reqs-01.txt,

#   Submitters must be able to specify an archivation period.

It's not clear that this is a reasonable requirement to be
'MUST', since it doesn't say what are reasonable
ranges, or whether a service must support all ranges, or
is free to ignore the archivation period. Is it possible
to have a long term archive service which doesn't support
deletion, for which all records are kept 'forever'?

Larry

Larry

> From: Jeff Williams [mailto:[email-masked]] 
> Sent: Saturday, July 31, 2004 1:41 AM
> To: Larry Masinter
> Cc: 'Denis Pinkas'; 'IETF LTANS'; [email-masked]
> Subject: Re: Use of RFC 2119 terms in requirements docs (was 
> RE: Comments on LTANS documents)
> 
> Larry and all,
> 
>   The use of certain terms and what the really mean as opposed to what
> they are considered amongst IETF/IAB self selected "Officials" is
> often times jux opposed as indicated in RFC 2119 as you rightly
> point out indirectly.  Yet these debates/discussions have also been
> previously discussed hotly debated over two years ago on the
> "poised" IEFT forum by a number of active participant, including
> myself.
> 
> Larry Masinter wrote:
> 
> > Denis Pinkas wrote:
> >
> > # 1. Since the document is a requirements document, it should use a
> > # terminology in accordance with RFC 2119 and use the 
> following key words:
> > # "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 
> "SHOULD", "SHOULD
> > # NOT", "RECOMMENDED", "MAY", and "OPTIONAL".
> >
> > There's been considerable discussion in the 'newtrk' group
> > about the use of RFC 2119 terms for requirements documents.
> > See  http://darkwing.uoregon.edu/~llynch/newtrk/msg00322.html
> > and the following discussion.
> >
> > Personally, I'm uncomfortable with the use of 2119 in requirements
> > documents, and have worked to avoid it in more recent requirements
> > documents I've worked on.  It doesn't make the document
> > clearer, and the choices are usually fairly arbitrary.
> >
> > Larry
> > --
> Regards,
> Jeffrey A. Williams
> Spokesman for INEGroup LLA. - (Over 134k members/stakeholders strong!)
> "Be precise in the use of words and expect precision from others" -
>     Pierre Abelard
> 
> "If the probability be called P; the injury, L; and the burden, B;
> liability depends upon whether B is less than L multiplied by
> P: i.e., whether B is less than PL."
> United States v. Carroll Towing  (159 F.2d 169 [2d Cir. 1947]
> ===============================================================
> Updated 1/26/04
> CSO/DIR. Internet Network Eng. SR. Eng. Network data security
> IDNS. div. of Information Network Eng.  INEG. INC.
> E-Mail [email-masked]
>  Registered Email addr with the USPS
> Contact Number: 214-244-4827
> 
> 

From: "Carl Wallace" <[email-masked]>
To: "'Peter Sylvester'" <[email-masked]>, <[email-masked]>, <[email-masked]>
Subject: RE: Use of "TAA" acronym (was Comments on LTANS documents)
Date: Sat, 31 Jul 2004 10:11:33 -0400
Sender: [email-masked]

> Trust(ed/worthy) Archive Service = TAS , in French = heap. 

Date: Sat, 31 Jul 2004 15:51:35 +0200 (MEST)
From: Peter Sylvester <[email-masked]>
To: [email-masked], [email-masked]
Subject: RE: Use of "TAA" acronym (was Comments on LTANS documents)
Sender: [email-masked]

From: "Santosh Chokhani" <[email-masked]>
To: "'IETF LTANS'" <[email-masked]>
Subject: RE: Use of "TAA" acronym (was Comments on LTANS documents)
Date: Sat, 31 Jul 2004 08:19:32 -0400
Importance: Normal
Sender: [email-masked]

Larry:

I agree with you.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Larry Masinter
Sent: Saturday, July 31, 2004 1:57 AM
To: 'Denis Pinkas'; 'IETF LTANS'
Subject: Use of "TAA" acronym (was Comments on LTANS documents)

(I thought these topics might deserve separate threads, so
I am sending separate emails with different subject lines.)

> 2. The document is using the word TAA. the T is for "Trusted". As soon 
> as
> this word "trust" is being used, then it is necessary to say *WHO trusts 
> SOMEBODY for WHAT*. The acronym "TAA" should not be used, "Arch-A" could
be 
> used instead, since AA already means Attribute Authority.

The current definition is quite short, it says:

      Trusted Archive Authority (TAA): A service that is responsible for
      preserving data for long periods.

I think the 'trust' here is that the service does what it is responsible
for: it preserves data for long periods. It doesn't lose the data, and
doesn't allow the data to change accidentally or maliciously.

As for WHO is doing the trusting, well: everyone. In fact, you might argue
that 'authority' might be redundtant with 'trusted by everyone', at least
for the data that the authority is an authority for.

If you're going to insist on precision about trust, you need *WHO trusts
WHOM for WHAT, WHEN*; i.e., you also need the element of time.  What makes a
'TAA' unusual is that the requirement for trustworthiness lasts for long
periods, as well.

Larry

Date: Sat, 31 Jul 2004 12:43:23 +0200 (MEST)
From: Peter Sylvester <[email-masked]>
To: [email-masked], [email-masked]
Subject: Roles and actors was:  Comments on LTANS documents
Sender: [email-masked]

Thanks for the comments. Very useful. 

I think we need to clarify some of the possible roles and actors
or mention some important use cases. 

I had started a reply some time ago, so I am a little bit out
of sync with the additional remarks from Larry and Jeff.
>
> >>As far as the WHO is concerned, there are:
> >>
> >>    1) the person or the application who did the deposit,
> >>
> >>    2) the persons or the applications allowed to retrieve the data
> >>       (not necessarily the same as 1))
> >>
> >>    3) the persons or the applications wishing to make sure that
> >>       some data originates from a given Archiving Unit (Arch-Unit)
> >>       under the responsibility of a given Archiving Authority
> >>       (Arch-A) and has been stored by it at a given point of time.
> > 
> > 
> > Could you write this a little bit simpler for me, I am not sure 
> > whether I understand the second line of point 3. Is this a relying party
> > which 1) has to convince that some required archiving had been done?  
> 
> The players are similiar to the players in the signature game:
> 1 someone signs a document
> 2 someone receives the signed document
> 3 someone validates the signature of the document
> 
> Answering your question:
> No, the relying party must not necessarily convinced by 1, and it may be
> not sufficient to convince 3 that the archiving was done.
> The target may be the fact of archiving but also the content archived or
> the time of archiving.

To me the situation is a little more complex as with a signed document
since you have data, an attestation from an archiver, and the possiblities
or need to verify some data against the attestation, or to retrieve them.

> > I think there is some overlap with the existing players mentioned
> > as Arbitrator, Submitter, Retriever, Originator. And there may be
> > others, judge, software provider, operator, configurator, system maintainer, ...
> 
> I guess that the three roles Denis mentioned are a good starting point.
> Do you think that there are other important roles?

The reqs already list different roles. 

To what degree does a very detailed list of roles/actors matter
to definition of the service? At least, it is good for the common
understanding of the problem space. 

A rough idea of the service:

Someone submits and eventually(=after a short time) gets some attestation
that convinces (not only the submitter) that some data have been stored
and can be retrieved, and that destruction will be difficult and not undetected,
except in nuc war where we don't really care at all anymore about our
little security problems anyway.

Peter

Date: Sat, 31 Jul 2004 12:29:42 +0200 (MEST)
From: Peter Sylvester <[email-masked]>
To: [email-masked], [email-masked], [email-masked]
Subject: Re: Use of "TAA" acronym (was Comments on LTANS documents)
Sender: [email-masked]

I had already prepared some text concerning this point,
it is a little out of sync with jeff and larry's comment,
but anyway:

> >>As far as the WHAT is concerned, each of the previous players is trusting 
> >>the Arch-A for a different purpose which should be detailed.
> > 
> > 
> > I think that all players want that the archival service stores the data 
> > correctly and can make it available to whoever is authorized, or do I 
> > miss something? Trust is always a problematic word.  
> 
> The word "correctly" is problematic as well. S oit is necessary to have
> a defined unambigous set of rules, conditions that the verification
> gives always the some result.

Agreed. But where is the relationship to 'TRUST' ? Everybody trusts the
archive service or/and a notary to provide a service that follows a 
defined set of conditions. the submitter trusts that the data will be
stored and can be retrieved, a retriever that the data retrieved are the one 
stored by someone, i.e., the same. this does not mean that all players
always and all the time have the same level of trust vis-a-vis the
service provider. 

Or, one somehow has to compensate for the potential degradation in time
by some techniques that the service can use to demonstrate his inability
to create false positives, to deny having archived something, and to use
auditing to 'control' the service, combine with redundancy not operated
by the same people etc. 

We could name these beasts SAS "Secure Archive Service" .

Peter

Date: Sat, 31 Jul 2004 01:48:48 -0700
From: Jeff Williams <[email-masked]>
Organization: INEGroup Spokesman
To: Larry Masinter <[email-masked]>
CC: "'Denis Pinkas'" <[email-masked]>, "'IETF LTANS'" <[email-masked]>
Subject: Re: Use of "TAA" acronym (was Comments on LTANS documents)
Sender: [email-masked]

Larry and all,

  Again a very good point brought out yet again as trust or whom, when
for what as it accurately equates to "TAA" is well yet again discussed
here.  More and more such "Trust" is given to entities that are not
broadly trusted or who's personnel are not trusted for some things
as they are not adequately broadly trusted for a specific area or
responsibility, and/or again "Selected" by less than well known
other individuals for such levels or areas of trust.

Larry Masinter wrote:

> (I thought these topics might deserve separate threads, so
> I am sending separate emails with different subject lines.)
>
> > 2. The document is using the word TAA. the T is for "Trusted". As soon as
> > this word "trust" is being used, then it is necessary to say *WHO trusts
> > SOMEBODY for WHAT*. The acronym "TAA" should not be used, "Arch-A" could
> be
> > used instead, since AA already means Attribute Authority.
>
> The current definition is quite short, it says:
>
>       Trusted Archive Authority (TAA): A service that is responsible for
>       preserving data for long periods.
>
> I think the 'trust' here is that the service does what it is responsible
> for: it preserves data for long periods. It doesn't lose the data, and
> doesn't allow the data to change accidentally or maliciously.
>
> As for WHO is doing the trusting, well: everyone. In fact, you might
> argue that 'authority' might be redundtant with 'trusted by everyone',
> at least for the data that the authority is an authority for.
>
> If you're going to insist on precision about trust, you need
> *WHO trusts WHOM for WHAT, WHEN*; i.e., you also need the element
> of time.  What makes a 'TAA' unusual is that the requirement
> for trustworthiness lasts for long periods, as well.
>
> Larry
> --

Regards,
--
Jeffrey A. Williams
Spokesman for INEGroup LLA. - (Over 134k members/stakeholders strong!)
"Be precise in the use of words and expect precision from others" -
    Pierre Abelard

"If the probability be called P; the injury, L; and the burden, B;
liability depends upon whether B is less than L multiplied by
P: i.e., whether B is less than PL."
United States v. Carroll Towing  (159 F.2d 169 [2d Cir. 1947]
===============================================================
Updated 1/26/04
CSO/DIR. Internet Network Eng. SR. Eng. Network data security
IDNS. div. of Information Network Eng.  INEG. INC.
E-Mail [email-masked]
 Registered Email addr with the USPS
Contact Number: 214-244-4827

Date: Sat, 31 Jul 2004 01:41:01 -0700
From: Jeff Williams <[email-masked]>
Organization: INEGroup Spokesman
To: Larry Masinter <[email-masked]>
CC: "'Denis Pinkas'" <[email-masked]>, "'IETF LTANS'" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: Use of RFC 2119 terms in requirements docs (was RE: Comments on LTANS documents)
Sender: [email-masked]

Larry and all,

  The use of certain terms and what the really mean as opposed to what
they are considered amongst IETF/IAB self selected "Officials" is
often times jux opposed as indicated in RFC 2119 as you rightly
point out indirectly.  Yet these debates/discussions have also been
previously discussed hotly debated over two years ago on the
"poised" IEFT forum by a number of active participant, including
myself.

Larry Masinter wrote:

> Denis Pinkas wrote:
>
> # 1. Since the document is a requirements document, it should use a
> # terminology in accordance with RFC 2119 and use the following key words:
> # "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD
> # NOT", "RECOMMENDED", "MAY", and "OPTIONAL".
>
> There's been considerable discussion in the 'newtrk' group
> about the use of RFC 2119 terms for requirements documents.
> See  http://darkwing.uoregon.edu/~llynch/newtrk/msg00322.html
> and the following discussion.
>
> Personally, I'm uncomfortable with the use of 2119 in requirements
> documents, and have worked to avoid it in more recent requirements
> documents I've worked on.  It doesn't make the document
> clearer, and the choices are usually fairly arbitrary.
>
> Larry
> --

Regards,

--
Jeffrey A. Williams
Spokesman for INEGroup LLA. - (Over 134k members/stakeholders strong!)
"Be precise in the use of words and expect precision from others" -
    Pierre Abelard

"If the probability be called P; the injury, L; and the burden, B;
liability depends upon whether B is less than L multiplied by
P: i.e., whether B is less than PL."
United States v. Carroll Towing  (159 F.2d 169 [2d Cir. 1947]
===============================================================
Updated 1/26/04
CSO/DIR. Internet Network Eng. SR. Eng. Network data security
IDNS. div. of Information Network Eng.  INEG. INC.
E-Mail [email-masked]
 Registered Email addr with the USPS
Contact Number: 214-244-4827

Date: Fri, 30 Jul 2004 22:56:56 -0700
From: Larry Masinter <[email-masked]>
Subject: Use of "TAA" acronym (was Comments on LTANS documents)
To: "'Denis Pinkas'" <[email-masked]>, "'IETF LTANS'" <[email-masked]>
Sender: [email-masked]

(I thought these topics might deserve separate threads, so
I am sending separate emails with different subject lines.)

> 2. The document is using the word TAA. the T is for "Trusted". As soon as 
> this word "trust" is being used, then it is necessary to say *WHO trusts 
> SOMEBODY for WHAT*. The acronym "TAA" should not be used, "Arch-A" could
be 
> used instead, since AA already means Attribute Authority.

The current definition is quite short, it says:

      Trusted Archive Authority (TAA): A service that is responsible for
      preserving data for long periods.

I think the 'trust' here is that the service does what it is responsible
for: it preserves data for long periods. It doesn't lose the data, and
doesn't allow the data to change accidentally or maliciously.

As for WHO is doing the trusting, well: everyone. In fact, you might
argue that 'authority' might be redundtant with 'trusted by everyone',
at least for the data that the authority is an authority for.

If you're going to insist on precision about trust, you need
*WHO trusts WHOM for WHAT, WHEN*; i.e., you also need the element
of time.  What makes a 'TAA' unusual is that the requirement
for trustworthiness lasts for long periods, as well.

Larry

Date: Fri, 30 Jul 2004 22:49:29 -0700
From: Larry Masinter <[email-masked]>
Subject: Use of RFC 2119 terms in requirements docs (was RE: Comments on LTANS documents)
To: "'Denis Pinkas'" <[email-masked]>
Cc: "'IETF LTANS'" <[email-masked]>
Sender: [email-masked]

Denis Pinkas wrote:

# 1. Since the document is a requirements document, it should use a 
# terminology in accordance with RFC 2119 and use the following key words: 
# "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD 
# NOT", "RECOMMENDED", "MAY", and "OPTIONAL".

There's been considerable discussion in the 'newtrk' group
about the use of RFC 2119 terms for requirements documents.
See  http://darkwing.uoregon.edu/~llynch/newtrk/msg00322.html
and the following discussion.

Personally, I'm uncomfortable with the use of 2119 in requirements
documents, and have worked to avoid it in more recent requirements
documents I've worked on.  It doesn't make the document
clearer, and the choices are usually fairly arbitrary.

Larry

Date: Fri, 30 Jul 2004 22:35:48 -0700
From: Larry Masinter <[email-masked]>
Subject: Scope of notary-requirements (was Comments on LTANS documents)
To: "'Santosh Chokhani'" <[email-masked]>
Cc: "'IETF LTANS'" <[email-masked]>
Sender: [email-masked]

 Santosh Chokhani wrote:

# My primary question on the document is that of the scope. 
# The document seems to include (possibly imply) human in
# the loop as the Notary.

#  I think the scope of IETF related work should be limited
# to Electronic Notary.  This also means dealing with electronic
# documents only.  There are lot of other non-IT related forensics
# issues involved with paper.  I wonder if IETF should deal with
# those issues.

I expect all of the discussion about notary services
is as a means of motivation, not of scope. Perhaps
this isn't clear that the introductory section is
just giving a little bit of history about what notaries
traditionally have done, and why we're looking for
electronic analogs. 

Larry

Date: Fri, 30 Jul 2004 22:22:48 +0900
From: Masaki SHIMAOKA <[email-masked]>
To: <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, [email-masked]
Subject: multi-domain PKI unofficial BoF
Cc: [email-masked]
Sender: [email-masked]

All,

# Sorry for any cross-postings.

I am going to hold a unofficial BoF for Best Current Practice (BCP) of multi-domain
PKI in the 60th IETF meeting at San Diego.

Date/Time and Room are not decided yet, but it will be held at Aug 4 or
5. If you have interest in this issue, please check your mailing list and
board at IETF reception. I will announce additional information there.

Purpose of this BoF is to make a consensus of the following:
* What is the multi-domain PKI?
* What is the problem in multi-domain PKI?
* Shall we solve this problem?

Summary:
There are many PKIs in the actual world, and they have of course
different architectures and different policies.
So when some PKIs assemble, it will bring some problems.
Assembling the PKIs is hard problem because it may require full understanding of not only PKI but LDAP and so on.
Therefore, I think that we should show some technical idea about assembling PKIs.

My opinion for this theme is described in my following personal I-D:
    http://www.jnsa.org/mpki/draft-shimaoka-multidomain-pki-04-20040730r1.txt

If we make a rough consensus, following this discussion I would like to
review my I-D with you.

Thanks,
shima

-----
Masaki SHIMAOKA

SECOM Trust.net
Tel: +81 422 91 8498 (ext.3635); Mitaka
Tel: +81 3 5775 8661 (ext.3485); Harajuku
Fax: +81 422 45 0536
e-mail: [email-masked]

Date: Wed, 28 Jul 2004 17:12:00 +0200
From: Ernst G Giessmann <[email-masked]>
To: [email-masked]
Subject: Re: Comments on LTANS documents
Sender: [email-masked]

Dear all,
I'm new on the LTANS list too.

Some remarks to Peter's reply to Denis (text shortened to save memory)

Peter Sylvester wrote:

....
>>As far as the WHO is concerned, there are:
>>
>>    1) the person or the application who did the deposit,
>>
>>    2) the persons or the applications allowed to retrieve the data
>>       (not necessarily the same as 1))
>>
>>    3) the persons or the applications wishing to make sure that
>>       some data originates from a given Archiving Unit (Arch-Unit)
>>       under the responsibility of a given Archiving Authority
>>       (Arch-A) and has been stored by it at a given point of time.
> 
> 
> Could you write this a little bit simpler for me, I am not sure 
> whether I understand the second line of point 3. Is this a relying party
> which 1) has to convince that some required archiving had been done?  

The players are similiar to the players in the signature game:
1 someone signs a document
2 someone receives the signed document
3 someone validates the signature of the document

Answering your question:
No, the relying party must not necessarily convinced by 1, and it may be
not sufficient to convince 3 that the archiving was done.
It is a person that proves that some given data was archived under given
conditions at a given time.
The target may be the fact of archiving but also the content archived or
the time of archiving.

> I think there is some overlap with the existing players mentioned
> as Arbitrator, Submitter, Retriever, Originator. And there may be
> others, judge, software provider, operator, configurator, system maintainer, ...

I guess that the three roles Denis mentioned are a good starting point.
Do you think that there are other important roles?

>>As far as the WHAT is concerned, each of the previous players is trusting 
>>the Arch-A for a different purpose which should be detailed.
> 
> 
> I think that all players want that the archival service stores the data 
> correctly and can make it available to whoever is authorized, or do I 
> miss something? Trust is always a problematic word.  

The word "correctly" is problematic as well. S oit is necessary to have
a defined unambigous set of rules, conditions that the verification
gives always the some result.

>>11. Retrieving of data should be done using information given in the "proof 
>>of deposit".
> 
> 
> 'should' ?? 
> 
> One should be able to retrieve for example 'all data
> for a particular client' without referencing all the stored items.
> And 30 years later, I may only have a vague idea.
> 
> IMO a search protocol allows to retrieve publicaly available
> 'acknowledgement', the details of this are outside scope.
> The actual retrieval must be done by such a reference.
> 
> The basic archival server is not required to
> provide a sophisticated search facility. 

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

> The need of authenticity is IMO the right term here, electronic signature
> is at best a means, unfortunately it has no final definition
When a definition is finalized?
Let us stick for a while at the formats of RFC 3126.

> What service does an electronic signature provide?
It is a rhetoric question isn't it?

An electronic signature produced in accordance with RFC 3126
provides evidence that can be processed to get confidence that some
commitment has been explicitly endorsed under a signature policy, at
a given time, by a signer under an identifier, e.g., a name or a
pseudonym, and optionally a role.

>>15. Disclosing or not the archived data to the Arch-Unit is an interesting 
>>topic. Three cases should be identified:
>>     1) the archived data is public data,
>>     2) the archived data is private data, and only a hash of it
>>        is communicated,
>>     3) the archived data is private data, and only encrypted data
>>        is communicated.
...
>>In case 3) the user who made the deposit only needs to keep a private key 
>>corresponding to the public key used to perform the encryption (which is not 
>>what the second document is saying).
> 
> No, a key to decrypt, e.g. a session key for example. 
Correct. It may be a private (asymmetric) key as well.

>>20. For the intellectual property statements, it should noted that some 
>>companies have patents about hash-tree applied to Time-Stamping. If somebody 
>>participating to this working group has or knows some patents along 
>>hash-tree applied to Time-Stamping, it would be fair that this participant 
>>informs us of any patent that would be related to the ERS document. This 
>>point should be raised to all the participants of the WG session at the San 
>>Diego meeting.
> 
> 
> I have made a list of potentially relevant patents is available to
> stimulate the discussion.
> 
>  http://ltans.edelweb.fr/patents.html
Thank you.

I wish you a sucessfull meeting in San Diego.

Regards,
Ernst.

-- 
	Ernst G Giessmann
	T-Systems GmbH ITC-Security
	Goslarer Ufer 35, D-10589 Berlin
	phone:+49-30-3497-4342 mailto:[email-masked]

Content-class: urn:content-classes:message
Subject: LTANS: agenda for San Diego
Date: Mon, 26 Jul 2004 17:57:06 +0200
Importance: high
From: "Tobias Gondrom" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>
Sender: [email-masked]

This is a multi-part message in MIME format.

------_=_NextPart_001_01C47329.346103D9
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hello,

=20

The agenda for the LTANS meeting in San Diego:

=20

Agenda for LTANS meeting:

A. Notary Requirements

1. Opening Presentation of Notary Reqs (Tobias) - 15 Min.

2. Further presentations of notary reqs/ideas.... 5 minutes each - 10 =
minutes

2.1 from Andreas Schmidt FHG (presented by Tobias)

3. Discussion about proceeding concerning notary services (Carl & =
Tobias) - 40 minutes

=20

B. long-term archive Protocol:

1. Presentation of protocol draft (Carl) - 15 Min.

2. Discussion (Carl & Tobias) - 30 Min.

=20

=20

Regards

=20

            Tobias

            Chair of LTANS

=20

__________________________________________=20
Tobias Gondrom
Senior Software Architect
PPMA, Engineering

IXOS SOFTWARE AG
Technopark 1
Bretonischer Ring 12
85630 Grasbrunn / Munich=20
Phone:  +49 (0) 89 4629-1816
Telefax:        +49 (0) 89 4629-33-1816
eMail:  mailto:[email-masked]
Internet:       http://www.ixos.com/=20

This eMail may contain confidential and/or privileged information. If =
you are not the intended recipient or have received this eMail in error, =
please notify the sender immediately and destroy this eMail. Any use, =
disclosure or distribution of the material in this eMail is strictly =
forbidden.

Diese eMail enth=E4lt vertrauliche und/oder rechtlich gesch=FCtzte =
Informationen. Wenn Sie nicht der richtige Adressat sind oder diese =
eMail irrt=FCmlich erhalten haben, informieren Sie bitte sofort den =
Absender und vernichten Sie diese eMail. Jegliche Art der Verwendung, =
Vervielf=E4ltigung oder Weitergabe ist nicht gestattet.

=20

------_=_NextPart_001_01C47329.346103D9
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

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

<head>
<meta http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<meta name=3DGenerator content=3D"Microsoft Word 11 (filtered medium)">
<o:SmartTagType =
namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"
 name=3D"City"/>
<o:SmartTagType =
namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"
 name=3D"place"/>
<!--[if !mso]>
<style>
st1\:*{behavior:url(#default#ieooui) }
</style>
<![endif]-->
<style>
<!--
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman";}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{color:purple;
	text-decoration:underline;}
p
	{mso-margin-top-alt:auto;
	margin-right:0in;
	mso-margin-bottom-alt:auto;
	margin-left:0in;
	font-size:12.0pt;
	font-family:"Times New Roman";}
span.EmailStyle17
	{mso-style-type:personal-compose;
	font-family:Arial;
	color:windowtext;}
@page Section1
	{size:8.5in 11.0in;
	margin:1.0in 1.25in 1.0in 1.25in;}
div.Section1
	{page:Section1;}
-->
</style>

</head>

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

<div class=3DSection1>

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

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

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>The agenda for the LTANS meeting in <st1:City =
w:st=3D"on"><st1:place
 w:st=3D"on">San =
Diego</st1:place></st1:City>:<o:p></o:p></span></font></p>

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

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

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

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>1. Opening Presentation of Notary Reqs (Tobias) =
&#8211; 15
Min.<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>2. Further presentations of notary reqs/ideas&#8230;. =
5
minutes each - 10 minutes<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>2.1 from Andreas Schmidt FHG (presented by =
Tobias)<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>3. Discussion about proceeding concerning notary =
services
(Carl &amp; Tobias) - 40 minutes<o:p></o:p></span></font></p>

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

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>B. long-term archive =
Protocol:<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>1. Presentation of protocol draft (Carl) - 15 =
Min.<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>2. Discussion (Carl &amp; Tobias) &#8211; 30 =
Min.<o:p></o:p></span></font></p>

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

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

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

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

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

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

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

<p><b><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial;
font-weight:bold'>__________________________________________</span></font=
></b> <br>
<b><font size=3D2 color=3Dblack face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial;color:black;font-weight:bold'>Tobias =
Gondrom</span></font></b><font
size=3D2 color=3Dblack face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial;
color:black'><br>
Senior Software Architect<br>
PPMA, Engineering<br>
</span></font><br>
<b><font size=3D2 color=3Dblack face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial;color:black;font-weight:bold'>IXOS SOFTWARE =
AG</span></font></b><font
size=3D2 color=3Dblack face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial;
color:black'><br>
Technopark 1<br>
Bretonischer Ring 12<br>
85630 Grasbrunn / <st1:place w:st=3D"on"><st1:City =
w:st=3D"on">Munich</st1:City></st1:place></span></font>
<br>
<font size=3D2 color=3Dblack face=3DArial><span =
style=3D'font-size:10.0pt;font-family:
Arial;color:black'>Phone:&nbsp; +49 (0) 89 4629-1816<br>
Telefax:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; +49 (0) 89 =
4629-33-1816<br>
eMail:&nbsp;</span></font> <font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'><a =
href=3D"mailto:[email-masked]">mailto:[email-masked]</a><=
br>
<font color=3Dblack><span =
style=3D'color:black'>Internet:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</span=
></font></span></font><u>
</u><u><font size=3D2 color=3Dblue face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial;color:blue'><a =
href=3D"http://www.ixos.com/">http://www.ixos.com/</a></span></font></u>
<o:p></o:p></p>

<p><font size=3D2 color=3Dblack face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial;color:black'>This eMail may contain confidential =
and/or
privileged information. If you are not the intended recipient or have =
received
this eMail in error, please notify the sender immediately and destroy =
this
eMail. Any use, disclosure or distribution of the material in this eMail =
is
strictly forbidden.</span></font><o:p></o:p></p>

<p><font size=3D2 face=3DArial><span lang=3DDE =
style=3D'font-size:10.0pt;font-family:
Arial'>Diese eMail enth=E4lt vertrauliche und/oder rechtlich =
gesch=FCtzte
Informationen. Wenn Sie nicht der richtige Adressat sind oder diese =
eMail
irrt=FCmlich erhalten haben, informieren Sie bitte sofort den Absender =
und
vernichten Sie diese eMail. Jegliche Art der Verwendung, =
Vervielf=E4ltigung oder
Weitergabe ist nicht gestattet.</span></font><span =
lang=3DDE><o:p></o:p></span></p>

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

</div>

</body>

</html>

------_=_NextPart_001_01C47329.346103D9--

Content-class: urn:content-classes:message
Subject: Agenda for San Diego meeting - proposals for presentations until July 25 - 22:00 ET ?
Date: Thu, 22 Jul 2004 17:57:10 +0200
Importance: high
From: "Tobias Gondrom" <[email-masked]>
To: <[email-masked]>
Cc: "todd glassey" <[email-masked]>
Sender: [email-masked]

This is a multi-part message in MIME format.

------_=_NextPart_001_01C47004.8BBFCF00
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hello,

=20

As Carl and I are setting up the agenda for San Diego please submit your =
proposals for presentations until=20

Sunday evening!=20

=20

As we see progress especially with notary services and protocol we =
currently plan to focus on these two issues.=20

So if you would like to contribute please submit your proposal with =
title, short (max. 3 lines) abstract and estimated duration.

=20

Carl and I will go through the proposals and must submit the agenda =
until July 26, 12:00 ET.

=20

Best regards

=20

            Tobias

            Chair of LTANS

=20

=20

Ps.: LTANS meeting will be August 5, 13:00-15:00  =
(http://www.ietf.org/meetings/agenda_60.txt)

=20

=20

__________________________________________=20
Tobias Gondrom
Senior Software Architect
Engineering

IXOS SOFTWARE AG
Technopark 1
Bretonischer Ring 12
85630 Grasbrunn / Munich=20
Phone:  +49 (0) 89 4629-1816
Telefax:        +49 (0) 89 4629-33-1816
eMail:  mailto:[email-masked]
Internet:       http://www.ixos.com/=20

This eMail may contain confidential and/or privileged information. If =
you are not the intended recipient or have received this eMail in error, =
please notify the sender immediately and destroy this eMail. Any use, =
disclosure or distribution of the material in this eMail is strictly =
forbidden.

Diese eMail enth=E4lt vertrauliche und/oder rechtlich gesch=FCtzte =
Informationen. Wenn Sie nicht der richtige Adressat sind oder diese =
eMail irrt=FCmlich erhalten haben, informieren Sie bitte sofort den =
Absender und vernichten Sie diese eMail. Jegliche Art der Verwendung, =
Vervielf=E4ltigung oder Weitergabe ist nicht gestattet.

=20

------_=_NextPart_001_01C47004.8BBFCF00
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

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

<head>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">

<meta name=3DGenerator content=3D"Microsoft Word 11 (filtered medium)">
<o:SmartTagType =
namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"
 name=3D"City"/>
<o:SmartTagType =
namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"
 name=3D"place"/>
<!--[if !mso]>
<style>
st1\:*{behavior:url(#default#ieooui) }
</style>
<![endif]-->
<style>
<!--
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman";}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{color:purple;
	text-decoration:underline;}
p
	{mso-margin-top-alt:auto;
	margin-right:0in;
	mso-margin-bottom-alt:auto;
	margin-left:0in;
	font-size:12.0pt;
	font-family:"Times New Roman";}
span.EmailStyle17
	{mso-style-type:personal-compose;
	font-family:Arial;
	color:windowtext;}
@page Section1
	{size:8.5in 11.0in;
	margin:1.0in 1.25in 1.0in 1.25in;}
div.Section1
	{page:Section1;}
-->
</style>

</head>

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

<div class=3DSection1>

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

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

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>As Carl and I are setting up the agenda for <st1:City =
w:st=3D"on"><st1:place
 w:st=3D"on">San Diego</st1:place></st1:City> please submit your =
proposals for
presentations until <o:p></o:p></span></font></p>

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

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

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>As we see progress especially with <b><span
style=3D'font-weight:bold'>notary services</span></b> and <b><span
style=3D'font-weight:bold'>protocol</span></b> we currently plan to =
focus on
these two issues. <o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>So if you would like to <b><span =
style=3D'font-weight:bold'>contribute</span></b>
please <b><span style=3D'font-weight:bold'>submit your =
proposal</span></b> with title,
short (max. 3 lines) abstract and estimated =
duration.<o:p></o:p></span></font></p>

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

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>Carl and I will go through the proposals and must =
submit the
agenda until July 26, 12:00 ET.<o:p></o:p></span></font></p>

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

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

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

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

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

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

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

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>Ps.: LTANS meeting will be August 5, 13:00-15:00=A0 =
(<a
href=3D"http://www.ietf.org/meetings/agenda_60.txt">http://www.ietf.org/m=
eetings/agenda_60.txt</a>)<o:p></o:p></span></font></p>

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

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

<p><b><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial;
font-weight:bold'>__________________________________________</span></font=
></b> <br>
<b><font size=3D2 color=3Dblack face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial;color:black;font-weight:bold'>Tobias =
Gondrom</span></font></b><font
size=3D2 color=3Dblack face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial;
color:black'><br>
Senior Software Architect<br>
Engineering<br>
</span></font><br>
<b><font size=3D2 color=3Dblack face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial;color:black;font-weight:bold'>IXOS SOFTWARE =
AG</span></font></b><font
size=3D2 color=3Dblack face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial;
color:black'><br>
Technopark 1<br>
Bretonischer Ring 12<br>
85630 Grasbrunn / <st1:place w:st=3D"on"><st1:City =
w:st=3D"on">Munich</st1:City></st1:place></span></font>
<br>
<font size=3D2 color=3Dblack face=3DArial><span =
style=3D'font-size:10.0pt;font-family:
Arial;color:black'>Phone:&nbsp; +49 (0) 89 4629-1816<br>
Telefax:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; +49 (0) 89 =
4629-33-1816<br>
eMail:&nbsp;</span></font> <font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'><a =
href=3D"mailto:[email-masked]">mailto:[email-masked]</a><=
br>
<font color=3Dblack><span =
style=3D'color:black'>Internet:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</span=
></font></span></font><u>
</u><u><font size=3D2 color=3Dblue face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial;color:blue'><a =
href=3D"http://www.ixos.com/">http://www.ixos.com/</a></span></font></u>
<o:p></o:p></p>

<p><font size=3D2 color=3Dblack face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial;color:black'>This eMail may contain confidential =
and/or
privileged information. If you are not the intended recipient or have =
received
this eMail in error, please notify the sender immediately and destroy =
this
eMail. Any use, disclosure or distribution of the material in this eMail =
is
strictly forbidden.</span></font><o:p></o:p></p>

<p><font size=3D2 face=3DArial><span lang=3DDE =
style=3D'font-size:10.0pt;font-family:
Arial'>Diese eMail enth=E4lt vertrauliche und/oder rechtlich =
gesch=FCtzte
Informationen. Wenn Sie nicht der richtige Adressat sind oder diese =
eMail
irrt=FCmlich erhalten haben, informieren Sie bitte sofort den Absender =
und
vernichten Sie diese eMail. Jegliche Art der Verwendung, =
Vervielf=E4ltigung oder
Weitergabe ist nicht gestattet.</span></font><span =
lang=3DDE><o:p></o:p></span></p>

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

</div>

</body>

</html>

------_=_NextPart_001_01C47004.8BBFCF00--

Date: Thu, 22 Jul 2004 16:19:17 +0200 (MEST)
From: Peter Sylvester <[email-masked]>
To: [email-masked], [email-masked]
Subject: Re: Comments on LTANS documents
Sender: [email-masked]

> Comments on LTANS documents
> 
> I have only been recently aware of the existence of the LTANS working group. 

You are pardonned. Welcome on board. 

I am not answering on behalf of the authors nor do my comments
necessarily reflect the authors' opinions.

> While I believe that work should be done along an archive service, the 
> current documents still do not provide the right presentation of the 
> problem, nor the right answers. 27 comments follow.

I think the participants of this group would like to read 
your presentation of the problem and your ideas for an answer. 

Your are probably aware of work that has been done
be various people in that area in the IETF and also outside. 
Some of the work is referenced in the ltans web server,
and people are discovering other related work regularily. 

The contributors on this list spend some time to identify
common elements in order to fold out something which is 
acceptable to some large community, otherwise it would
be 'YAS' (yet another standard). 

Well, then:

> Comments on draft-ietf-ltans-requs-01.txt
> 
> 1. Since the document is a requirements document, it should use a 
> terminology in accordance with RFC 2119 and use the following key words: 
> "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD 
> NOT", "RECOMMENDED", "MAY", and "OPTIONAL".

At the current state I see the requirements documents as an attempt
to get a common understanding of the problem to be solved, there
are examples where the right usage of such terms is difficult, at
least for non native english people, your point 16 seems to be an
example (to me). But there will certainly a next round.  

> 2. The document is using the word TAA. the T is for "Trusted". As soon as 
> this word "trust" is being used, then it is necessary to say *WHO trusts 
> SOMEBODY for WHAT*. The acronym "TAA" should not be used, "Arch-A" could be 
> used instead, since AA already means Attribute Authority.
> 
> As far as the WHO is concerned, there are:
> 
>     1) the person or the application who did the deposit,
> 
>     2) the persons or the applications allowed to retrieve the data
>        (not necessarily the same as 1))
> 
>     3) the persons or the applications wishing to make sure that
>        some data originates from a given Archiving Unit (Arch-Unit)
>        under the responsibility of a given Archiving Authority
>        (Arch-A) and has been stored by it at a given point of time.

Could you write this a little bit simpler for me, I am not sure 
whether I understand the second line of point 3. Is this a relying party
which 1) has to convince that some required archiving had been done?  

You have introduced a term Arch-unit without giving a definition.

> The difference between the above "players" should be introduced in the 
> documents.

I think there is some overlap with the existing players mentioned
as Arbitrator, Submitter, Retriever, Originator. And there may be
others, judge, software provider, operator, configurator, system maintainer, ...
 
> 
> As far as the WHAT is concerned, each of the previous players is trusting 
> the Arch-A for a different purpose which should be detailed.

I think that all players want that the archival service stores the data 
correctly and can make it available to whoever is authorized, or do I 
miss something? Trust is always a problematic word.  

> 3. When a person or an application makes deposit, it is of primary 
> importance that it gets back a "proof of deposit" from an Arch-Unit. In case 
> the deposited data would be lost, then the Arch-A would be responsible from 
> the loss.

I am not sure that we are all thinkinn about the same thing. 

There is a difference between the technical element of a 'receipt' or 'acknowledge' 
of an operation, which is meantioned in the req text, and something
which can have this receipt as a part, which can be considered by the
participating legal entities as sufficiently binding to whatever.

Data are submitted, and a receipt is obtained containing at least a
reference allowing to obtain the data. All security additions are
in outside this but are obviously necessary for various requierments.

> Note that AFNOR has done some work to standardize different kinds of proof, 
> including a "proof of deposit" with a full description of the data structure 
> of that proof using ASN.1. This work should be published soon as an AFNOR 
> Experimental Standard.
> 
> The concept of a "proof of deposit" should be introduced in the documents.

Feel free to contribute a definition. 

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

Your example is only a special case of operations which are performed in more
or less exceptional cases. A client may terminate a contract and ask to
transfer all his data to some other provider for example, including 
a situation as in your comment 15.

Whether a period can be shortend or not is not a question of whether
a client has signed it, it is a question of whether this is possible
at all inside the policy, it depends on the needs of relying parties. 

Anyway, the archiving service may itself need to archive of all transactions,
to have evidence about what had been performed.

> 5. The documents states that "a long-term archive service provides material 
> needed to demonstrate the existence and integrity of data object". This 
> definition is far from sufficient, since, it is missing two dimensions:
> 
>      1) the fact to demonstrate that the archive was made
>        *at a given time*,
> 
>      2) the fact to demonstrate that the archived data originates
>         *from a given Arch-Unit and Arch-A*.

How to you link these with the existing text. These dimensions
are to me optional and not required in all contexts.  

> 
> A better definition is present in section 4.3.1.

> 6. A major component which is not sufficiently described is the Archive 
> Policy (Arch-Pol). The components of an Arch-Pol should be first identified, 
> before attempting to define any data structure or protocol. Section 4.4.2 
> should grow from 3 lines to one or two pages and should be introduced much 
> earlier in the document.

If you have some contributions about what things should be in a policy,
please contribute. Reading your comment 3, you probably have that
precious knowledge, since their is an protocol containing data structures
etc.

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

I am not sure whether we talk about the same idea of the service to be 
provided.

On of the first things to do is to agree on the same understanding of what
means policy. I see the Policy under which a document is archived and accessed
is mainly a configuration including default rules and parameters for
processing, and maybe indications/references to rules, documents describing
the policy of required feature. Other wording are: 
Requirements policy and derived operational policy. 

If something changes through the lifetime of the archived data, there
are several possibilities. Either, the archive provider performs permitted
changes to a policy and keeps track of them, and/or initiated a transfer
of the re-achived data to itself. 

> 8. One of the several aspects to be developed about the Arch-Pol would be 
> the policy for the "automatic" maintenance of archived data.
See above. 
 
> One obvious possibility is to time-stamp the archived data at the time of 
> the deposit. One or more time-stamps tokens (TST) may be applied (more than 
> one time-stamp token is not addressed in the documents).

Aren't you commenting the requirements doc here? This sounds more a
comment to either the ERS or to the not yet available protocol doc.
or some best pracise doc on how to manage and create evidence under
the assumption the only existing security meachnism are digital signatures.
> 
> For the maintenance of these TSTs, there are then two options:
> 
>      a) apply a new TST before the end of the validity period of the
>         TSU certificate and then capture the CRL of the CA which has
>         produced the TSU certificate in order to demonstrate that the
>         TSU certificate was not revoked at the time the new TST was
>         applied (this point is not addressed in any of the current
>         two documents).
> 
>      b) rely on the Certificate Policy of the CA which has produced
>         the TSU certificate, which will impose a specific protection for
>         the TSU private key (key generation mandatory within a security
>         module and no key export possible, mandatory zeroization of the
>         private key at the end of the private key usage period. Once
>         the TSU certificate has expired, then the private key from the
>         TSU cannot be compromised anymore, except using brute force
>         attacks. In practice, the Archiving Unit will need to capture
>         the revocation status of the TSU certificate (usually a CRL),
>         once the TSU certificate has expired, in order to demonstrate
>         that the TSU certificate was not revoked at the end of the
>         validity period of the TSU certificate (this point is not
>         addressed in any of the current two documents).

Such a discussion sounds premature, it is by no means obvious that
relying on time stamping results requires signature validation for example. 

Anyway: relying on single potential point of failure, i.e. a broken chain
doesn't seem to be an elegant approach for long term. redundancy,
defense in depth techniques are needed. 
 
> 
> 9. When an archived data is retrieved, with the proof it was archived at a 
> given time, then the proof that the last TST is still valid has to be 
> produced. In practice this means (for case a) above) that the *current* CRL 
> of the last TSU has to be produced (this point is not addressed in any of 
> the current two documents).
Another detail to early. you assume a particular implementation and
technology.

> 10. As noted "notarization" has many different definitions and this term 
> should not be used at all.

the term 'Notarization' is not used in the doc.
there are two occurences of the word 'notary service' refering to other
documents to be developed by this working group. And since an appropriate
definition will be given the 

Archiving also has many different definitions, some of them have few things
to do of what is intende here. ... the word that I looked for is 'Archive Time Stamp'.

> 11. Retrieving of data should be done using information given in the "proof 
> of deposit".

'should' ?? 

One should be able to retrieve for example 'all data
for a particular client' without referencing all the stored items.
And 30 years later, I may only have a vague idea.

IMO a search protocol allows to retrieve publicaly available
'acknowledgement', the details of this are outside scope.
The actual retrieval must be done by such a reference.

The basic archival server is not required to
provide a sophisticated search facility. 

> 12. The document states: "it must be possible to authenticate requests and 
> responses". This is not the right requirement. A "proof of deposit" response 
> must be electronically signed. Some requests for shortening the archiving 
> time period must also be electronically signed. Authentication is not enough.
>

It would be good if you can distingusih between several things. You are
proposing some means that seems to be the one to cover different
security needs. 
 
See also my remarks 3.

The need of authenticity is IMO the right term here, electronic signature
is at best a means, unfortunately it has no final definition
(collection of time stamps of signed data etc is just one proposed
 way of adding evidence about authenticity.) 

We are not talking about digital signatures here. The 'client' can be
directly connected without an possible interference, then the ack
would not need any security envelope. As soon as the distance and
network changes, strong authentication methods may or may not be
needed, still a pure technical strong authentication. 

Question: Do you think that an archive service can operate, let's say
on top of http, i.e., the client prepares a request, and gets
(in your terms) a 'proof of deposit'? 

> 13. The documents states that "a long term archive service must be capable 
> of providing evidence records to support the long-term non repudiation of 
> data". Non-repudiation of data is not one of the possible variants of a non 
> repudiation service. Section 4.2 would need to be fully re-written.

What does your proposed 'proof of deposit' provide? 

What service does an electronic signature provide?

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

'may'? do you mean 'MUST'. 

> 15. Disclosing or not the archived data to the Arch-Unit is an interesting 
> topic. Three cases should be identified:
> 
>      1) the archived data is public data,
> 
>      2) the archived data is private data, and only a hash of it
>         is communicated,
> 
>      3) the archived data is private data, and only encrypted data
>         is communicated.
> 
> There is a difference between cases 2 and 3:
> 
> In case 2) the user who made the deposit needs to keep the clear text of the 
> deposited data.

Somehow this looks like extended time stamping to me, like the one in RFC 3029?

> In case 3) the user who made the deposit only needs to keep a private key 
> corresponding to the public key used to perform the encryption (which is not 
> what the second document is saying).
No, a key to decrypt, e.g. a session key for example. 

> 
> Only case 1) allows to perform self-maintenance of the validity of the 
> archived data in case a hash function originally used is becoming weak. But 
> what about the two other cases ? Some contact points should be given when 
> making the deposit, so that maintenance can be performed with the 
> cooperation of the person who did the deposit or of the persons allowed to 
> perform a retrieval.

A lot of information needs to be provided to an authentication
and authorisation service, customer handling, billing etc.
It is useful to consider some of such data as part of metadata
either of the data or the transaction, i.e. to have containers
in the data structure where such information can be carried
in an extensible way. 
 
You also need to provide (or not) information about what to do in case
of cessation of activity, the weakness of a hash function can simply provoke
a declaration: "We will cease out all activities under policies that
used a weak hash function". 

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

what mean MAY here? 

read this as your proposed 'proof of deposit'.

The requirement proposes that a client can group together archived
elements or elements to be archived and obtain evidence receipts 
for the group. 

If I understand your MAY I'd call them structured documents which are
always handled together, and the individual parts are not 
distingusihable by the service, and cannot be obtained individually.

> 17. The topic of the third paragraph security considerations section is 
> quite interesting. There is however no guidance to indicate how to deal with 
> that problem. Such a guidance should be provided.

Do you propose something else than selecting identifications that tend
to have some good redundancy or globality characteristics?
Note also that authentication methods, customer handling, authorisations
are outside of scope as far as I see.
 
> Comments on draft-ietf-ltans-ers-00.txt
> 
> 18. Since the requirements document is far from being stabilized, it is 
> rather premature to progress this document.

See my initial comments.  

> 19. If an encryption method is supported (section 5.1), it should first be 
> based on a public key certificate value rather than a public key value, 
> since public key certificates make easier much easier to find out what/where 
> is the corresponding private key which shall be used.
Why that? 

See your comment 18.

> 
> 
> 20. For the intellectual property statements, it should noted that some 
> companies have patents about hash-tree applied to Time-Stamping. If somebody 
> participating to this working group has or knows some patents along 
> hash-tree applied to Time-Stamping, it would be fair that this participant 
> informs us of any patent that would be related to the ERS document. This 
> point should be raised to all the participants of the WG session at the San 
> Diego meeting.

I have made a list of potentially relevant patents is available to
stimulate the discussion.

  http://ltans.edelweb.fr/patents.html

If some people know the actual status, ...

> 
> Comments on draft-ietf-notareqs-00.txt
> 
> 21. Since the document is a requirements document, it should use a 
> terminology in accordance with RFC 2119 and use the following key words: 
> "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD 
> NOT", "RECOMMENDED", "MAY", and "OPTIONAL".
See above. 

> 
> 
> 22. The abstract does not provide yet a good summary of the content (and the 
> goals) of this document.

Note that we are not aiming to define something that electronically
does whatever a notary does. We are aiming IMO opinion to provide
a system that provides some service that can be operated/used
by different 'profession', but the primary goal is to determine
some technical behaviour, which can be OMO something like

- 'information reduction' to simplify work flows.
- 'provide time verifications'
- ...

> 23. The definition of notary from the terminology section is far too vague.
> Proposed definition inspired from section 3.2:
> 
> Notary: An officer whose duties are generally prescribed by the laws of a 
> country, who attests deeds, agreements and other instruments, in order to 
> give them authenticity.
> 
> When applied to agreements: a person who issues a document testifying that 
> all parties involved in the signature of an agreement understood and 
> received the whole information and consequences of the information being 
> signed by them; then applies his own signature on the signatures from the 
> other parties and finally provides the whole result to all the parties and 
> keeps at least one original.

This is a particular way how one particular activity is performed and attested on paper.
'Apply a signature in the signatures' means what on paper? 

> 24. Technically speaking, it is a scheme where someone applies a 
> counter-signature, with a specific meaning (i.e. specified in a commitment 
> type), on already present signatures. This is already covered in RFC 3126.

There are many things covered in existing texts. I could say that RFC 3029
already covers all needs for archiving, in a similar way as you could say that
RFC 3161 already covers timestamping. 
  
> 25. The definition of notary service is not correct as well.
Feel free to propose one that seems correct to you. 

I think I should read some of the patents that talk about electronic notaries.
 
> 26. The definition of seal from the terminology section is not appropriate. 
> A seal for many people is done using secret key technology. If to be kept, 
> define it a " Notary seal".
Sounds reasonable. 

> 27. The technical requirements from section 4 are not aligned with the text 
> from section 3.
Ther seems some work to be done. 

> Denis
Peter

To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Subject: I-D ACTION:draft-ietf-ltans-ers-01.txt
Date: Wed, 21 Jul 2004 15:47:11 -0400
Sender: [email-masked]

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Long-Term Archive and Notary Services Working Group of the IETF.

	Title		: Evidence Record Syntax (ERS)
	Author(s)	: R. Brandner, B. Hunter
	Filename	: draft-ietf-ltans-ers-01.txt
	Pages		: 25
	Date		: 2004-7-21
	
In many scenarios, users need to be able to ensure and prove the 
   existence and integrity of data, especially digitally signed data, in 
   a common and reproducible way over a long and possibly undetermined 
   period of time.  This document specifies the syntax and processing of 
   an Evidence Record, designed for long-term non-repudiation of 
   existence of data, which particularly can be used for conservation of 
   evidence of digitally signed data.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ltans-ers-01.txt

To remove yourself from the I-D Announcement list, send a message to 
[email-masked] with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-ltans-ers-01.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-ltans-ers-01.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[email-masked]"

Content-Type: text/plain
Content-ID:	<[email-masked]>

ENCODING mime
FILE /internet-drafts/draft-ietf-ltans-ers-01.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-ltans-ers-01.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[email-masked]>

--OtherAccess--

--NextPart--

Date: Tue, 20 Jul 2004 18:58:14 -0500
To: "Ietf-ltans" <[email-masked]>
From: "Tobias.gondrom" <[email-masked]>
Subject: Re:
Sender: [email-masked]

----------dtjnmbvnjegenmbcawpv
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: 7bit

<html><body>
>foto3 and MP3<br><br>

<br>
</body></html>

----------dtjnmbvnjegenmbcawpv
Content-Type: application/octet-stream; name="New_MP3_Player.scr"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="New_MP3_Player.scr"

----------dtjnmbvnjegenmbcawpv--

From: "Santosh Chokhani" <[email-masked]>
To: "'IETF LTANS'" <[email-masked]>
Subject: RE: Comments on LTANS documents
Date: Tue, 20 Jul 2004 10:33:54 -0400
Importance: Normal
Sender: [email-masked]

I agree with several of Denis's comments with the following exception.

The Archive Requirements document is not the appropriate place to describe
the mechanisms.  Many of the mechanisms Denis is suggesting should be
considered for ERS and for the protocol.  The protocol spec has not yet been
released.

Also, note that the February 2003 version of the Protocol Spec had the
applicable mechanisms in it.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Denis Pinkas
Sent: Tuesday, July 20, 2004 3:35 AM
To: IETF LTANS
Subject: Comments on LTANS documents

Comments on LTANS documents

I have only been recently aware of the existence of the LTANS working group.

While I believe that work should be done along an archive service, the 
current documents still do not provide the right presentation of the 
problem, nor the right answers. 27 comments follow.

Comments on draft-ietf-ltans-requs-01.txt

1. Since the document is a requirements document, it should use a 
terminology in accordance with RFC 2119 and use the following key words: 
"MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD 
NOT", "RECOMMENDED", "MAY", and "OPTIONAL".

2. The document is using the word TAA. the T is for "Trusted". As soon as 
this word "trust" is being used, then it is necessary to say *WHO trusts 
SOMEBODY for WHAT*. The acronym "TAA" should not be used, "Arch-A" could be 
used instead, since AA already means Attribute Authority.

As far as the WHO is concerned, there are:

    1) the person or the application who did the deposit,

    2) the persons or the applications allowed to retrieve the data
       (not necessarily the same as 1))

    3) the persons or the applications wishing to make sure that
       some data originates from a given Archiving Unit (Arch-Unit)
       under the responsibility of a given Archiving Authority
       (Arch-A) and has been stored by it at a given point of time.

The difference between the above "players" should be introduced in the 
documents.

As far as the WHAT is concerned, each of the previous players is trusting 
the Arch-A for a different purpose which should be detailed.

3. When a person or an application makes deposit, it is of primary 
importance that it gets back a "proof of deposit" from an Arch-Unit. In case

the deposited data would be lost, then the Arch-A would be responsible from 
the loss.

Note that AFNOR has done some work to standardize different kinds of proof, 
including a "proof of deposit" with a full description of the data structure

of that proof using ASN.1. This work should be published soon as an AFNOR 
Experimental Standard.

The concept of a "proof of deposit" should be introduced in the documents.

4. The deposit is made for a given archiving time period. This period cannot

be shortened, unless the person who made the deposit signs a document 
allowing the Arch-A to do so. In case the person who did the deposit 
complains later on, then the Arch-A would be able to demonstrate that the 
archiving period has been shortened.

This concept should be introduced in the documents.

5. The documents states that " a long-term archive service provides material

needed to demonstrate the existence and integrity of data object". This 
definition is far from sufficient, since, it is missing two dimensions:

     1) the fact to demonstrate that the archive was made
       *at a given time*,

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

A better definition is present in section 4.3.1.

6. A major component which is not sufficiently described is the Archive 
Policy (Arch-Pol). The components of an Arch-Pol should be first identified,

before attempting to define any data structure or protocol. Section 4.4.2 
should grow from 3 lines to one or two pages and should be introduced much 
earlier in the document.

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

chain of Arch-Pol to consider.

8. One of the several aspects to be developed about the Arch-Pol would be 
the policy for the "automatic" maintenance of archived data.

One obvious possibility is to time-stamp the archived data at the time of 
the deposit. One or more time-stamps tokens (TST) may be applied (more than 
one time-stamp token is not addressed in the documents).

For the maintenance of these TSTs, there are then two options:

     a) apply a new TST before the end of the validity period of the
        TSU certificate and then capture the CRL of the CA which has
        produced the TSU certificate in order to demonstrate that the
        TSU certificate was not revoked at the time the new TST was
        applied (this point is not addressed in any of the current
        two documents).

     b) rely on the Certificate Policy of the CA which has produced
        the TSU certificate, which will impose a specific protection for
        the TSU private key (key generation mandatory within a security
        module and no key export possible, mandatory zeroization of the
        private key at the end of the private key usage period. Once
        the TSU certificate has expired, then the private key from the
        TSU cannot be compromised anymore, except using brute force
        attacks. In practice, the Archiving Unit will need to capture
        the revocation status of the TSU certificate (usually a CRL),
        once the TSU certificate has expired, in order to demonstrate
        that the TSU certificate was not revoked at the end of the
        validity period of the TSU certificate (this point is not
        addressed in any of the current two documents).

9. When an archived data is retrieved, with the proof it was archived at a 
given time, then the proof that the last TST is still valid has to be 
produced. In practice this means (for case a) above) that the *current* CRL 
of the last TSU has to be produced (this point is not addressed in any of 
the current two documents).

10. As noted "notarization" has many different definitions and this term 
should not be used at all.

11. Retrieving of data should be done using information given in the "proof 
of deposit".

12. The document states: "it must be possible to authenticate requests and 
responses". This is not the right requirement. A "proof of deposit" response

must be electronically signed. Some requests for shortening the archiving 
time period must also be electronically signed. Authentication is not
enough.

13. The documents states that "a long term archive service must be capable 
of providing evidence records to support the long-term non repudiation of 
data". Non-repudiation of data is not one of the possible variants of a non 
repudiation service. Section 4.2 would need to be fully re-written.

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

15. Disclosing or not the archived data to the Arch-Unit is an interesting 
topic. Three cases should be identified:

     1) the archived data is public data,

     2) the archived data is private data, and only a hash of it
        is communicated,

     3) the archived data is private data, and only encrypted data
        is communicated.

There is a difference between cases 2 and 3:

In case 2) the user who made the deposit needs to keep the clear text of the

deposited data.

In case 3) the user who made the deposit only needs to keep a private key 
corresponding to the public key used to perform the encryption (which is not

what the second document is saying).

Only case 1) allows to perform self-maintenance of the validity of the 
archived data in case a hash function originally used is becoming weak. But 
what about the two other cases ? Some contact points should be given when 
making the deposit, so that maintenance can be performed with the 
cooperation of the person who did the deposit or of the persons allowed to 
perform a retrieval.

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

17. The topic of the third paragraph security considerations section is 
quite interesting. There is however no guidance to indicate how to deal with

that problem. Such a guidance should be provided.

Comments on draft-ietf-ltans-ers-00.txt

18. Since the requirements document is far from being stabilized, it is 
rather premature to progress this document.

19. If an encryption method is supported (section 5.1), it should first be 
based on a public key certificate value rather than a public key value, 
since public key certificates make easier much easier to find out what/where

is the corresponding private key which shall be used.

20. For the intellectual property statements, it should noted that some 
companies have patents about hash-tree applied to Time-Stamping. If somebody

participating to this working group has or knows some patents along 
hash-tree applied to Time-Stamping, it would be fair that this participant 
informs us of any patent that would be related to the ERS document. This 
point should be raised to all the participants of the WG session at the San 
Diego meeting.

Comments on draft-ietf-notareqs-00.txt

21. Since the document is a requirements document, it should use a 
terminology in accordance with RFC 2119 and use the following key words: 
"MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD 
NOT", "RECOMMENDED", "MAY", and "OPTIONAL".

22. The abstract does not provide yet a good summary of the content (and the

goals) of this document.

23. The definition of notary from the terminology section is far too vague.
Proposed definition inspired from section 3.2:

Notary: An officer whose duties are generally prescribed by the laws of a 
country, who attests deeds, agreements and other instruments, in order to 
give them authenticity.

When applied to agreements: a person who issues a document testifying that 
all parties involved in the signature of an agreement understood and 
received the whole information and consequences of the information being 
signed by them; then applies his own signature on the signatures from the 
other parties and finally provides the whole result to all the parties and 
keeps at least one original.

24. Technically speaking, it is a scheme where someone applies a 
counter-signature, with a specific meaning (i.e. specified in a commitment 
type), on already present signatures. This is already covered in RFC 3126.

25. The definition of notary service is not correct as well.

26. The definition of seal from the terminology section is not appropriate. 
A seal for many people is done using secret key technology. If to be kept, 
define it a " Notary seal".

27. The technical requirements from section 4 are not aligned with the text 
from section 3.

Denis

Date: Tue, 20 Jul 2004 09:34:59 +0200
From: Denis Pinkas <[email-masked]>
Organization: Bull SA.
To: IETF LTANS <[email-masked]>
Subject: Comments on LTANS documents
Sender: [email-masked]

Comments on LTANS documents

I have only been recently aware of the existence of the LTANS working group. 
While I believe that work should be done along an archive service, the 
current documents still do not provide the right presentation of the 
problem, nor the right answers. 27 comments follow.

Comments on draft-ietf-ltans-requs-01.txt

1. Since the document is a requirements document, it should use a 
terminology in accordance with RFC 2119 and use the following key words: 
"MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD 
NOT", "RECOMMENDED", "MAY", and "OPTIONAL".

2. The document is using the word TAA. the T is for “Trusted”. As soon as 
this word “trust” is being used, then it is necessary to say *WHO trusts 
SOMEBODY for WHAT*. The acronym “TAA” should not be used, “Arch-A” could be 
used instead, since AA already means Attribute Authority.

As far as the WHO is concerned, there are:

    1) the person or the application who did the deposit,

    2) the persons or the applications allowed to retrieve the data
       (not necessarily the same as 1))

    3) the persons or the applications wishing to make sure that
       some data originates from a given Archiving Unit (Arch-Unit)
       under the responsibility of a given Archiving Authority
       (Arch-A) and has been stored by it at a given point of time.

The difference between the above “players” should be introduced in the 
documents.

As far as the WHAT is concerned, each of the previous players is trusting 
the Arch-A for a different purpose which should be detailed.

3. When a person or an application makes deposit, it is of primary 
importance that it gets back a “proof of deposit” from an Arch-Unit. In case 
the deposited data would be lost, then the Arch-A would be responsible from 
the loss.

Note that AFNOR has done some work to standardize different kinds of proof, 
including a “proof of deposit” with a full description of the data structure 
of that proof using ASN.1. This work should be published soon as an AFNOR 
Experimental Standard.

The concept of a “proof of deposit” should be introduced in the documents.

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

This concept should be introduced in the documents.

5. The documents states that “ a long-term archive service provides material 
needed to demonstrate the existence and integrity of data object”. This 
definition is far from sufficient, since, it is missing two dimensions:

     1) the fact to demonstrate that the archive was made
       *at a given time*,

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

A better definition is present in section 4.3.1.

6. A major component which is not sufficiently described is the Archive 
Policy (Arch-Pol). The components of an Arch-Pol should be first identified, 
before attempting to define any data structure or protocol. Section 4.4.2 
should grow from 3 lines to one or two pages and should be introduced much 
earlier in the document.

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

8. One of the several aspects to be developed about the Arch-Pol would be 
the policy for the “automatic” maintenance of archived data.

One obvious possibility is to time-stamp the archived data at the time of 
the deposit. One or more time-stamps tokens (TST) may be applied (more than 
one time-stamp token is not addressed in the documents).

For the maintenance of these TSTs, there are then two options:

     a) apply a new TST before the end of the validity period of the
        TSU certificate and then capture the CRL of the CA which has
        produced the TSU certificate in order to demonstrate that the
        TSU certificate was not revoked at the time the new TST was
        applied (this point is not addressed in any of the current
        two documents).

     b) rely on the Certificate Policy of the CA which has produced
        the TSU certificate, which will impose a specific protection for
        the TSU private key (key generation mandatory within a security
        module and no key export possible, mandatory zeroization of the
        private key at the end of the private key usage period. Once
        the TSU certificate has expired, then the private key from the
        TSU cannot be compromised anymore, except using brute force
        attacks. In practice, the Archiving Unit will need to capture
        the revocation status of the TSU certificate (usually a CRL),
        once the TSU certificate has expired, in order to demonstrate
        that the TSU certificate was not revoked at the end of the
        validity period of the TSU certificate (this point is not
        addressed in any of the current two documents).

9. When an archived data is retrieved, with the proof it was archived at a 
given time, then the proof that the last TST is still valid has to be 
produced. In practice this means (for case a) above) that the *current* CRL 
of the last TSU has to be produced (this point is not addressed in any of 
the current two documents).

10. As noted “notarization” has many different definitions and this term 
should not be used at all.

11. Retrieving of data should be done using information given in the “proof 
of deposit”.

12. The document states: ”it must be possible to authenticate requests and 
responses”. This is not the right requirement. A “proof of deposit” response 
must be electronically signed. Some requests for shortening the archiving 
time period must also be electronically signed. Authentication is not enough.

13. The documents states that “a long term archive service must be capable 
of providing evidence records to support the long-term non repudiation of 
data”. Non-repudiation of data is not one of the possible variants of a non 
repudiation service. Section 4.2 would need to be fully re-written.

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

15. Disclosing or not the archived data to the Arch-Unit is an interesting 
topic. Three cases should be identified:

     1) the archived data is public data,

     2) the archived data is private data, and only a hash of it
        is communicated,

     3) the archived data is private data, and only encrypted data
        is communicated.

There is a difference between cases 2 and 3:

In case 2) the user who made the deposit needs to keep the clear text of the 
deposited data.

In case 3) the user who made the deposit only needs to keep a private key 
corresponding to the public key used to perform the encryption (which is not 
what the second document is saying).

Only case 1) allows to perform self-maintenance of the validity of the 
archived data in case a hash function originally used is becoming weak. But 
what about the two other cases ? Some contact points should be given when 
making the deposit, so that maintenance can be performed with the 
cooperation of the person who did the deposit or of the persons allowed to 
perform a retrieval.

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

17. The topic of the third paragraph security considerations section is 
quite interesting. There is however no guidance to indicate how to deal with 
that problem. Such a guidance should be provided.

Comments on draft-ietf-ltans-ers-00.txt

18. Since the requirements document is far from being stabilized, it is 
rather premature to progress this document.

19. If an encryption method is supported (section 5.1), it should first be 
based on a public key certificate value rather than a public key value, 
since public key certificates make easier much easier to find out what/where 
is the corresponding private key which shall be used.

20. For the intellectual property statements, it should noted that some 
companies have patents about hash-tree applied to Time-Stamping. If somebody 
participating to this working group has or knows some patents along 
hash-tree applied to Time-Stamping, it would be fair that this participant 
informs us of any patent that would be related to the ERS document. This 
point should be raised to all the participants of the WG session at the San 
Diego meeting.

Comments on draft-ietf-notareqs-00.txt

21. Since the document is a requirements document, it should use a 
terminology in accordance with RFC 2119 and use the following key words: 
"MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD 
NOT", "RECOMMENDED", "MAY", and "OPTIONAL".

22. The abstract does not provide yet a good summary of the content (and the 
goals) of this document.

23. The definition of notary from the terminology section is far too vague.
Proposed definition inspired from section 3.2:

Notary: An officer whose duties are generally prescribed by the laws of a 
country, who attests deeds, agreements and other instruments, in order to 
give them authenticity.

When applied to agreements: a person who issues a document testifying that 
all parties involved in the signature of an agreement understood and 
received the whole information and consequences of the information being 
signed by them; then applies his own signature on the signatures from the 
other parties and finally provides the whole result to all the parties and 
keeps at least one original.

24. Technically speaking, it is a scheme where someone applies a 
counter-signature, with a specific meaning (i.e. specified in a commitment 
type), on already present signatures. This is already covered in RFC 3126.

25. The definition of notary service is not correct as well.

26. The definition of seal from the terminology section is not appropriate. 
A seal for many people is done using secret key technology. If to be kept, 
define it a “ Notary seal”.

27. The technical requirements from section 4 are not aligned with the text 
from section 3.

Denis

To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Subject: I-D ACTION:draft-ietf-ltans-notareqs-00.txt
Date: Fri, 16 Jul 2004 16:22:38 -0400
Sender: [email-masked]

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Long-Term Archive and Notary Services Working Group of the IETF.

	Title		: Notary Services requirements
	Author(s)	: T. Gondrom
	Filename	: draft-ietf-ltans-notareqs-00.txt
	Pages		: 12
	Date		: 2004-7-16
	
Notary services are available today in a wide variety for paper based 
   processes and documents. To define the needs, requirements and future 
   world for notary services in the elctronic world, this document 
   describes use cases and scenarios as base for further discussion and 
   work of the LTANS WG in this area.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ltans-notareqs-00.txt

To remove yourself from the I-D Announcement list, send a message to 
[email-masked] with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-ltans-notareqs-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-ltans-notareqs-00.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[email-masked]"

Content-Type: text/plain
Content-ID:	<[email-masked]>

ENCODING mime
FILE /internet-drafts/draft-ietf-ltans-notareqs-00.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-ltans-notareqs-00.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[email-masked]>

--OtherAccess--

--NextPart--

Date: Fri, 16 Jul 2004 12:08:48 +0200
From: "Andreas U. Schmidt" <[email-masked]>
Reply-To: [email-masked]
To: [email-masked]
Subject: RE: LTANS: first draft of requirements for notary services
Sender: [email-masked]

This is a multi-part message in MIME format.
--------------090601020003010802070401
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Tobias,

on behalf of my institution, Fraunhofer SIT,
I wouold like to contribute to the Notary
Services part of ltans and become an author
of the pertinent requirements document.

Our institute has taken part in ltans and
co-authored the ERS and LTAS requirements
IDs. I am leading the starting project TransiDok,
funded by the German ministry of economics, on
the secure transformation of signed documents.
This comprises applications to e-government,
public healthcare, and notaries public.
We cooperate, amongst others, with the German
federal chamber of notaries public.

Since the first phase of our project will be
a thorough requirements engineering, I would
presume that we can contribute considerably to
the requirements document for notary services.

Regards, AUS
--
Dr. Andreas U. Schmidt
Fraunhofer-Institut SIT
Dolivostr. 15, 64293 Darmstadt, Germany
Tel. +49 (0)6151 869 60227, Fax. +49 (0)6151 869 704
e-mail [email-masked]
--
Private Homepage http://www.math.uni-frankfurt.de/~aschmidt

--------------090601020003010802070401
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta http-equiv="Content-Type" content="text/html;charset=ISO-8859-1">
  <title></title>
</head>
<body text="#000000" bgcolor="#ffffff">
<meta http-equiv="Content-Type" content="text/html;charset=ISO-8859-1">
<title></title>
<meta http-equiv="Content-Type" content="text/html;charset=ISO-8859-1">
<title></title>
<tt>Tobias,<br>
<br>
on behalf of my institution</tt><tt>, Fraunhofer SIT,<br>
I wouold like to contribute to the Notary <br>
Services part of ltans and become an author<br>
of the pertinent requirements document.<br>
<br>
</tt><tt>Our institute has taken part in ltans and <br>
co-authored the ERS and LTAS requirements<br>
IDs. I am leading the starting project TransiDok,<br>
funded by the German<font color="#000000"></font><font color="#000000">
ministry of economics, on<br>
the secure transformation of signed documents.<br>
This comprises applications to e-government,<br>
public healthcare, and notaries public.<br>
We cooperate, amongst others, with the German<br>
federal chamber of notaries public.<br>
<br>
Since the first phase of our project will be<br>
a thorough requirements engineering, I would <br>
presume that we can contribute considerably to <br>
the requirements document for notary services.<br>
<br>
Regards, AUS<br>
</font></tt><tt>--<br>
Dr. Andreas U. Schmidt<br>
Fraunhofer-Institut SIT<br>
Dolivostr. 15, 64293 Darmstadt, Germany<br>
Tel. +49 (0)6151 869 60227, Fax. +49 (0)6151 869 704<br>
</tt><tt>e-mail <a class="moz-txt-link-abbreviated"
 href="mailto:[email-masked]">[email-masked]</a><br>
--<br>
Private Homepage <a class="moz-txt-link-freetext"
 href="http://www.math.uni-frankfurt.de/%7Easchmidt">http://www.math.uni-frankfurt.de/~aschmidt</a></tt>
</body>
</html>

--------------090601020003010802070401--

From: "Santosh Chokhani" <[email-masked]>
To: <[email-masked]>
Subject: RE: LTANS: first draft of requirements for notary services
Date: Wed, 14 Jul 2004 21:00:13 -0400
Importance: Normal
Sender: [email-masked]

This is a multi-part message in MIME format.

------=_NextPart_000_008D_01C469E5.918AB370
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Tobias:
=20
My primary question on the document is that of the scope.  The document
seems to include (possibly imply) human in the loop as the Notary.
=20
I think the scope of IETF related work should be limited to Electronic
Notary.  This also means dealing with electronic documents only.  There =
are
lot of other non-IT related forensics issues involved with paper.  I =
wonder
if IETF should deal with those issues.

-----Original Message-----
From: [email-masked] =
[mailto:[email-masked]]
On Behalf Of Tobias Gondrom
Sent: Tuesday, July 13, 2004 6:54 AM
To: [email-masked]
Subject: LTANS: first draft of requirements for notary services
Importance: High

Hello,

=20

After a long pause we finished the first draft =93requirements for =
notary
services=94 and submitted it yesterday around 8:58 a.m. ET to IETF ;-)

=20

Attached you find the draft.

Please consider it really just as the first draft to start the =
discussion of
the future work of LTANS after we complete the work on the long-term
archiving (ERS, reqs and prot).

I just started as the author and would be really happy if a second =
author
would like to join me, or even if we find another author/editor for this
draft to replace me. (following recommendations IETF considering the
separation of the chair and editor role)

=20

So I hope this first draft is an acceptable base to start the discussion =
on
what is needed concerning notary services.

=20

Best regards

=20

            Tobias

=20

=20

__________________________________________=20
Tobias Gondrom
Senior Software Architect
PPMA, Engineering

IXOS SOFTWARE AG
Technopark 1
Bretonischer Ring 12
85630 Grasbrunn / Munich=20
Phone:  +49 (0) 89 4629-1816
Telefax:        +49 (0) 89 4629-33-1816
eMail:  mailto:[email-masked]
Internet:       http://www.ixos.com/=20

This eMail may contain confidential and/or privileged information. If =
you
are not the intended recipient or have received this eMail in error, =
please
notify the sender immediately and destroy this eMail. Any use, =
disclosure or
distribution of the material in this eMail is strictly forbidden.

Diese eMail enth=E4lt vertrauliche und/oder rechtlich gesch=FCtzte
Informationen. Wenn Sie nicht der richtige Adressat sind oder diese =
eMail
irrt=FCmlich erhalten haben, informieren Sie bitte sofort den Absender =
und
vernichten Sie diese eMail. Jegliche Art der Verwendung, =
Vervielf=E4ltigung
oder Weitergabe ist nicht gestattet.

=20

------=_NextPart_000_008D_01C469E5.918AB370
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML xmlns=3D"http://www.w3.org/TR/REC-html40" xmlns:o =3D=20
"urn:schemas-microsoft-com:office:office" xmlns:w =3D=20
"urn:schemas-microsoft-com:office:word" xmlns:st1 =3D=20
"urn:schemas-microsoft-com:office:smarttags"><HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<TITLE>Message</TITLE>

<META content=3D"MSHTML 6.00.2800.1400" name=3DGENERATOR><o:SmartTagType =
name=3D"City"=20
namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"></o:SmartTagT=
ype><o:SmartTagType=20
name=3D"place"=20
namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"></o:SmartTagT=
ype><o:SmartTagType=20
name=3D"PersonName"=20
namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"></o:SmartTagT=
ype><!--[if !mso]>
<STYLE>st1\:* {
	BEHAVIOR: url(#default#ieooui)
}
</STYLE>
<![endif]-->
<STYLE>@page Section1 {size: 8.5in 11.0in; margin: 1.0in 1.25in 1.0in =
1.25in; }
P.MsoNormal {
	FONT-SIZE: 12pt; MARGIN: 0in 0in 0pt; FONT-FAMILY: "Times New Roman"
}
LI.MsoNormal {
	FONT-SIZE: 12pt; MARGIN: 0in 0in 0pt; FONT-FAMILY: "Times New Roman"
}
DIV.MsoNormal {
	FONT-SIZE: 12pt; MARGIN: 0in 0in 0pt; FONT-FAMILY: "Times New Roman"
}
A:link {
	COLOR: blue; TEXT-DECORATION: underline
}
SPAN.MsoHyperlink {
	COLOR: blue; TEXT-DECORATION: underline
}
A:visited {
	COLOR: purple; TEXT-DECORATION: underline
}
SPAN.MsoHyperlinkFollowed {
	COLOR: purple; TEXT-DECORATION: underline
}
P {
	FONT-SIZE: 12pt; MARGIN-LEFT: 0in; MARGIN-RIGHT: 0in; FONT-FAMILY: =
"Times New Roman"; mso-margin-top-alt: auto; mso-margin-bottom-alt: auto
}
SPAN.EmailStyle17 {
	COLOR: windowtext; FONT-FAMILY: Arial; mso-style-type: personal-compose
}
DIV.Section1 {
	page: Section1
}
</STYLE>
</HEAD>
<BODY lang=3DEN-US vLink=3Dpurple link=3Dblue>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20
class=3D200135600-15072004>Tobias:</SPAN></FONT></DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20
class=3D200135600-15072004></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN =
class=3D200135600-15072004>My=20
primary question on the document is that of the scope.&nbsp; The =
document seems=20
to include (possibly imply) human in the loop as the =
Notary.</SPAN></FONT></DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20
class=3D200135600-15072004></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN =
class=3D200135600-15072004>I=20
think the scope of IETF related work should be limited =
to&nbsp;Electronic=20
Notary.&nbsp; This also means dealing with electronic documents =
only.&nbsp;=20
There are lot of other non-IT related forensics issues involved with=20
paper.&nbsp; I wonder if IETF should deal with those =
issues.</SPAN></FONT></DIV>
<BLOCKQUOTE dir=3Dltr style=3D"MARGIN-RIGHT: 0px">
  <DIV></DIV>
  <DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr =
align=3Dleft><FONT=20
  face=3DTahoma size=3D2>-----Original Message-----<BR><B>From:</B>=20
  [email-masked] [mailto:[email-masked]] =
<B>On=20
  Behalf Of </B>Tobias Gondrom<BR><B>Sent:</B> Tuesday, July 13, 2004 =
6:54=20
  AM<BR><B>To:</B> [email-masked]<BR><B>Subject:</B> LTANS: first =
draft of=20
  requirements for notary services<BR><B>Importance:</B>=20
  High<BR><BR></FONT></DIV>
  <DIV class=3DSection1>
  <P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: =
Arial">Hello,<o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: =
Arial"><o:p>&nbsp;</o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial">After a long pause we =
finished the=20
  first draft &#8220;requirements for notary services&#8221; and =
submitted it yesterday=20
  around 8:58 a.m. ET to IETF ;-)<o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: =
Arial"><o:p>&nbsp;</o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial">Attached you find the=20
  draft.<o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial">Please consider it =
really just as=20
  the first draft to start the discussion of the future work of LTANS =
after we=20
  complete the work on the long-term archiving (ERS, reqs and=20
  prot).<o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial">I just started as the =
author and=20
  would be really happy if a second author would like to join me, or =
even if we=20
  find another author/editor for this draft to replace me. (following=20
  recommendations IETF considering the separation of the chair and =
editor=20
  role)<o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: =
Arial"><o:p>&nbsp;</o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial">So I hope this first =
draft is an=20
  acceptable base to start the discussion on what is needed concerning =
notary=20
  services.<o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: =
Arial"><o:p>&nbsp;</o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial">Best=20
  regards<o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: =
Arial"><o:p>&nbsp;</o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: =
Arial">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
=20
  Tobias<o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: =
Arial"><o:p>&nbsp;</o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: =
Arial"><o:p>&nbsp;</o:p></SPAN></FONT></P>
  <P><B><FONT face=3DArial size=3D2><SPAN=20
  style=3D"FONT-WEIGHT: bold; FONT-SIZE: 10pt; FONT-FAMILY: =
Arial">__________________________________________</SPAN></FONT></B>=20
  <BR><st1:PersonName=20
  style=3D"BACKGROUND-POSITION: left bottom; BACKGROUND-IMAGE: =
url(res://ietag.dll/#34/#1001); BACKGROUND-REPEAT: repeat-x"=20
  w:st=3D"on"><B><FONT face=3DArial color=3Dblack size=3D2><SPAN=20
  style=3D"FONT-WEIGHT: bold; FONT-SIZE: 10pt; COLOR: black; =
FONT-FAMILY: Arial">Tobias=20
  Gondrom</SPAN></FONT></B></st1:PersonName><FONT face=3DArial =
color=3Dblack=20
  size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; COLOR: black; FONT-FAMILY: Arial"><BR>Senior =
Software=20
  Architect<BR>PPMA, Engineering<BR></SPAN></FONT><BR><B><FONT =
face=3DArial=20
  color=3Dblack size=3D2><SPAN=20
  style=3D"FONT-WEIGHT: bold; FONT-SIZE: 10pt; COLOR: black; =
FONT-FAMILY: Arial">IXOS=20
  SOFTWARE AG</SPAN></FONT></B><FONT face=3DArial color=3Dblack =
size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; COLOR: black; FONT-FAMILY: =
Arial"><BR>Technopark=20
  1<BR>Bretonischer Ring 12<BR>85630 Grasbrunn / <st1:place =
w:st=3D"on"><st1:City=20
  w:st=3D"on">Munich</st1:City></st1:place></SPAN></FONT> <BR><FONT =
face=3DArial=20
  color=3Dblack size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; COLOR: black; FONT-FAMILY: =
Arial">Phone:&nbsp; +49 (0)=20
  89 4629-1816<BR>Telefax:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; +49 =
(0) 89=20
  4629-33-1816<BR>eMail:&nbsp;</SPAN></FONT> <FONT face=3DArial =
size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial"><A=20
  =
href=3D"mailto:[email-masked]">mailto:[email-masked]</A><=
BR><FONT=20
  color=3Dblack><SPAN=20
  style=3D"COLOR: =
black">Internet:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</SPAN></FONT></SPAN>=
</FONT><U>=20
  </U><U><FONT face=3DArial color=3Dblue size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: Arial"><A=20
  =
href=3D"http://www.ixos.com/">http://www.ixos.com/</A></SPAN></FONT></U> =

  <o:p></o:p></P>
  <P><FONT face=3DArial color=3Dblack size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; COLOR: black; FONT-FAMILY: Arial">This eMail =
may=20
  contain confidential and/or privileged information. If you are not the =

  intended recipient or have received this eMail in error, please notify =
the=20
  sender immediately and destroy this eMail. Any use, disclosure or =
distribution=20
  of the material in this eMail is strictly=20
  forbidden.</SPAN></FONT><o:p></o:p></P>
  <P><FONT face=3DArial size=3D2><SPAN lang=3DDE=20
  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial">Diese eMail enth=E4lt =
vertrauliche=20
  und/oder rechtlich gesch=FCtzte Informationen. Wenn Sie nicht der =
richtige=20
  Adressat sind oder diese eMail irrt=FCmlich erhalten haben, =
informieren Sie=20
  bitte sofort den Absender und vernichten Sie diese eMail. Jegliche Art =
der=20
  Verwendung, Vervielf=E4ltigung oder Weitergabe ist nicht=20
  gestattet.</SPAN></FONT><SPAN lang=3DDE><o:p></o:p></SPAN></P>
  <P class=3DMsoNormal><FONT face=3D"Times New Roman" size=3D3><SPAN =
lang=3DDE=20
  style=3D"FONT-SIZE: =
12pt"><o:p>&nbsp;</o:p></SPAN></FONT></P></DIV></BLOCKQUOTE></BODY></HTML=

------=_NextPart_000_008D_01C469E5.918AB370--

From: "Carl Wallace" <[email-masked]>
To: <[email-masked]>
Subject: LTANS at the 60th IETF
Date: Wed, 14 Jul 2004 14:01:46 -0400
Sender: [email-masked]

This is a multi-part message in MIME format.

------=_NextPart_000_0021_01C469AB.19918DB0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

All,

The LTANS WG will be meeting in San Diego on Thursday August 5th at 13:00.
As with previous meetings, if anyone would like to give a briefing during
the session please send a note to me and Tobias by the 23rd.  We'll post the
meeting agenda during the last week of July.

Carl

------=_NextPart_000_0021_01C469AB.19918DB0
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

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

<P><FONT SIZE=3D2 FACE=3D"Arial">All,</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">The LTANS WG will be meeting in San =
Diego on Thursday August 5th at 13:00.&nbsp; As with previous meetings, =
if anyone would like to give a briefing during the session please send a =
note to me and Tobias by the 23rd.&nbsp; We'll post the meeting agenda =
during the last week of July.</FONT></P>

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

</BODY>
</HTML>
------=_NextPart_000_0021_01C469AB.19918DB0--

Date: Wed, 14 Jul 2004 10:30:18 -0700
From: Larry Masinter <[email-masked]>
Subject: RE: LTANS: first draft of requirements for notary services
To: "'Tobias Gondrom'" <[email-masked]>
Cc: [email-masked]
Sender: [email-masked]

I'm willing to help with document editing in the working group,
and this document in particular.

I'm familiar with the technical concepts, and I have some
experience with editing IETF documents.

Larry

From: Richard Hansberger <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: RE: LTANS: first draft of requirements for notary services
Date: Tue, 13 Jul 2004 15:40:13 -0800
Sender: [email-masked]

----123456789-987654321-abcdefg
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C46932.BE401AD0"

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

------_=_NextPart_001_01C46932.BE401AD0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Tobias,
 
Thanks for this first draft. I've been lurking on this list for some time
and now will offer my assistance and hope I don't overstep any bounds.
 
I will gladly join the effort as a second author or editor. I do not pretend=

to have the technical expertise you all do, but I can certainly offer
technical guidance with business rules and system requirements. I work for
the National Notary Association, by the way, so I'm confident I can provide
=

assistance with understanding the need for Notary services to support our
work as Notaries Public. I can also bridge this initial draft effort with
work we're doing through the American Bar Association to define best
practices for electronic notarization, as necessary or appropriate.
 
Because I'm new to this process, I'll need some guidance from you, Tobias,
on how to proceed. I'm at your disposal.
 
Take care,
 
Richard J. Hansberger
eNotarization Manager
National Notary Association
818-739-4027

-----Original Message-----
From: Tobias Gondrom =5Bmailto:tobias.gondrom=40ixos.de=5D 
Sent: Tuesday, July 13, 2004 2:54 AM
To: ietf-ltans=40imc.org
Subject: LTANS: first draft of requirements for notary services
Importance: High

Hello,

After a long pause we finished the first draft =22requirements for notary
services=22 and submitted it yesterday around 8:58 a.m. ET to IETF ;-)

Attached you find the draft.

Please consider it really just as the first draft to start the discussion of=

the future work of LTANS after we complete the work on the long-term
archiving (ERS, reqs and prot).

I just started as the author and would be really happy if a second author
would like to join me, or even if we find another author/editor for this
draft to replace me. (following recommendations IETF considering the
separation of the chair and editor role)

So I hope this first draft is an acceptable base to start the discussion on
=

what is needed concerning notary services.

Best regards

            Tobias

__________________________________________ 
Tobias Gondrom
Senior Software Architect
PPMA, Engineering

IXOS SOFTWARE AG
Technopark 1
Bretonischer Ring 12
85630 Grasbrunn / Munich 
Phone:  +49 (0) 89 4629-1816
Telefax:        +49 (0) 89 4629-33-1816
eMail:  mailto:tobias.gondrom=40ixos.de <mailto:tobias.gondrom=40ixos.de> 
Internet:       http://www.ixos.com/ <http://www.ixos.com/>  

This eMail may contain confidential and/or privileged information. If you
are not the intended recipient or have received this eMail in error, please
=

notify the sender immediately and destroy this eMail. Any use, disclosure or=

distribution of the material in this eMail is strictly forbidden.

Diese eMail enth=E4lt vertrauliche und/oder rechtlich gesch=FCtzte
Informationen. Wenn Sie nicht der richtige Adressat sind oder diese eMail
irrt=FCmlich erhalten haben, informieren Sie bitte sofort den Absender und
vernichten Sie diese eMail. Jegliche Art der Verwendung, Vervielf=E4ltigung
=

oder Weitergabe ist nicht gestattet.

------_=_NextPart_001_01C46932.BE401AD0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<=21DOCTYPE HTML PUBLIC =22-//W3C//DTD HTML 4.0 Transitional//EN=22>
<HTML xmlns=3D=22http://www.w3.org/TR/REC-html40=22 xmlns:o =3D 
=22urn:schemas-microsoft-com:office:office=22 xmlns:w =3D 
=22urn:schemas-microsoft-com:office:word=22 xmlns:st1 =3D 
=22urn:schemas-microsoft-com:office:smarttags=22><HEAD>
<META HTTP-EQUIV=3D=22Content-Type=22 CONTENT=3D=22text/html; charset=3Diso-=
8859-1=22>
<TITLE>Message</TITLE>

<META content=3D=22MSHTML 6.00.2800.1400=22 name=3DGENERATOR><o:SmartTagType=
 name=3D=22City=22 
namespaceuri=3D=22urn:schemas-microsoft-com:office:smarttags=22></o:SmartTag=
Type><o:SmartTagType 
name=3D=22place=22 
namespaceuri=3D=22urn:schemas-microsoft-com:office:smarttags=22></o:SmartTag=
Type><o:SmartTagType 
name=3D=22PersonName=22 
namespaceuri=3D=22urn:schemas-microsoft-com:office:smarttags=22></o:SmartTag=
Type><=21--=5Bif =21mso=5D>
<STYLE>st1=5C:* =7B
	BEHAVIOR: url(=23default=23ieooui)
=7D
</STYLE>
<=21=5Bendif=5D-->
<STYLE>=40page Section1 =7Bsize: 8.5in 11.0in; margin: 1.0in 1.25in 1.0in 1.=
25in; =7D
P.MsoNormal =7B
	FONT-SIZE: 12pt; MARGIN: 0in 0in 0pt; FONT-FAMILY: =22Times New Roman=22
=7D
LI.MsoNormal =7B
	FONT-SIZE: 12pt; MARGIN: 0in 0in 0pt; FONT-FAMILY: =22Times New Roman=22
=7D
DIV.MsoNormal =7B
	FONT-SIZE: 12pt; MARGIN: 0in 0in 0pt; FONT-FAMILY: =22Times New Roman=22
=7D
A:link =7B
	COLOR: blue; TEXT-DECORATION: underline
=7D
SPAN.MsoHyperlink =7B
	COLOR: blue; TEXT-DECORATION: underline
=7D
A:visited =7B
	COLOR: purple; TEXT-DECORATION: underline
=7D
SPAN.MsoHyperlinkFollowed =7B
	COLOR: purple; TEXT-DECORATION: underline
=7D
P =7B
	FONT-SIZE: 12pt; MARGIN-LEFT: 0in; MARGIN-RIGHT: 0in; FONT-FAMILY: =22Times=
 New Roman=22; mso-margin-top-alt: auto; mso-margin-bottom-alt: auto
=7D
SPAN.EmailStyle17 =7B
	COLOR: windowtext; FONT-FAMILY: Arial; mso-style-type: personal-compose
=7D
DIV.Section1 =7B
	page: Section1
=7D
</STYLE>
</HEAD>
<BODY lang=3DEN-US vLink=3Dpurple link=3Dblue>
<DIV><FONT face=3DArial color=3D=230000ff size=3D2><SPAN 
class=3D356523623-13072004>Tobias,</SPAN></FONT></DIV>
<DIV><FONT face=3DArial color=3D=230000ff size=3D2><SPAN 
class=3D356523623-13072004></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial color=3D=230000ff size=3D2><SPAN class=3D356523623-1=
3072004>Thanks 
for this first draft. I've been lurking on this list for some time and now w=
ill 
offer my assistance and hope I don't overstep any bounds.</SPAN></FONT></DIV=
<DIV><FONT face=3DArial color=3D=230000ff size=3D2><SPAN 
class=3D356523623-13072004></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial color=3D=230000ff size=3D2><SPAN class=3D356523623-1=
3072004>I will 
gladly join the effort&nbsp;as a second author or editor. I do not pretend t=
o 
have the technical expertise you all do, but I can certainly offer technical=
 
guidance with business rules and system requirements. I work for the Nationa=
l 
Notary Association, by the way, so I'm confident I can provide assistance wi=
th 
understanding the need for Notary services to support our work as Notaries 
=

Public. I can also bridge this initial draft effort with work we're doing 
through the American Bar Association to define best practices for electronic=
 
notarization, as necessary or appropriate.</SPAN></FONT></DIV>
<DIV><FONT face=3DArial color=3D=230000ff size=3D2><SPAN 
class=3D356523623-13072004></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial color=3D=230000ff size=3D2><SPAN 
class=3D356523623-13072004>Because I'm new to this process, I'll need some 
=

guidance from you,&nbsp;Tobias, on how to proceed. I'm at your 
disposal.</SPAN></FONT></DIV>
<DIV><FONT face=3DArial color=3D=230000ff size=3D2><SPAN 
class=3D356523623-13072004></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial color=3D=230000ff size=3D2><SPAN class=3D356523623-1=
3072004>Take 
care,</SPAN></FONT></DIV>
<DIV><FONT face=3DArial color=3D=230000ff size=3D2><SPAN 
class=3D356523623-13072004></SPAN></FONT>&nbsp;</DIV>
<DIV align=3Dleft><FONT face=3DArial size=3D2><STRONG>Richard J. 
Hansberger</STRONG></FONT></DIV>
<DIV align=3Dleft><FONT face=3DArial size=3D2>eNotarization Manager</FONT></=
DIV>
<DIV align=3Dleft><FONT face=3DArial size=3D2>National Notary Association</F=
ONT></DIV>
<DIV align=3Dleft><FONT face=3DArial size=3D2>818-739-4027</FONT></DIV>
<BLOCKQUOTE dir=3Dltr style=3D=22MARGIN-RIGHT: 0px=22>
  <DIV></DIV>
  <DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr align=3Dleft><FON=
T 
  face=3DTahoma size=3D2>-----Original Message-----<BR><B>From:</B> Tobias G=
ondrom 
  =5Bmailto:tobias.gondrom=40ixos.de=5D <BR><B>Sent:</B> Tuesday, July 13, 2=
004 2:54 
  AM<BR><B>To:</B> ietf-ltans=40imc.org<BR><B>Subject:</B> LTANS: first draf=
t of 
  requirements for notary services<BR><B>Importance:</B> 
  High<BR><BR></FONT></DIV>
  <DIV class=3DSection1>
  <P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN 
  style=3D=22FONT-SIZE: 10pt; FONT-FAMILY: Arial=22>Hello,<o:p></o:p></SPAN>=
</FONT></P>
  <P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN 
  style=3D=22FONT-SIZE: 10pt; FONT-FAMILY: Arial=22><o:p>&nbsp;</o:p></SPAN>=
</FONT></P>
  <P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN 
  style=3D=22FONT-SIZE: 10pt; FONT-FAMILY: Arial=22>After a long pause we fi=
nished the 
  first draft =22requirements for notary services=22 and submitted it yester=
day 
  around 8:58 a.m. ET to IETF ;-)<o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN 
  style=3D=22FONT-SIZE: 10pt; FONT-FAMILY: Arial=22><o:p>&nbsp;</o:p></SPAN>=
</FONT></P>
  <P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN 
  style=3D=22FONT-SIZE: 10pt; FONT-FAMILY: Arial=22>Attached you find the 
  draft.<o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN 
  style=3D=22FONT-SIZE: 10pt; FONT-FAMILY: Arial=22>Please consider it reall=
y just as 
  the first draft to start the discussion of the future work of LTANS after =
we 
  complete the work on the long-term archiving (ERS, reqs and 
  prot).<o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN 
  style=3D=22FONT-SIZE: 10pt; FONT-FAMILY: Arial=22>I just started as the au=
thor and 
  would be really happy if a second author would like to join me, or even if=
 we 
  find another author/editor for this draft to replace me. (following 
  recommendations IETF considering the separation of the chair and editor 
  role)<o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN 
  style=3D=22FONT-SIZE: 10pt; FONT-FAMILY: Arial=22><o:p>&nbsp;</o:p></SPAN>=
</FONT></P>
  <P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN 
  style=3D=22FONT-SIZE: 10pt; FONT-FAMILY: Arial=22>So I hope this first dra=
ft is an 
  acceptable base to start the discussion on what is needed concerning notar=
y 
  services.<o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN 
  style=3D=22FONT-SIZE: 10pt; FONT-FAMILY: Arial=22><o:p>&nbsp;</o:p></SPAN>=
</FONT></P>
  <P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN 
  style=3D=22FONT-SIZE: 10pt; FONT-FAMILY: Arial=22>Best 
  regards<o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN 
  style=3D=22FONT-SIZE: 10pt; FONT-FAMILY: Arial=22><o:p>&nbsp;</o:p></SPAN>=
</FONT></P>
  <P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN 
  style=3D=22FONT-SIZE: 10pt; FONT-FAMILY: Arial=22>&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  Tobias<o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN 
  style=3D=22FONT-SIZE: 10pt; FONT-FAMILY: Arial=22><o:p>&nbsp;</o:p></SPAN>=
</FONT></P>
  <P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN 
  style=3D=22FONT-SIZE: 10pt; FONT-FAMILY: Arial=22><o:p>&nbsp;</o:p></SPAN>=
</FONT></P>
  <P><B><FONT face=3DArial size=3D2><SPAN 
  style=3D=22FONT-WEIGHT: bold; FONT-SIZE: 10pt; FONT-FAMILY: Arial=22>_____=
_____________________________________</SPAN></FONT></B> 
  <BR><st1:PersonName w:st=3D=22on=22><B><FONT face=3DArial color=3Dblack si=
ze=3D2><SPAN 
  style=3D=22FONT-WEIGHT: bold; FONT-SIZE: 10pt; COLOR: black; FONT-FAMILY: =
Arial=22>Tobias 
  Gondrom</SPAN></FONT></B></st1:PersonName><FONT face=3DArial color=3Dblack=
 
  size=3D2><SPAN 
  style=3D=22FONT-SIZE: 10pt; COLOR: black; FONT-FAMILY: Arial=22><BR>Senior=
 Software 
  Architect<BR>PPMA, Engineering<BR></SPAN></FONT><BR><B><FONT face=3DArial =

  color=3Dblack size=3D2><SPAN 
  style=3D=22FONT-WEIGHT: bold; FONT-SIZE: 10pt; COLOR: black; FONT-FAMILY: =
Arial=22>IXOS 
  SOFTWARE AG</SPAN></FONT></B><FONT face=3DArial color=3Dblack size=3D2><SP=
AN 
  style=3D=22FONT-SIZE: 10pt; COLOR: black; FONT-FAMILY: Arial=22><BR>Techno=
park 
  1<BR>Bretonischer Ring 12<BR>85630 Grasbrunn / <st1:place w:st=3D=22on=22>=
<st1:City 
  w:st=3D=22on=22>Munich</st1:City></st1:place></SPAN></FONT> <BR><FONT face=
=3DArial 
  color=3Dblack size=3D2><SPAN 
  style=3D=22FONT-SIZE: 10pt; COLOR: black; FONT-FAMILY: Arial=22>Phone:&nbs=
p; +49 (0) 
  89 4629-1816<BR>Telefax:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; +49 (0)=
 89 
  4629-33-1816<BR>eMail:&nbsp;</SPAN></FONT> <FONT face=3DArial size=3D2><SP=
AN 
  style=3D=22FONT-SIZE: 10pt; FONT-FAMILY: Arial=22><A 
  href=3D=22mailto:tobias.gondrom=40ixos.de=22>mailto:tobias.gondrom=40ixos.=
de</A><BR><FONT 
  color=3Dblack><SPAN 
  style=3D=22COLOR: black=22>Internet:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</=
SPAN></FONT></SPAN></FONT><U> 
  </U><U><FONT face=3DArial color=3Dblue size=3D2><SPAN 
  style=3D=22FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: Arial=22><A 
  href=3D=22http://www.ixos.com/=22>http://www.ixos.com/</A></SPAN></FONT></=
U> 
  <o:p></o:p></P>
  <P><FONT face=3DArial color=3Dblack size=3D2><SPAN 
  style=3D=22FONT-SIZE: 10pt; COLOR: black; FONT-FAMILY: Arial=22>This eMail=
 may 
  contain confidential and/or privileged information. If you are not the 
  intended recipient or have received this eMail in error, please notify the=
 
  sender immediately and destroy this eMail. Any use, disclosure or distribu=
tion 
  of the material in this eMail is strictly 
  forbidden.</SPAN></FONT><o:p></o:p></P>
  <P><FONT face=3DArial size=3D2><SPAN lang=3DDE 
  style=3D=22FONT-SIZE: 10pt; FONT-FAMILY: Arial=22>Diese eMail enth=E4lt ve=
rtrauliche 
  und/oder rechtlich gesch=FCtzte Informationen. Wenn Sie nicht der richtige=
 
  Adressat sind oder diese eMail irrt=FCmlich erhalten haben, informieren Si=
e 
  bitte sofort den Absender und vernichten Sie diese eMail. Jegliche Art der=
 
  Verwendung, Vervielf=E4ltigung oder Weitergabe ist nicht 
  gestattet.</SPAN></FONT><SPAN lang=3DDE><o:p></o:p></SPAN></P>
  <P class=3DMsoNormal><FONT face=3D=22Times New Roman=22 size=3D3><SPAN lan=
g=3DDE 
  style=3D=22FONT-SIZE: 12pt=22><o:p>&nbsp;</o:p></SPAN></FONT></P></DIV></B=
LOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C46932.BE401AD0--

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

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

----123456789-987654321-abcdefg--

Content-class: urn:content-classes:message
Subject: LTANS: first draft of requirements for notary services
Date: Tue, 13 Jul 2004 12:53:45 +0200
Importance: high
From: "Tobias Gondrom" <[email-masked]>
To: <[email-masked]>
Sender: [email-masked]

This is a multi-part message in MIME format.

------_=_NextPart_001_01C468C7.AB3849F0
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_002_01C468C7.AB3849F0"

------_=_NextPart_002_01C468C7.AB3849F0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hello,

=20

After a long pause we finished the first draft "requirements for notary =
services" and submitted it yesterday around 8:58 a.m. ET to IETF ;-)

=20

Attached you find the draft.

Please consider it really just as the first draft to start the =
discussion of the future work of LTANS after we complete the work on the =
long-term archiving (ERS, reqs and prot).

I just started as the author and would be really happy if a second =
author would like to join me, or even if we find another author/editor =
for this draft to replace me. (following recommendations IETF =
considering the separation of the chair and editor role)

=20

So I hope this first draft is an acceptable base to start the discussion =
on what is needed concerning notary services.

=20

Best regards

=20

            Tobias

=20

=20

__________________________________________=20
Tobias Gondrom
Senior Software Architect
PPMA, Engineering

IXOS SOFTWARE AG
Technopark 1
Bretonischer Ring 12
85630 Grasbrunn / Munich=20
Phone:  +49 (0) 89 4629-1816
Telefax:        +49 (0) 89 4629-33-1816
eMail:  mailto:[email-masked]
Internet:       http://www.ixos.com/=20

This eMail may contain confidential and/or privileged information. If =
you are not the intended recipient or have received this eMail in error, =
please notify the sender immediately and destroy this eMail. Any use, =
disclosure or distribution of the material in this eMail is strictly =
forbidden.

Diese eMail enth=E4lt vertrauliche und/oder rechtlich gesch=FCtzte =
Informationen. Wenn Sie nicht der richtige Adressat sind oder diese =
eMail irrt=FCmlich erhalten haben, informieren Sie bitte sofort den =
Absender und vernichten Sie diese eMail. Jegliche Art der Verwendung, =
Vervielf=E4ltigung oder Weitergabe ist nicht gestattet.

=20

------_=_NextPart_002_01C468C7.AB3849F0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

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

<head>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">

<meta name=3DGenerator content=3D"Microsoft Word 11 (filtered medium)">
<o:SmartTagType =
namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"
 name=3D"City"/>
<o:SmartTagType =
namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"
 name=3D"place"/>
<o:SmartTagType =
namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"
 name=3D"PersonName"/>
<!--[if !mso]>
<style>
st1\:*{behavior:url(#default#ieooui) }
</style>
<![endif]-->
<style>
<!--
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman";}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{color:purple;
	text-decoration:underline;}
p
	{mso-margin-top-alt:auto;
	margin-right:0in;
	mso-margin-bottom-alt:auto;
	margin-left:0in;
	font-size:12.0pt;
	font-family:"Times New Roman";}
span.EmailStyle17
	{mso-style-type:personal-compose;
	font-family:Arial;
	color:windowtext;}
@page Section1
	{size:8.5in 11.0in;
	margin:1.0in 1.25in 1.0in 1.25in;}
div.Section1
	{page:Section1;}
-->
</style>

</head>

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

<div class=3DSection1>

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

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

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>After a long pause we finished the first draft =
&#8220;requirements
for notary services&#8221; and submitted it yesterday around 8:58 a.m. =
ET to
IETF ;-)<o:p></o:p></span></font></p>

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

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>Attached you find the =
draft.<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>Please consider it really just as the first draft to =
start
the discussion of the future work of LTANS after we complete the work on =
the long-term
archiving (ERS, reqs and prot).<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>I just started as the author and would be really =
happy if a
second author would like to join me, or even if we find another =
author/editor for
this draft to replace me. (following recommendations IETF considering =
the separation
of the chair and editor role)<o:p></o:p></span></font></p>

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

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>So I hope this first draft is an acceptable base to =
start
the discussion on what is needed concerning notary =
services.<o:p></o:p></span></font></p>

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

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

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

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

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

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

<p><b><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial;
font-weight:bold'>__________________________________________</span></font=
></b> <br>
<st1:PersonName w:st=3D"on"><b><font size=3D2 color=3Dblack =
face=3DArial><span
 =
style=3D'font-size:10.0pt;font-family:Arial;color:black;font-weight:bold'=
>Tobias
 Gondrom</span></font></b></st1:PersonName><font size=3D2 color=3Dblack =
face=3DArial><span
style=3D'font-size:10.0pt;font-family:Arial;color:black'><br>
Senior Software Architect<br>
PPMA, Engineering<br>
</span></font><br>
<b><font size=3D2 color=3Dblack face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial;color:black;font-weight:bold'>IXOS SOFTWARE =
AG</span></font></b><font
size=3D2 color=3Dblack face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial;
color:black'><br>
Technopark 1<br>
Bretonischer Ring 12<br>
85630 Grasbrunn / <st1:place w:st=3D"on"><st1:City =
w:st=3D"on">Munich</st1:City></st1:place></span></font>
<br>
<font size=3D2 color=3Dblack face=3DArial><span =
style=3D'font-size:10.0pt;font-family:
Arial;color:black'>Phone:&nbsp; +49 (0) 89 4629-1816<br>
Telefax:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; +49 (0) 89 =
4629-33-1816<br>
eMail:&nbsp;</span></font> <font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'><a =
href=3D"mailto:[email-masked]">mailto:[email-masked]</a><=
br>
<font color=3Dblack><span =
style=3D'color:black'>Internet:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</span=
></font></span></font><u>
</u><u><font size=3D2 color=3Dblue face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial;color:blue'><a =
href=3D"http://www.ixos.com/">http://www.ixos.com/</a></span></font></u>
<o:p></o:p></p>

<p><font size=3D2 color=3Dblack face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial;color:black'>This eMail may contain confidential =
and/or
privileged information. If you are not the intended recipient or have =
received
this eMail in error, please notify the sender immediately and destroy =
this
eMail. Any use, disclosure or distribution of the material in this eMail =
is
strictly forbidden.</span></font><o:p></o:p></p>

<p><font size=3D2 face=3DArial><span lang=3DDE =
style=3D'font-size:10.0pt;font-family:
Arial'>Diese eMail enth=E4lt vertrauliche und/oder rechtlich =
gesch=FCtzte
Informationen. Wenn Sie nicht der richtige Adressat sind oder diese =
eMail
irrt=FCmlich erhalten haben, informieren Sie bitte sofort den Absender =
und
vernichten Sie diese eMail. Jegliche Art der Verwendung, =
Vervielf=E4ltigung oder
Weitergabe ist nicht gestattet.</span></font><span =
lang=3DDE><o:p></o:p></span></p>

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

</div>

</body>

</html>

------_=_NextPart_002_01C468C7.AB3849F0--

------_=_NextPart_001_01C468C7.AB3849F0
Content-Type: text/plain;
	name="draft-ietf-ltans-notareqs-00.txt"
Content-Transfer-Encoding: base64
Content-Description: draft-ietf-ltans-notareqs-00.txt
Content-Disposition: attachment;
	filename="draft-ietf-ltans-notareqs-00.txt"

------_=_NextPart_001_01C468C7.AB3849F0--