Discussion of notareqs document

Larry Masinter <LMM@acm.org> Wed, 27 October 2004 16:00 UTC

Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9RG09bU095165; Wed, 27 Oct 2004 09:00:09 -0700 (PDT) (envelope-from owner-ietf-ltans@mail.imc.org)
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9RG090G095164; Wed, 27 Oct 2004 09:00:09 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f
Received: from psmtp.com (exprod6ob4.obsmtp.com [64.18.1.214]) by above.proper.com (8.12.11/8.12.9) with SMTP id i9RG09H2095135 for <ietf-ltans@imc.org>; Wed, 27 Oct 2004 09:00:09 -0700 (PDT) (envelope-from LMM@acm.org)
Received: from source ([192.150.22.8]) by exprod6ob4.obsmtp.com ([64.18.5.12]) with SMTP; Wed, 27 Oct 2004 08:59:30 PDT
Received: from inner-relay-3.corp.adobe.com (inner-relay-3 [153.32.251.51]) by smtp-relay-8.adobe.com (8.12.10/8.12.10) with ESMTP id i9RFxo85021425 for <ietf-ltans@imc.org>; Wed, 27 Oct 2004 08:59:55 -0700 (PDT)
Received: from calsj-dev (calsj-dev.corp.adobe.com [153.32.1.193]) by inner-relay-3.corp.adobe.com (8.12.9/8.12.9) with ESMTP id i9RFxo0U025183 for <ietf-ltans@imc.org>; Wed, 27 Oct 2004 08:59:50 -0700 (PDT)
Received: from MasinterT40 ([130.248.178.62]) by mailsj-v1.corp.adobe.com (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTP id <0I69003IU33PK7@mailsj-v1.corp.adobe.com> for ietf-ltans@imc.org; Wed, 27 Oct 2004 08:59:50 -0700 (PDT)
Date: Wed, 27 Oct 2004 08:59:49 -0700
From: Larry Masinter <LMM@acm.org>
Subject: Discussion of notareqs document
In-reply-to: <417F760B.3030303@edelweb.fr>
To: ietf-ltans@imc.org
Message-id: <0I69003IV33PK7@mailsj-v1.corp.adobe.com>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
X-Mailer: Microsoft Office Outlook, Build 11.0.6353
Content-type: text/plain; charset="iso-8859-1"
Thread-index: AcS8EQeHzNmztPZBTaOxPCVvEq0kkwAJ9+Xw
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i9RG09H2095159
Sender: owner-ietf-ltans@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-ltans/mail-archive/>
List-Unsubscribe: <mailto:ietf-ltans-request@imc.org?body=unsubscribe>
List-ID: <ietf-ltans.imc.org>

(Note that my email said    'draft-ietf-ltans-notareq-01' but
the actual document name is 'draft-ietf-ltans-notareqs-01'
with an s; the internet-drafts editor fixed this).

I think there is no problem changing the title again to
"Data Validation and Certification Service Requirements".

On the technical content of the document, I am hoping we
can have a good discussion at the IETF meeting about some
of these points:

Use cases:

The use cases in the document are fairly general. We've had
some suggestions for more specific use cases, from Paul-André Pays:
-  validation of an X.509 certificate
-  validation of a receipt notification by a Long-Term Archive service
-  "approval" of a document at a given time by at least 67% of
    the members of a given list of users
and from Peter Sylvester (originally at IETF Vienna):
-  Certify three events of an SMIME message sent
   (prepare message, receipt of message, receipt of acknowledgement)

If we are to include these, we will need to describe them
clearly. Are there any problems with including these?

* Are there other use cases?
* Should any of the use cases be omitted?
* What other elements of these use cases should be elaborated?
  (I think it would be useful to elaborate the 'long term' 
  elements of the use cases, e.g., "after 10 years, someone
  needs to prove A having sent the message")

Requirements:

What are the actual requirements corresponding to these use
cases, as far as the network protocol or data structures necessary
to communicate with an agent performing these services?
I think we want to document requirements in the same way that
we've been moving the long-term archive requirements document.

Security considerations:

I think a "Long-Term" service needs some expansion about the requirements
for long-term security. For example, over a 30-year period, what is
feasible with a "brute force" attack is different than what might be
expected over a 2-year period, because of indetermined increases in
computing power available to attackers, and the sheer amount of time
available to do brute force.

Operational considerations:

It seems that there are two main purposes to this section -- to
be clear about the scaling and performance requirements, and to
lay out the operational security measures necessary. I think this
could be clearer in the document.

References:

I had meant to add references to DVCS and ERS and to reference
them in the introduction as some prior work in the area.
And the reference to the long-term archive requirements could
be to RFC XXXX assuming it will be published first (or at least,
simultaneously).

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