>
> Carl,
>
> > Regarding WG focus, the recent shift in requirements focus has been w.r.t.
> > to the "notary" requirements. The long-term archive requirements focus on
> > the types of concerns you mention. That focus has been relatively stable
> > for some time, though the requirements document itself is still evolving.
>
> II know that, but correct me if I am wrong: e-notaries were shifted to
> certification services (and this is not the real point), which should provide
> among other things some attestation on validity of digital signatures. How this
> validity is delivered is a crucial question. There might be a DVCS-like service
> but the service itself should provide enough information by itself to prove
> that a signature was valid at T1 and not wait until T4. DVCS does provide some
> attestation, but it is not clear (at least to me), how the attestation is
> actually generated. Can we take DVCS response as "enough information" to
> enclose it to a signature and pack everything? Peter?
There are several aspects:
- I think it is not a good statement to say taht one has to prove that
a signature was good at some time, but rather that one assert having performed
a particular validation, and it succeeded.
- IMO opinion there is no reason to wait for a CRL for example. If a relying party
just waits, and has no interaction with the user, I don't think that the
possibility to determine better whether a signature is valid is enhanced.
If the 'signer' is never be confronted with the signature, no problem will
be detected, and there is no motivation for revoking a cert.
- There are context where consumer rights come into action. In this case
it is important to determine when certain delays start, I am pretty sure that
is is not sufficient for a relying party to timestamp sopmething in privacy,
and confront a user after the delay.
Within a delay, a user can 'revoke' the document, without revoking his signing
certificate.
- Technically the DVCS protocol is neutral about what is actually certified.
The idea behind a DVCS attestation concerning a 'signed document' is to
perform the validity checking at some time and provide *ALL* information
that had been used to do this, i.e., CRLs, OCSP responses, SCVP reponses,
DVCS responses, etc. and indicate a time. Anyone in possession of such
an attestation can perform the same validaton
This approach responds to 'keeping track of a validation act' and the
provision of all information. One can combine this with a signature in a
similar way as the advance signature formats timestamp. The attestation
asserts more than a time stamp since the attesting entity has actually
seen a document that corresponds.
The notarisation action and the attestation can include an reponse from
some archiver (I try to avoid the usage of the word "attestation from an archiver")
because the degree of security (expressed by an security envelope) of this
archiving attestation may vary, the notarisation could just include
an unsigned response if archiver and "notariser" are the same entities.
- This usage of a DVCS like service is a bit contrary to the needs of notaries
where they serve as information reduction entities. But then, it is
for example possible that one takes the elements described in the previous
point, archive them, and just return a statement, saying 'All is ok, if
details are necessary, they have been archived at XXX under reference RRR'.
- Now I don't know what you ask with 'how is the attestation actually generated'?
At least it seems to be that it can either contain all information or reference
them.
> > Regarding signature preservation, as discussed so far, an evidence record is
> > relative to a single time T1, e.g. the time of submission to the archive.
> > Retroactive revocation would need to be considered before committing the
> > data to an archive and initiating an evidence record (using the mechanisms
> > that have been discussed so far). Even if a CRL were issued immediately
> > when a cert was revoked, it's revocation time might be before T1.
>
> Well that is the general problem. Legislation states that post-festum revocation
> is not allowed, meaning the time of revocation can not be defined before the
> time when revocation was requested. It may take some time before next CRL is
> published, so when this information is published is the main issue. If we
> consider that time stops at the time of processing, some attestation could be
> produced. The practice? I am not sure....
>
> Also, TAS performs its own validation at time T1 and by that states that
> signature existed at T1. Post-festum validation should only provide information
> that nothing really happened before T1....
>
> I don't
> > believe I heard anyone discuss using an evidence record to verify a
> > signature relative to multiple points in time (that could get ugly). It
> > seems unlikely that retroactive revocation applied after several periodic
> > refresh operations (which should be relatively infrequent) at time T4 should
> > invalidate a signature generated at, or before, time T1.
>
> Well, I am afraid exactly of that. See my answer to Santosh - I am not stating
> that this is the way to go, I just would like to clear up this issue before
> some concrete steps forward are made. We have been playing with implementation
> of second generation of TAS but this problems causes headaches, not to mention
> the fulfillment of LTANS data grouping requirement... The main outcome I would
> like to see is at least a common understanding of the problem and some
> conclusions on how to manage such data.
Such problems occur as a side quark when trying to make a 100% secure signing device
and a requirement of impossibility of non-repudiation.
I think it is sufficient to determine the validity of a signature *NOW* and then
shift to whatever the transaction processing foresees. Later revocation does not
automatically invalidate the signature i.e. the associated engagement. And a
successful verification does not inhibit a subsequent repudiation ..