Subject: Document submitted for draft-ietf-ltans-notareq-01.txt

From: Larry Masinter <[email-masked]>
Date: Fri, 22 Oct 2004 16:10:59 -0700

After some discussion with co-editors of the document (and some
subsequent reorganization on my own), I've submitted a new
version of the 'notareq' document.

The title is now 'Requirements for Certification Services'.

Most of the document is significantly rewritten. There is still
need for quite a bit of work.

If you would like a preview before the internet draft is
available, you may find this at:

http://larry.masinter.net/ltans-notary-req.txt (plain text, what was
submitted)
http://larry.masinter.net/ltans-notary-req.xml (source xml, should view)
http://larry.masinter.net/ltans-notary-req.html (html transformation)

Larry

---

From: Denis Pinkas <[email-masked]>
Date: Mon, 25 Oct 2004 09:35:25 +0200

Larry,

> The title is now 'Requirements for Certification Services'.

This new title will add even more confusion with the PKIX working group.
Once you proposed:

"Data Validation and Certification Protocol Requirements".

The word "data" has been dropped in the new proposal.

"Requirements for Data Certification Services" could be appropriate,
but "Requirements for Certification Services" is not.

Denis

---

From: Larry Masinter <[email-masked]>
Date: Mon, 25 Oct 2004 09:28:56 -0700

> This new title will add even more confusion with the PKIX 

I'm sorry about the confusion over the title. We had put off
working through the document, so there was some rush to get
a new version out.

I'm a little uneasy about "Data Validation and Certification"
because in many of the use cases, the thing being validated
or certified isn't so much "data" as it is an "event" -- an
oath was administered, an agreement was understood, etc.

If we keep these use cases, can you think of other alternatives?

Larry

---

From: Paul-André PAYS <[email-masked]>
Date: Mon, 25 Oct 2004 18:59:25 +0200

>oath was administered, an agreement was understood, etc.
On one hand, you are right, in many cases what will be certified will 
not be an document, but as you say a fact or an event, but on the other 
hand, we are dealing with information systems and "facts" or "events" 
will have to be represented and it will be by some "data" (a combination 
of what, when, by whom ...)

As far as my understanding of the english language is correct, "data", 
as being the more general word(even vague, here it is a clear advantage 
over a more "accurate" or "connotated" term) is definitely the more 
appropriate.

We can probably have a shortexplanation in the foreword of the document, 
stating that in this document the word "data" has to be understood as 
the "electronic representation" of a "fact" (or "event") .
One specific case of such a "fact" is the submission or validation of a 
document at a given date and time (optionnaly by a specific user), one 
specific subcase being the validation of a X.509 certificate.
Another case being for example the receipt notification by a Long Term 
Archive service,
or the the "approval" of a document at a given time by at least 67% of 
the members of a given list of users.

Regards,

-- PAP

-- 
Edelweb
	Groupe ON-X Pôle Sécurité
[email-masked] 	[email-masked]
http://www.edelweb.fr/ 	http://www.on-x.com/

Tel. + 33 1 40 99 14 14. Fax. +33 1 40 99 99 58 -- Adresse : 15, quai de 
Dion Bouton  -  92816 Puteaux cedex
Pour vérifier la signature électronique, http://edelpki.edelweb.fr/ vous 
permet d'obtenir le certificat de l'autorité et la LCR.

---

From: Denis Pinkas <[email-masked]>
Date: Wed, 27 Oct 2004 09:48:39 +0200

Paul-André,

You said:

"We can probably have a shortexplanation in the foreword of the document, 
stating that in this document the word "data" has to be understood as the 
"electronic representation" of a "fact" (or "event")."

This is fully correct and I support this.

However thenafter you added:

"One specific case of such a "fact" is the submission or validation of a 
document at a given date and time (optionnaly by a specific user), one 
specific subcase being the validation of a X.509 certificate".

I wonder about this.

Someone (e.g. a notary) can testify hundreds of facts or events. There are 
millions of such facts or events. So we should neither focus on "submission 
or validation of a document at a given date and time" nor on "validation of 
a X.509 certificate".

Denis

---

From: Paul-André PAYS <[email-masked]>
Date: Wed, 27 Oct 2004 12:18:51 +0200

-- Denis Pinkas --  a dit,  - le 27/10/2004 09:48:

>
> Paul-André,
>
> You said:
>
> "We can probably have a shortexplanation in the foreword of the 
> document, stating that in this document the word "data" has to be 
> understood as the "electronic representation" of a "fact" (or "event")."
>

perfect

> "One specific case of such a "fact" is the submission or validation of 
> a document at a given date and time (optionnaly by a specific user), 
> one specific subcase being the validation of a X.509 certificate".
>
> I wonder about this.
>
> Someone (e.g. a notary) can testify hundreds of facts or events. There 
> are millions of such facts or events. So we should neither focus on 
> "submission or validation of a document at a given date and time" nor 
> on "validation of a X.509 certificate".

I never said that the groupe "should focus" on "validation of a 
certificate" and I am sorry if my wording was so obscure that it could 
be understood as such.
Nevertheless, I still pretend that  the ability to obtain from a "Data  
Certification Service" some form of "evidence", by means of a "data 
cert" (dated and signed by the DCS authority) that one has indeed 
verified at a given date and time that an X.509 certificate was checked 
and validated is indeed one example of "user's requirement" from such a 
service.
Don't read that this should be the goal (main goal, unique goal) of  
LTANS, just that it cann't be excluded and it makes sense in addition to 
such services as OCSP. The "data cert" will "prove" for example that the 
signature attached to a given document had been verified by a specific 
user, at a given date (different from the signature date) using a given 
"validation service".  The actual role of the "Data Certification 
Service" will not be to perform "itself" the validation work but to 
certify that is has been done in the specific context (that is the 
"fact" that is certified")

Same could be said about "document validation and submission", the role 
of the DCS must be to deliver such a data cert and need not to include 
the actual perfomance of the validation itself. Exactly as a "notary" 
could establish a certificate that one of is customers has deposited 
some amount of money at a bank for a specific purpose, that the 
banknotes had been validated -by the bank- and that this bank has 
delivered a receipt. The "data-cert" certifies a fact and comes in 
addition to the bank receipt.

This being said, for the purpose of sharing the understanding, I agree 
that that mentionning "X509 certs validation" too early in the document 
and as a purpose and not as an example might be confusing, and I 
certainly do no invite the group to mention this use case event if I 
still claim that it belongs to the myriads of use cases relevant of such 
a service.

regards,

-- PAP

>> not be an document, but as you say a fact or an event, but on the 
>> other hand, we are dealing with information systems and "facts" or 
>> "events" will have to be represented and it will be by some "data" (a 
>> combination of what, when, by whom ...)
>>
>> As far as my understanding of the english language is correct, 
>> "data", as being the more general word(even vague, here it is a clear 
>> advantage over a more "accurate" or "connotated" term) is definitely 
>> the more appropriate.
>>
>> We can probably have a shortexplanation in the foreword of the 
>> document, stating that in this document the word "data" has to be 
>> understood as the "electronic representation" of a "fact" (or "event") .
>> One specific case of such a "fact" is the submission or validation of 
>> a document at a given date and time (optionnaly by a specific user), 
>> one specific subcase being the validation of a X.509 certificate.
>> Another case being for example the receipt notification by a Long 
>> Term Archive service,
>> or the the "approval" of a document at a given time by at least 67% 
>> of the members of a given list of users.
>>
>> Regards,
>>
>> -- PAP
>>
>> Tel. + 33 1 40 99 14 14. Fax. +33 1 40 99 99 58 -- Adresse : 15, quai 
>> de Dion Bouton  -  92816 Puteaux cedex
>> Pour vérifier la signature électronique, http://edelpki.edelweb.fr/ 
>> vous permet d'obtenir le certificat de l'autorité et la LCR.
>>
>>
>>
>
>
>
>
>

---

From: Larry Masinter <[email-masked]>
Date: Wed, 27 Oct 2004 08:59:49 -0700

(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

---

From: "Carl Wallace" <[email-masked]>
Date: Wed, 27 Oct 2004 13:22:54 -0400

<snip>
> * Should any of the use cases be omitted?

I don't think we should include a use case that simply consists of reporting
the validation status of an X.509 certificate.  SCVP is well underway and
serves that purpose.  That cert validity is reported as part of a data
certification operation seems OK but establishing an alternative to SCVP is
not in our scope.

---

From: Paul-André PAYS <[email-masked]>
Date: Wed, 27 Oct 2004 19:55:36 +0200

>certification operation seems OK but establishing an alternative to SCVP is
I fully agree, but the use case I presented and proposed -in my last mail- :

    * is not "/simply of reporting the validation status of an X.509
      certificate/"
    * is not "Yet Another SCVP"
    * but extend (and possibly encompass) the service rendered by SCVP
      or any other, in order to meet the end user's requirement :
      obtaining a certification (some form of "proof" valid for long
      term use) by some external "authority" (not to say notary or
      e-notary) (of the "fact" that s/he has actually used a validation
      service (such as SCVP) and be assured that the "DVC service" (or
      ntotary) will keep a detailed and certified -and securely
      archived- log entry of this request. 
    *

By the way, (and not limited to the above use case) this is one element 
of solution against the threat for the long term that the original 
certifying keys could be broken some day (before the end of this long term!)

    * a SCVP report could be forged 20 years after the effective date
    * BUT, it will be much more difficult to forge -and in a consistent
      way- also the "DVC data cert" and the "secure and archived log
      entries".

This is another proof of the sound approach of LTANS which links "data 
certs" and "secure archived". Any "data cert" must not only be signed, 
but a detailed log entry must be archived in a secure way (non 
rewritable medium, hash linking). This mandatory combination was a major 
rationale of the openevidence project (/the technical solution by then 
was a a combination of TSP RFC3061, DVCS RFC3029 and hash-linking/)

---

From: "Carl Wallace" <[email-masked]>
Date: Wed, 27 Oct 2004 15:07:24 -0400

I don't think we are in disagreement.  I was not responding to your last
email but to Larry's question regarding whether any of the listed use cases
should be omitted.  You seem to agree that a use case targeting validation
of an X.509 certificate is beyond our scope.  I agree what you describe
below is within our scope.

  _____  

From: [email-masked] [mailto:[email-masked]]
On Behalf Of Paul-André PAYS
Sent: Wednesday, October 27, 2004 1:56 PM
To: Carl Wallace
Cc: [email-masked]
Subject: Re: Discussion of notareqs document

 <snip>

not in our scope.

*	is not "simply of reporting the validation status of an X.509
certificate" 

*	but extend (and possibly encompass) the service rendered by SCVP or
any other, in order to meet the end user's requirement : obtaining a
certification (some form of "proof" valid for long term use) by some
external "authority" (not to say notary or e-notary) (of the "fact" that
s/he has actually used a validation service (such as SCVP) and be assured
that the "DVC service" (or ntotary) will keep a detailed and certified -and
securely archived- log entry of this request.  

*	

By the way, (and not limited to the above use case) this is one element of
solution against the threat for the long term that the original certifying
keys could be broken some day (before the end of this long term!)

*	BUT, it will be much more difficult to forge -and in a consistent
way- also the "DVC data cert" and the "secure and archived log entries". 

This is another proof of the sound approach of LTANS which links "data
certs" and "secure archived". Any "data cert" must not only be signed, but a
detailed log entry must be archived in a secure way (non rewritable medium,
hash linking). This mandatory combination was a major rationale of the
openevidence project (the technical solution by then was a a combination of
TSP RFC3061, DVCS RFC3029 and hash-linking)

-- 

Edelweb
<http://edelpki.edelweb.fr/> vous permet d'obtenir le certificat de
l'autorité et la LCR.

---

From: Denis Pinkas <[email-masked]>
Date: Thu, 28 Oct 2004 15:39:03 +0200

Paul-André,

(text deleted)

> rationale of the openevidence project (the technical solution by then 
> was a a combination of TSP RFC3061, DVCS RFC3029 and hash-linking)

There is no such mandatory comnbination for LTANS: data needs to be signed 
(and time-stamped) by the archive service, but the log is not intended to be 
used as an evidence.

Denis

---

From: Paul-André PAYS <[email-masked]>
Date: Thu, 28 Oct 2004 17:17:40 +0200

-- Denis Pinkas --  a dit,  - le 28/10/2004 15:39:

>
> Paul-André,
>
> (text deleted)
>
>> This is another proof of the sound approach of LTANS which links 
>> "data certs" and "secure archived". Any "data cert" must not only be 
>> signed, but a detailed log entry must be archived in a secure way 
>> (non rewritable medium, hash linking). This mandatory combination was 
>> a major rationale of the openevidence project (the technical solution 
>> by then was a a combination of TSP RFC3061, DVCS RFC3029 and 
>> hash-linking)
>
>
> There is no such mandatory comnbination for LTANS: data needs to be 
> signed (and time-stamped) by the archive service, but the log is not 
> intended to be used as an evidence.

I am exactly suggesting that it be.

We are preparing a *requirements document* and not some "a posteriori" 
rationale for a given protocol or service.  My strong suggestion, based 
on several years activities for several customers, is indeed that the 
"certified archival" of "detailed and signed" log is a "must" for a 
large majority of actual applications and uses cases.

What the most "educated" or aware customers do require is a complete set 
of "evidence management" services. (/What they call in France "Gestion 
de la Preuve" or "Administration de la Preuve"; what they will be able 
to exhibit in order to dissuade "others" to initiate a litigation, or 
whenever unsuccessfull, what they will be able to exhibit as evidence 
elements in a court/).

My personal view of the whole justification of LTANS  context is, as I 
am convinced that this type of requirements will be generalized, that 
the IETF succeeds in proposing and establishing standards that wil enable :

   1. technical interop between business partners
   2. technical interop between solution providers
   3. the judges and their expert to master the e-material (because it
      conforms to standard and because there exist tools enbling to
      manipulate them)
   4. the possibility of mutual recognition within a business community

And I have no longer any doubt that  "certified archived logs" (more or 
less equivalent of the certified archival of requests and receipts) will 
be one of, if not, the most usefull component.

---

From: Denis Pinkas <[email-masked]>
Date: Thu, 28 Oct 2004 17:29:45 +0200

Paul-André,

Unfortunately, we have quite opposite personal views.

Denis

> We are preparing a requirements document and not some "a posteriori" 
> of "evidence management" services. (What they call in France "Gestion de 
> la Preuve" or "Administration de la Preuve"; what they will be able to 
> exhibit in order to dissuade "others" to initiate a litigation, or 
> elements in a court).