The S/MIME list debated this some time ago, and decided (pretty much unanimously) against it, for two reasosn. Firstly, because it adds huge ugly blobs of base64 crap to each message (and before the ECC fans leap in here, that still adds small ugly blobs of base64 crap to each message). Secondly, because if you get a message from someone you know you'll be able to get a pretty good idea of its authenticity from the content (for example an SSH developer would be unlikely to be advocating SSL in a list posting), and if you get a message from someone you don't know then it's pretty much irrelevant whether it's signed or not. So the consensus was not to sign messages.
this may or may not be my KISS authentication thread.
mid-90s, some number of financial institutions retrenched from x.509 identity certificates to simple relying-party-only certificates ... because of enormous privacy issues regarding blanketing the world with privacy information contained in identity certificates.
however, they were still looking at taking a 60-80 bytes payment message, attaching a 128byte digital signature, and then attaching a 4k byte to 12k byte relying-party-only certificate ... and sending it back to the financial institution that issued the certificate. this is not counting any ASN.1 encoding that might have been done which then possiby includes a bunch more bytes. note that standard payment message message has been around some 30 years carefully crafted as simple 7bit ascii w/o any addition encoding requirements. the purpose of the certificate was to carry the account number ... which was also included in the signed payment message ... and the public key ... which was stored in the account record back at the financial institution that was receiving the transmission and had originally issued the relying-party-only certificate.
so the financial institution receives this new payment object, retrieves the account number from the (signed) payment message and uses the public key in the account record to verify the signature ... w/o ever resorting to the certificate. So we have a payload bloat of one hundred times ... in order to carry a certificate that is redundant and superfluous and never used.
so x9.59 was fairly carefully crafted to add a 42byte ECC signature to a standard 60-80byte payment message. any special encoding to carry 42byte ecc 8bit in 7bit transmission at worst doubled the signature payload size.
http://www.garlic.com/~lynn/index.html#x959
--
Anne & Lynn Wheeler http://www.garlic.com/~lynn/
Internet trivia 20th anv http://www.garlic.com/~lynn/rfcietff.htm
--------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
