On Thu, 2004-05-06 at 17:52, Ian Grigg wrote: > c. much less emphasis on deductive no-risk > systems (PKIs like x.509 with SSL) due to the > poor security and market results of the CA > model. >
at the nist pki r&d workship (mentioned elsewhere in some other post in this mailing list) there was discussion of 1) using private key signing for things like signature (like in human signature) agreement/authorization as opposed to straight authentication. one of the issues is that if you ever use a private key to digitally some random challenge/response data in a authentication paradigm ... you might be at risk ever using the same private key for signature purposes ... since it might be possible that some of the random data you may have signed might not have been truely random after all 2) naked public keys ... aka w/o certificates at all 3) and in some of the breaks the certificate use in payment transactions. sort of two issues in payment transactions were/are a) privacy and b) size bloat. in the mid-90s, the traditional x.509 identity certificate from the early 90s was drastically cut back to relying-party-only, "account number" certificate because of privacy issues with identity information. The work on certificate-based financial transaction started with taking a 60-80 byte payment transaction, instead of ISO8583, using ASN.1 encoding to blow it up to 200-300 bytes; added a 128-byte RSA signature (then adding in the ASN.1 encoding) and a relying-party-only certificate that typically ran 4k-12k bytes; having starting from a 60byte normal transaction, the certificate-based stuff would blow it up by factor of one hundred times to 6k to 12k bytes. The certificate was totally redundant and superfluous since the financial institution was the relying party and already had all the information. In the X9.59 work it was observed that it was possible to encode an ECDSA signature in an ISO8583 transaction in 42 bytes ... so absolute minimum for authenticated payment transaction would go from 60 bytes to a little over 100 bytes ... w/o throwing in a bunch of extraneous, duplicated and/or superfluous data that provided absolutely no added value (the payment transaction still contained the same data, digital signature authentication was added ... and all the payload carried in a certificate was totally redundant and superfluous since the relying-party had a superset). It isn't exactly that payment security requirements have to be proportional to the cost of certificate security ... it was that certificate security increased the payload costs by a factor of one hundred times and provided NO added value. some of my further observations about mixing authentication signing and signature signing ... as well as nature of naked public keys ... recently posted to thread in sci.crypt: http://www.garlic.com/~lynn/2004e.html#20 Soft signatures and "the future of security" ... somewhat orthogonal to cryptography ... there was recently a letter from NSF to some former multician that was posted to the alt.os.multics n.g. that started a thread on (not necessarily crypto) system security (and multics never having been broken). a couple posts in the thread http://www.garlic.com/~lynn/2004e.html#27 NSF itnerest in Multics security http://www.garlic.com/~lynn/2004e.html#36 NSF itnerest in Multics security -- Anne & Lynn Wheeler | http://www.garlic.com/~lynn/ --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
