[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


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.



Home | Date list | Subject list