← Prev in month
← Prev in thread
Next in thread →
Next in month →
agsc-tpki-requirements-00.txt - Signing "live" form data
The current requirement document does neither address the input format, nor the output format of the data-to-be-signed. It is worth noting that there are major complexities associated with this part. A brief example follows here. Assume that you only allowed static data to be signed. If applied to HTML, the input format could be: <html><body>Ordered items: 456</body></html> The output format could be limited to a hash (message digest) of this document. Complexity: low. If you instead allowed "live" forms to be signed things become considerably more complex. <html><body>Ordered items: <input type="text" name="items"></body></html> Assume that the user types in "t45" and then signs it: The server will (hopefully) reject the signature because it does not consider "t45" a valid number. You may argue that this is easily fixed with some Javascript but that is only true for simple forms where all testing can be done locally. In addition you would also sign the javascript code which certainly is no crime, but not particularly pretty either. But the complexity does not stop there. What exactly is to be transmitted back to the web server? A modified HTML document? <html><body><script>whatever needed to verify local data correctness </script>Ordered items: <input type="text" name="items" value="456"></body></html> Or something made up like this? <data name="items">456</data> It seems that both these schemes are rather hard to programmatically correlate with the HTML form. It gets even more "interesting" for PDF which if to be supported with "live" form input, has its own unique signature format. A further complexity of signing "live" data is that there is no possibility to cryptographically associate computer-oriented (transaction) data with the user view. What is this? An example of this feature (WYSIWYS + "data") that many other signature systems support is here: <VisibleDataForTheUserToSign> <html><body>Ordered items: 456</body></html> </VisibleDataForTheUserToSign> <HiddenTransactionData> <data name="items">456</data> </HiddenTransactionData> My opinion on this, is that TPKI should align itself to the web paradigm by offloading the final input data validation to the server and then offer the user an opportunity to sign static and validated data in a subsequent step, because this is much, much more flexible and does in no way limit the possibility to use advanced forms, they just be get better. Anders Rundgren
← Prev in month
← Prev in thread
Next in thread →
Next in month →