for the most part HTTPS SSL is certificate manufactoring (a term we coined a couple years ago) .... "infrastructure" typically implies the administrative and management .... which would require (at a minimum) CRLs for a certificate-based PKI.
the interesting thing about the use of SSL domain name server certificates is that they supposedly are addressing an integrity issue in the domain name infrastructure .... i.e. SSL checks that the domain name listed in the SSL domain name server certificate is the same as the domain name clicked/typed in for contacting the server. The issue is that the domain name could be hijacked and instead of going to the "real" IP-address .... it gets rerouted to a fraudulent IP-address. however, if you track back the trust infrastructure for the SSL domain name server certificate .... the process is somebody applies for a SSL domain name server certifificate with a certification authority. The standard operating procedure for certification authorities is that they typically have to verify the information that they are certifying (in this case domain name ownership) with the authoritative agency for the information (in this case the domain name infrastructure). Now since there could be an integrity problem in the domain name infrastructure with respect to domain name hijacking ... there in fact could be a domain name hijacking prior to the application for a certificate .... which results in the issuing of a valid SSL domain name server certificate to the wrong entity. One of the suggestions for addressing the domain name infrastructure integrity issue is for public keys to be registered at the same time as the domain name .... and then further communication with the domain name infrastructure be with digitally signed messages ... as part of the process for thwarting domain name hijacking. Note however, since the domain name infrastructure is the registration authority for the public key as well as the relying party receiving the signed messages .... certificates are redundant, superfulous, and extraneous .... even tho it still could be considered a (certificate-less) "publick key infrastructure" with significant administrative and management support. The other interesting aspect is that the existing domain name infrastructure is set up for (presumably) trusted, (near) real-time distribution (and updating) of almost any kind of information; not just the (nearly) trusted binding of domain name to IP-address. Given that public keys are also registered with domain names at the same time as domain name and ip-address .... then a trusted domain name infrastructure could be relied upon to implement a (certificate-less) near real-time "public key infrastructure" (with full administrative and management functions already in existance) .... aka the domain name infrastructure could optionally distribute public key in the same response that it distributes ip-address ...... eliminating the requirement for a certificate-based PKI for trusted public key distribution. This is somewhat a catch-22 .... that one of the solutions to addressing a basic SSL domain name certificate integrity problem (i.e. a CA has a broken trust chain if there is an integrity issue with the authoritative agency responsible for the information that a certification authority must certificate) could also be the solution eliminating any requirement for SSL domain name certificates. As an aside, having the public key at the same time as the ip-address for setting up the base TCP session could also be used to simplify the normal SSL session setup (since there is no certificate distribution that has to occur). random additional discussion: http://www.garlic.com/~lynn/subtopic.html#sslcerts there is also the claim that 99.99999 percent of client authentication in the internet world today is radius-based; typically userid/password (although radius supports multiple authentication processes specifiable at an individual userid/account level). There has been work done on an authentication process for radius involving digital signature where a public key is registered in place of a password. This would also represent a (certificate-less) public key infrastructure with full administrative and management support. random raidus discussion http://www.garlic.com/~lynn/subtopic.html#radius for pointer to radius standards & documents: http://www.garlic.com/~lynn/rfcietff.htm & click on "Term (term->RFC#) and then click on "RADIUS" in the "Acronym fastpath" section remote authentication dial in user service (RADIUS ) see also authentication , network access server , network services 3162 2882 2869 2868 2867 2866 2865 2809 2621 2620 2619 2618 2548 2139 2138 2059 2058 also of some interest are the AAA rfcs: Authentication, Authorization and Accounting see also accounting , authentication , authorization 3127 2989 2977 2906 2905 2904 2903 perry e. metzger <[EMAIL PROTECTED]> on 12/26/2001 3:45 pm wrote: HTTPS SSL does not use PKI. SSL at best has this weird system in which Verisign has somehow managed to charge web sites a toll for the use of SSL even though for the most part the certificates assure the users of nothing whatsoever. (If you don't believe me about the assurance levels, read a Verisign cert practice statement sometime.) Of course, client side certificates barely even exist, although people made substantial preparation for them early on in the history of all of this. Were it not for historical accident no one would care about "PKI" in this context. > S/MIME use is significant and growing. I get PGP encrypted mail a few times a week. I've never received a request from any counterparty to set myself up to receive S/MIME. Your mileage may vary. > The financial industry is not looking at offline PKI models in > general. When I was still doing security consulting, nearly every firm I worked for had installed Entrust or something similar -- and none of them used the systems for anything. PKI and the Emperor's New Clothes have a bunch in common. > As for what PKI vendors have been up to, the sucessful ones have been > supporting private label certification hierarchies from the start. The PKI vendors are, I think, largely surprised by what has happened. They were expecting things like lots of mutual authentication using PKI to be in place, and in fact, there's almost none in use at all. I think many of the PKI vendors haven't been doing too well -- some of them that I used to have dealings with barely exist any longer. The one business that seems to make money is charging a toll for running an e-commerce site. I wonder who they might be. Of course, none of this should be surprising in the least. Commerce and the PKI model have nearly nothing to do with each other. Some of us were writing about this years ago. -- Perry E. Metzger [EMAIL PROTECTED] -- NetBSD Development, Support & CDs. http://www.wasabisystems.com/ --------------------------------------------------------------------- The SPKI Mailing List Unsubscribe by sending "unsubscribe spki" to [EMAIL PROTECTED] --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
