Subject: Comments on LTANS documents

From: Denis Pinkas <[email-masked]>
Date: Tue, 20 Jul 2004 09:34:59 +0200

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

---

From: "Santosh Chokhani" <[email-masked]>
Date: Tue, 20 Jul 2004 10:33:54 -0400

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

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 difference between the above "players" should be introduced in the 
documents.

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

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

The concept of a "proof of deposit" 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:

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

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.

deposited data.

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.

goals) of this document.

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

Denis

---

From: Larry Masinter <[email-masked]>
Date: Fri, 30 Jul 2004 22:35:48 -0700

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
-- 
http://larry.masinter.net

---

From: Larry Masinter <[email-masked]>
Date: Fri, 30 Jul 2004 22:49:29 -0700

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

---

From: Larry Masinter <[email-masked]>
Date: Fri, 30 Jul 2004 22:56:56 -0700

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

> 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

---

From: Jeff Williams <[email-masked]>
Date: Sat, 31 Jul 2004 01:41:01 -0700

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.

> clearer, and the choices are usually fairly arbitrary.

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: Jeff Williams <[email-masked]>
Date: Sat, 31 Jul 2004 01:48:48 -0700

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.

Regards,

---

From: "Santosh Chokhani" <[email-masked]>
Date: Sat, 31 Jul 2004 08:19:32 -0400

Larry:

I agree with you.

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

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

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

---

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

(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,
>

---

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

Larry and all,

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

> about their positioning.

  Agreed.

> It would seem that the business of
> 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?

> kinds of terms, because you'll be judging compliance of your

Yes understood.

> # structures and protocols for the secure usage of the necessary archive

  Right.

> and not on the protocol for accessing them.

  Yes "Some"!

> means of guaranteeing what they say they guarantee.

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

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

> 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

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

Regards,