On Tue, Jan 06, 2009 at 06:09:34 +0900, Randy Bush wrote:
to use your example, the contractor who serves dns for www.bank.example could insert a cert and then fake the web site having (a child of) that cert. whereas, if the site had its cert a descendant of the ca for all banks, this attack would fail.
To be pedantic, it'd have to be the contractor who holds the signing key for the bank.example zone (which may be a separate entity from whoever has operational control of the nameservers). You're correct that this proposal treats control of a DNS zone as a strong proof of identity, but I'd argue that that's the case already -- whoever controls the zone can easily get a CA to issue them a cert which is valid for the host "www.bank.example". Whether the organization name is "Example Bancorp" or "DomainSquatters'R'Us, Inc." is irrelevant, since nobody ever looks at that. I'd go so far as to argue that the hostname is the proper *definition* of identity in this context. The client identifies the destination it wishes to connect to by hostname, not by organization name. The purpose of the cert ought to be to ensure that we're talking to the host identified by that hostname (according to a necessarily trusted DNS). Ensuring that the hostname belongs to someone the user really wants to speak to is an orthogonal problem which is impossible to solve without a clueful user in the loop, and at which the current model is failing miserably.