On 26/04/12 22:24 PM, helpcrypto helpcrypto wrote:
If you want the signature + document to be legally sustainable and/or
user-interpretable, then plaintext signatures with embedded public keys are
the way to go. You can base64-encode the public keys :) Some further
development of this theme is at
http://iang.org/papers/ricardian_contract.html
Maybe im wrong...
Lets suppose i have a page with ISO-8859 encoding. In a textarea
-which i want to sign- I type:
"Legión Española" and click sign (this will translate ISO into bytes and sign)
Then, i send the original+signed data to you.
You receive on UTF-8 and try to verify signature. As your UTF string
tranlated into bytes its not the same i use, the signature will not be
the same-> verification fail.
...am i correct?
(Maybe iso/utf-8 share those bytes, but im sure Kim Jong Un use another ones)
Yes, correct. The message you send to me must be capable of
self-describing its characteristics that lead me to successfully
interpret it at all levels that I might need. UTF, signature, page
layout, all.
So, you need a canonicalisation format in order to deal with UTF, etc.
Also there are various artifacts with other issues.
If you've looked at the old PGP form, you'll find that it drops trailing
spaces - that's because popular word-processors used to add trailing
spaces. Later on we had the problem that mail programs would move the
words around, or quote them differently. Hence MIME and that funny '='
method. All of these are real-life problems in working with documents,
and any signature has to survive the assault of "programs that know
better..."
Out of this are two popular directions:
sophistication - UTF, MIME, XML, etc.
simplification - ascii, lines, space-stripping, OpenPGP.
iang
--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
