Subject: RE: Discussion of notareqs document

From: Peter Sylvester <[email-masked]>
Date: Wed, 3 Nov 2004 15:45:30 +0100 (MET)

> 
> 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 ..

---

From: Peter Sylvester <[email-masked]>
Date: Wed, 3 Nov 2004 16:09:42 +0100 (MET)

> 
> OK, understand and agree on that. But the "premium" service is still a problem.
> Some (business) scenarios are build around short lifetimes of documents (e.g.
> tax declaration, valid for one year). This approach fails. I thnik we should
> expose the problem in some of the documents and at least provide conceptual
> approaches (or limitations) to solve them.
> 
I agree with the last sentence.

But a solution may be different than expected similar as with New York's problem
 of horse shit a century ago. :-)

A signature on a paper based income declaration has almost no meaning concerning
security. It is never verified. As soon as you accept to pay taxes according
to what you receive as a "receipt" of your tax declaration, you confirm
yourself the validity of your "signature" which still is not verified but
the fiscal service may only deduce that if they find out that you haven't
declared everything you had "two chances to lie".

A digital signature on a "income declaration" thus seems totally unnecessary,
it is in fact only a means to limit the number of multiple declaration for the
same 'customer', which by each occurence is not a problem because it can
be resolved, but their is the simple interest to limit the number of such cases. 

In all short term scenarios you have some more or less immediate reaction
with 'the customer' who in one or the other way will confirm the validity
of the signature if the transaction is initiated by the customer.

For a 'tax declaration', i.e. the statement from the state ...
someone else can explain the requirements?

---

From: Peter Sylvester <[email-masked]>
Date: Wed, 3 Nov 2004 19:00:20 +0100 (MET)

> 
> >
> > Aleksej,
> >
> > The archive package should contain the CRL used to verify the transaction.
> > That coupled with other times will show when the transaction was received
> > and processed.
> >
> > When speed is of not essence, the relying party can always wait for a CRL
> > issued after the transaction was received to verify.  This will ensure that
> > the certificate was not revoked in the interim.  Relying party can use the
> > later CRL for archiving the transaction.

IMO opinion it doesn't give additional value waiting for a new CRL without 
doing anything in the meantime. If the *impact/effect* of the signatures in question
are not  confronted to the user in some way, a user may not even think about 
the possibility to revoke a cert. (I am talking about a signature
made at distance.)

Then there are also consumer rights with delays. The fact that a signature
has been validated with this or that CRL probably doesn't influence at all
the rights, even if the signature is proven valid, 100% safe or whatever.
(Well the latter was the dream of the banks and merchants).

The user does not have to revoke a cert, he can 'revoke/repudiate' the action
or document.