Re: [dss] Pending / TryAgainLater

[Trevor Perrin <trevp@trevp.net>]

At 12:35 AM 4/8/2004 +0200, Andreas Kuehne wrote:
>Hi again !
>
>>> > Another possibility is to have a single, separate Async Profile.  This
>>> > would make it clear what the approved way of doing asychronous operation
>>> > is, hopefully avoiding the confusion you mention.
>>>Do you think of another horizontal profile ?
>>
>>
>>yeah, that's what I was thinking.  (and I see Nick agrees with this).
>
>Hmm,  makes me afraid of the "combinatory explosion" a bit more ...

That's a fair concern.  I think we should wait and see if the problem 
occurs in practice though, before getting too worried about it.


[...]
>Sadly the awkward case is my usual case : In my favorite use case the 
>invoices ( several thousands )  drop out of a batch job or a message 
>queue. These processes usually don't carry any authentication information. 
>Especially they don't know anything about the guy plugging in his key 
>cards and typing his pin code into the card terminal.

Is this the use case? -
  - Thousands of invoices are generated by a client
  - The client submits the invoices to a signing server (which has no 
private key)
  - The server stores the invoices
  - Sometime later, someone with a smartcard comes along, plugs his card 
into the server, and signs the invoices
  - The client is notified to retrieve the signed invoices
  - The client retrieves them

If so, I assume the person with the smartcard isn't actually reviewing the 
invoices and signing requests (there's thousands of them).  So it might not 
be necessary to have a full, asynchronous protocol.  Consider this instead:
  - Thousands of invoices are generated by a client
  - The client stores the invoices
  - Sometimes later, someone with a smartcard comes along and plugs his 
card into the server
  - The client is notified that the server is ready for signing
  - The client performs normal, synchronous, DSS requests with the server.

In the first scenario, the DSS protocol is split in half, with the request 
and response at different times.  In the second scenario, some non-DSS 
mechanism is used to signal "ready-for-signing", allowing a vanilla DSS 
exchange to be used.

I may not have your use case exactly right, but I think the idea of using 
DSS synchronously as one component of a larger, asynchronous process may be 
a good general approach, instead of trying to stretch DSS to be asynchronous.

The "TryAgainLater" code could be viewed as a way of accomplishing the same 
thing - by making the server able to recognize repeat requests, we allow an 
asynchronous process to be built out of the plain, synchronous DSS protocol.


>Anyway, if we got the lucky case of the having the card holder sending a 
>signing request he may authenticate hisself. But in no case he would 
>expose his pin code. So for generating the signature using the key card a 
>second step has to performed ! Moreover the signature law explicitly 
>postulates the commitment / time slot procedure.

Out of curiosity, is that in one of these documents?:
http://www.regtp.de/imperia/md/content/tech_reg_t/digisign/119.pdf
http://www.regtp.de/imperia/md/content/tech_reg_t/digisign/120.pdf


Trevor