Frank Hecker goes to the Mountain - mapping the structure of the Certificate Authority
Frank takes aim at the woeful business known as certificate authorities in an attempt to chart out their structural elements and market opportunities.
Frank argues that CAs can be viewed as providers of one of encryption, DNS-fixes, site identity proofs, or as anti-fraud services. Depending on which you choose, this has grave ramifications for what follows next -- Frank's thesis implicitly seems to be that only one of those can be pursued, and each have severe problems, if not inescapable and intractable contradictions. In the meantime, what is a browser manufacturer supposed to do?
For those who have followed the PKI debate this will not surprise. What is stunningly new -- as in news -- is that this is the first time to my knowledge that a PKI user organisation has come out and said "we have a problem here, folks!" Actually, Frank doesn't say that in words, but if you understand what he writes, then you'd have to be pre-neanderthalic not to detect the discord.
What to do next is not clear -- so it would appear that this essay is simply the start of the debate. That's very welcome, albeit belated.
Posted by iang at November 21, 2005 06:33 PM
Thanks for commenting on my blog post. I wanted to clarify myself regarding your comment on the proposed possible functions of a CA, that "Frank's thesis implicitly seems to be that only one of those can be pursued..." I believe that a CA can in fact serve multiple functions at once, in the sense (for example) that a CA issuing "domain validated" certificates is serving both the "fix DNS" function and the "enable encryption" function: end users connecting to a site with such a certificate get both an encrypted connection and some measure of protection against DNS MITM attacks.
Where the choice of possible CA functions causes problems and contradictions comes from the point of view of the developer of PKI-enabled applications, and in particular when deciding how to handle particular edge cases and error situations. To return to the example above, if a browser developer adopts the point of view that the function of a CA is to prevent DNS MITM attacks then clearly it would be an error to allow a connection to a web site using a self-signed certificate, with no independent validation that the site operator owns or controls the domain referenced in the certificate. However if the browser developer adopts the point of view that the function of a CA is simply to enable encryption then connecting to a site with a self-signed certificate would not necessarily be a full-fledged error; at most it might require some minimal user confirmation that the user wants to proceed, after which the site would display as normal.
One could think of similar examples involving conflicts between the "fix DNS" point of view and the "verify identity" point of view, or between the "verify identity" point of view and the "prevent fraud" point of view. I leave these as an exercise for the reader.