To:
James Seng/Personal <jseng@pobox.org.sg>
cc:
<keydist@cafax.se>, Michael Richardson <mcr@sandelman.ottawa.on.ca>
From:
Simon Josefsson <simon+keydist@josefsson.org>
Date:
Mon, 7 Jan 2002 10:09:03 +0100 (CET)
Delivery-Date:
Mon Jan 7 10:09:22 2002
In-Reply-To:
<001401c19738$514f5180$0401000a@jamessonyvaio>
Sender:
owner-keydist@cafax.se
Subject:
Re: From whence we came...
On Mon, 7 Jan 2002, James Seng/Personal wrote:
[Keys vs Certs]
> So lets choose: which one is our requirement?
It seems clear to me that either choice will exclude a large amount of
people here, who will need to define their own mechanisms. Since
essentially these two mechanisms will, from the DNS point of view and from
the {keys,certificate}-retrieval functionality point of view, behave the
same I don't see why we need to require either one. Does deciding on this
make the work here easier? The same issues has to be dealt with anyway.
Let's define a flexible system that allows any kind of operation. Taking
CERT RR and stating "It is OK to register a subtype for things that aren't
strictly certificates" and replacing the naming recomendation is
sufficient. Adopting APPKEY is sufficient. Even allowing both KEY and
CERT to be used as they are currently specified (together with a better
naming recomendation) is sufficient, even though it makes matters more
complicated for applications that supports both keys and certificates. A
secured referral idea a'la WPKI would be sufficient.