To:
Jakob Schlyter <jakob@crt.se>
Cc:
Simon Josefsson <jas@extundo.com>, Edward Lewis <lewis@tislabs.com>, <dnssec@cafax.se>
From:
Derek Atkins <warlord@MIT.EDU>
Date:
31 Aug 2001 12:13:38 -0400
Delivery-Date:
Fri Aug 31 20:35:41 2001
In-Reply-To:
Jakob Schlyter's message of "Fri, 31 Aug 2001 17:49:33 +0200 (MEST)"
Sender:
owner-dnssec@cafax.se
Subject:
Re: CERTificates and public keys
Jakob Schlyter <jakob@crt.se> writes:
> 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. 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."
Read the very next paragraph:
Alternatively, if certificates are retrieved from a secure DNS zone
with DNS security checking enabled and are verified by DNS security,
the key within the retrieved certificate MAY be trusted without
verifying the certificate chain if this conforms with the user's
security policy.
Basically, what it says is that "if you are in a Secure Zone and trust
it, you can trust the contents of the CERT record; if you are NOT in a
Secure Zone, then you cannot trust the CERT record and must verify it
out-of-band."
There is still no requirement that a CERT record actually contain
signature information itself.
Another thing to note: Extra resource records adds complexity to the
system. Complexity leads to confusion. Confusion leads to bad/broken
implementation. And bad/broken implementation leads to security
vulnerabilities. Simplicity would state that we need TWO key-type
resource records:
a) DNSSec infrastructure keys
b) application keys
Note that all application keys should use the SAME RR type. There is
absoutely no reason to use different types, and a number of reasons
why it would be bad or confusing.
-derek
--
Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
Member, MIT Student Information Processing Board (SIPB)
URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH
warlord@MIT.EDU PGP key available