Crypto 2003
This year's Crypto conference is in Santa Barbara August 17-21. The early registration deadline is July 14th. Full program information is available at http://www.iacr.org/conferences/crypto2003/2003Program.html . It'll be great, both technically and socially! regards, Greg. (General Chair) Greg Rose INTERNET: [EMAIL PROTECTED] Qualcomm Australia VOICE: +61-2-9817 4188 FAX: +61-2-9817 5199 Level 3, 230 Victoria Road,http://people.qualcomm.com/ggr/ Gladesville NSW 2111232B EC8F 44C6 C853 D68F E107 E6BF CD2F 1081 A37C - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: New toy: SSLbar
Adam Fields said: On Fri, Jun 27, 2003 at 12:56:24AM +1000, Mister Lee wrote: Regarding the usefulness of SSLbar itself, its immediate purpose was fingerprint display, as a (theoretically) easy means of checking a cert't validity yourself, ... Maybe this is a stupid question, but exactly how are you supposed to use this information to verify a cert? I've done an informal survey of a few financial institutions whose sites use SSL, and the number of them that were able to provide me with a fingerprint over the phone was exactly zero. If you can't get/verify the fingerprint at least once via another channel, you can't use SSLbar to verify the cert. About the best you can do is ensure that you're seeing the same fingerprint every time you visit the site. Some commercial CAs (eg: Verisign) allow you to look up a cert that they issued. Say I want to verify e-gold's cert (and I trust Verisign), I can do the following: - Go to https://digitalid.verisign.com/services/server/search.htm and search for www.e-gold.com. - Click the link for e-gold's valid cert to view the details. - Annoyingly, they don't show the SHA1/MD5 fingerprints, but they do show the certificate details, so... - Go to the e-gold site, and view the cert properties via the usual click-the-little-padlock method. - Verify the name, subject, serial number etc. against what was shown on Verisign's site. - Make a note of the cert fingerprints. - Next time you visit the site you can use SSLbar to check the cert fingerprint against your records. Makes me think I should add a view cert button to SSLbar, plus maybe an option to show the serial number in addition to SHA1 and MD5 fingerprints... ML - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Mozilla tool to self-verify HTTPS site
Marc Branchaud wrote: Ian Grigg wrote: Tying the certificate into the core crypto protocol seems to be a poor design choice; outsourcing any certification to a higher layer seems to work much better out in the field. I'll reserve judgement about the significance of SSLBar, but I couldn't agree more with the above point. The only way to use non-X.509 certs with TLS 1.0 is by rather clunkily extending the ciphersuites to also identify some kind of certificate type. I'm currently reading Eric Rescorla's SSLTLS book, and a significant proportion of the problems within the SSL/TLS protocol seem to come from the assumption that the cert should be supplied *within* the core protocol, and not outsourced to a higher layer. I.e., if SSL/TLS was re-written around this simple separation into two separate sub-protocols: 1. get the/a/all certificate(s) 2. use the key within a lot of the complexity would disappear. (I understand the argument that SSL/TLS does not require a cert, but to all intents and purposes, everything and everyone assumes it, AFAICS. As a practical issue, as it effects the implementations out there, I'm not sure it makes sense to even consider SSL/TLS without certs.) It seems to me to be a developing principle. We are all agreed that the delivery of (any/the) cert is a very hard problem. We are mostly agreed that it is an unsolved problem. So, as a corollary to the hard problem, the key to use as the starting point for any crypto protocol should be provided to it, not bootstrapped within. (I wonder if there is a pithy way of stating this principle? Good crypto divorces bad PKIs? Cost effective crypto starts with an assumed key?) IMO, this fact has significantly contributed to the lack of adoption of PGP, SPKI, and alternative PKIs on the Internet. (I'm not quite sure what the issue here is with PGP ... it works fine without any certification, and it works slightly better when 3rd party sigs (certs?) are added by the user? Although I grant you that the key structure is .. costly to code, to the point of being impermeable to new implementations.) TLS's new extension mechanism can help address this (see draft-ietf-tls-openpgp-keys), but it'll be a while before extension support is common. Yes, my company's protocol (SOX) extends the certificate layer by using OpenPGP. Configuring the issuance of a new monetary contract is a bit of a bear, in no small part due to the chain of signatures in the OpenPGP PKI that we use. But, it works, and it doesn't feel as though the big costly PKI process built out of OpenPGP slows down adoption any. [ We tried x.509 for a while, but it was a mistake; it lacked cleartext signing (minor point, we hacked our own) and its fixed PKI doesn't map to financial relationships, which are based on WoT, not centralised permissions. ] SSH chooses the simplest solution - opportunistic crypto - create the certs on demand and caching them for future checking. That is the best success formula I have seen so far. -- iang - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: New toy: SSLbar
-- On 2 Jul 2003 at 6:04, [EMAIL PROTECTED] wrote: If you can't get/verify the fingerprint at least once via another channel, you can't use SSLbar to verify the cert. About the best you can do is ensure that you're seeing the same fingerprint every time you visit the site. In practice, if people were able to ensure they saw the same cert every time they hit what is purportedly the same site, this would take out most scams. Unfortunately, no one is going to memorize fingerprints. --digsig James A. Donald 6YeGpsZR+nOTh/cGwvITnSR3TdzclVpR0+pr3YYQdkG /3xr3PRIl9VwhL3ZVdM2Y6VIS/bUwun0l+Sxa7y8 4q6X4YQoXr6QwwvNJ6wKw/ZRgH6Ssp7tpPgQD6rW/ - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: New toy: SSLbar
On Wed, Jul 02, 2003 at 11:05:08AM -0700, James A. Donald wrote: In practice, if people were able to ensure they saw the same cert every time they hit what is purportedly the same site, this would take out most scams. What's wrong with the ssh known-hosts approach, for this? Do sites change certs more often than sshd changes host keys? Given how much crap browsers cache already, this wouldn't seem to add much. Of course it wouldn't help when using a public client host, but anybody doing that for confidential web access is wide open anyway. -- Barney Wolff http://www.databus.com/bwresume.pdf I'm available by contract or FT, in the NYC metro area or via the 'Net. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
