Re: [dss] Pending / TryAgainLater

[Andreas Kuehne <kuehne@klup.de>]

Hi Trevor !

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

Maybe it's too late, then ...

 
>> 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
Hey, you got it !!


 
> If so, I assume the person with the smartcard isn't actually reviewing 
> the invoices and signing requests (there's thousands of them).  

No, of course he doesn't. BUT : He has to have the chance (!) to look at it ! This is an explicit demand of the sig law §17,(2).

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

Again it's §17 (2) : The card guy usually doesn't wait at the signing server console for documents to check. So it's the accepted practice to 
store documents on the signing server in a special 'inbox' for a ( theoreticial ) review. After a review period the documents from the inbox 
were forwardedmto the signing unit. This timeslot spans usally several hours. So the signing process lasts some hours at least. This demands 
asynchronity !



> 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.
In modern environments you'll may be able to resolve asynch problems by delegating it to the client. But for the sake of easy integration I would demand a flexible signing server, able to handle asynch requests. Especially if it introduces the problem itself.
 
> 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
Yes, but usually it's bit hidden :


'Chance to look at document' : 119.pdf, Section 17 (2) and 119.pdf, Section 15 (2) 1.c
'Key on signing card' : 119.pdf, Section 15 (7). Only Signing Cards comply with the mentioned regulations.
'Don't store the key card key' : 120.pdf, Section 15 (1)

The regulatory body gives some interpretaion of the regulations and outlines how to process in a compliant way. Anyway, what type of signatures / processing ways will be honored as a unequivoval evidence in a lawsuit isn't known yet. So it's the best way to expect the worse.


Never mind, everyone looking at the german regulations for the first time asks 'why so complicated' ! Me, too :-)
Now that the law is in place for some years I have accepted that we have to work according to it. I'll try build a signing server system that is 
  as easy to use as possible for the end user. And in the end a handy signing component will increase the use of electronic signature ...

Greetings

Andreas