To:
Jakob Schlyter <jakob@crt.se>
cc:
Derek Atkins <warlord@MIT.EDU>, Edward Lewis <lewis@tislabs.com>, <dnssec@cafax.se>
From:
Simon Josefsson <jas@extundo.com>
Date:
Fri, 31 Aug 2001 18:09:52 +0200 (CEST)
Delivery-Date:
Fri Aug 31 21:13:04 2001
In-Reply-To:
<Pine.BSO.4.33.0108311744010.12076-100000@fonbella.crt.se>
Sender:
owner-dnssec@cafax.se
Subject:
Re: CERTificates and public keys
On Fri, 31 Aug 2001, Jakob Schlyter wrote: > On 31 Aug 2001, Derek Atkins wrote: > > > No, a CERT record is just a blob. It specifically states that the > > 'certificate' portion of the RR is opaque to DNS and may contain > > multiple parts. > > this is wrong. FWIW, I tend to agree with it. > quoting the security considerations section of 2538: > > "By definition, certificates contain their own authenticating signature. > Thus it is reasonable to store certificates in non-secure DNS zones or to > retrieve certificates from DNS with DNS security checking not implemented > or deferred for efficiency." Yes. It doesn't say you must not do DNSSEC, only that the security of the CERT isn't necessarily void if you don't. (Oh, now my english teacher will smack me even more, using all those negations in one sentence..) If SSH store raw public keys in CERT, the client shouldn't accept the key without some security mechanism in place (TSIG, DNSSEC, or even a SSH public key format which allows for signed keys). If the zone administrator want SSH to work, he should sign the zone or something. If he doesn't want SSH to work, it simply wont.