To:
Edward Lewis <lewis@tislabs.com>
Cc:
<dnssec@cafax.se>
From:
Simon Josefsson <simon+dnssec@josefsson.org>
Date:
Tue, 04 Sep 2001 22:22:57 +0200
In-Reply-To:
<v03130301b7bae0979aeb@[199.171.39.4]> (Edward Lewis's messageof "Tue, 4 Sep 2001 15:54:21 -0400")
Sender:
owner-dnssec@cafax.se
User-Agent:
Gnus/5.090004 (Oort Gnus v0.04) Emacs/21.0.105
Subject:
Re: CERTificates and public keys
Edward Lewis <lewis@tislabs.com> writes: >>It is already possible to put a public key that is not signed by a CA >>in a CERT record. Let's use it. >> >>(Ok, if SSH wants a certificate type number in CERT of its own, they >>need to register one. But the same holds for KEY.) > > Why force SSH to use a certificate? > > There are two things a client needs to make a secure connection - the IP > address and server host key. The IP address is coming out of DNS, so > implicitly there is trust in the DNS admin to enter the right data. Why is > the server host key any different? > > What are the "requirements" motivating the use of a certificate structure > instead of a raw public key? Why do the extra processing needed to get the > server host key into a certificate, ship a certificate, and then parse and > extract the key from the certificate in the client? Oh. I have been unclear, this is not what I want. I am sorry, I will try to explain what I'm after. I'm suggesting to let SSH put a raw public key in a CERT record, using a "SSH" Certificate type. In my mind, this isn't even abusing [my understanding of] the intention of the CERT record, a raw public key somehow signed by someone else (be it DNSSEC, TSIG or whatever) _is_ a certificate and thus OK to store in a CERT RR. And even if this is abusing the intention of the CERT record, I don't see any technical arguments against this. Using APPKEY would work equally fine to me, but having both CERT and APPKEY for similar purposes is not good.