To:
keydist@cafax.se
From:
Edward Lewis <lewis@tislabs.com>
Date:
Thu, 10 Jan 2002 15:52:21 -0500
In-Reply-To:
<200201102031.g0AKVDl16893@marajade.sandelman.ottawa.on.ca>
Sender:
owner-keydist@cafax.se
Subject:
Re: Is this something to solve
At 3:31 PM -0500 1/10/02, Michael Richardson wrote: > However, I think that one answer in our problem space is that you should >have taken a copy of your institutions' apex DNSSEC public key. I ommitted that on purpose. Taking the apex key and having that save the day presupposes the use of DNS in "getting through." (Not that the DNS validates the needed key, perhaps it only leads to the right server for that.) Nor do I want to rule out DNS completely. I am trying to state the base problem, completely independent of the mechanisms we think might be used to solve the problem. I'd like to try and think this way to divorce us (for some scope of us) from our current DNS concept and look at this from the persepctive of what needs to be solved. > It isn't easy to know what to do with it right now. > (I think that putting it into the named.ca file doesn't work for some >reason) > > The answer therefore does not depend upon a global PKI or trust model. Once we know the scenario, we can begin to talk within the protocol's environment about what "trust" is. E.g., for SSH, I want to trust that the SSH daemon is running on the intended server (and with the correct permissions, etc.). I am already relying on the server's address data to be arriving correctly via DNS. Okay - so it looks like I'm delving back into DNS-speak, but the point is that I want to think of the problem in terms of SSH getting its work done - and the same for other protocols. -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NAI Labs Phone: +1 443-259-2352 Email: lewis@tislabs.com Opinions expressed are property of my evil twin, not my employer.