[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: 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
|
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]