Discussion of notareqs document

[Larry Masinter <LMM@xxxxxxx>]

(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