|
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.
-- Carl Wallace -- a dit, - le 27/10/2004
19:22:
<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.
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)
--
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.
|
|