To:
Derek Atkins <warlord@MIT.EDU>
Cc:
Edward Lewis <lewis@tislabs.com>, Simon Josefsson <jas@extundo.com>, <dnssec@cafax.se>
From:
Jakob Schlyter <jakob@crt.se>
Date:
Fri, 31 Aug 2001 17:29:29 +0200 (MEST)
Delivery-Date:
Fri Aug 31 20:35:34 2001
In-Reply-To:
<sjmu1yotjqf.fsf@rcn.ihtfp.org>
Sender:
owner-dnssec@cafax.se
Subject:
Re: CERTificates and public keys
On 31 Aug 2001, Derek Atkins wrote: > There is absolutely no assumption at all in RFC 2538 that a > certificate is signed. If there is, please point out the section so I > can go re-read it again. rfc 2538 section 1 - "A certificate is a binding, through a cryptographic digital signature, of a public key, a validity interval and/or conditions, and identity, authorization, or other information." > This means that when you "enter a key into a certificate" you don't > have to worry about who signs it, because quite frankly NOBODY has to > "sign" it. I think we should separate certificates, that contains its own signature (which is probably not a all related to dnssec signatures) and simple public keys (that needs and depends on dnssec to be trusted). > The main reason, IMHO, to use a CERT record over a KEY record is that > KEY records imply DNSSec keys whereas CERT records imply application > keys. one of the the problems are that KEY is used both for storing keys used by the infrastructure itself and for applications. I believe the solution is to create a separate application key rr-type as described in the appkey draft (draft-schlyter-appkey-00.txt). jakob