Yahoo releases internet standard draft for using DNS as public key server

[Anne & Lynn Wheeler]

At 10:14 PM 5/30/2004, Peter Gutmann wrote:
>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 majordomo at metzdowd.com