To:
"Scott Rose" <scottr@antd.nist.gov>
Cc:
<dnssec@cafax.se>
From:
Simon Josefsson <simon+dnssec@josefsson.org>
Date:
Tue, 04 Sep 2001 21:42:09 +0200
In-Reply-To:
<008e01c1356e$cbe8f080$b9370681@antd.nist.gov> ("Scott Rose"'smessage of "Tue, 4 Sep 2001 14:24:12 -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
"Scott Rose" <scottr@antd.nist.gov> writes: > So either store non-DNS keys in a new record, or use the CERT record. > Either solution is (splitting hairs) a non-DNSSEC issue, but a "using DNS in > support of other protocols" issue. In this case, another protocol using > DNSSEC to provide some security features. Agreed. > The downside of creating a new "raw key" type for the CERT record is that > there is no protocol field in the record to indicate the protocol for the > key stored in the record. Right, so instead of using a "raw key" type, use protocol types. E.g. let SSH define a CERT type that specify the content of the certificate blob to be a raw key. Defining a "raw key" type doesn't seem useful to me, applications need to know if the key is meant for them or not. (This could be solved by using owner naming schemes such as "host._ssh.example.org" though...)