[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: PROCEDURAL ISSUE: RE: QUERY: Key Server Choices

To: "Hallam-Baker, Phillip" <pbaker@xxxxxxxxxxxx>
Subject: Re: PROCEDURAL ISSUE: RE: QUERY: Key Server Choices
From: Thomas Roessler <tlr@xxxxxx>
Date: Tue, 26 Jul 2005 13:04:31 +0200
Cc: Dave Crocker <dcrocker@xxxxxxxx>, IETF-MAILSIG <ietf-mailsig@xxxxxxx>
In-reply-to: <>
List-archive: <http://www.imc.org/ietf-mailsig/mail-archive/>
List-id: <ietf-mailsig.imc.org>
List-unsubscribe: <mailto:ietf-mailsig-request@imc.org?body=unsubscribe>
Mail-followup-to: "Hallam-Baker, Phillip" <pbaker@verisign.com>, Dave Crocker <dcrocker@bbiw.net>, IETF-MAILSIG <ietf-mailsig@imc.org>
References: <>
Sender: owner-ietf-mailsig@xxxxxxxxxxxx
User-agent: Mutt/1.5.9i

On 2005-07-25 17:13:27 -0700, Hallam-Baker, Phillip wrote:

> The true choices here are three fold:
> 
>   1) Only use DNS based keying
>   2) Design a completely new non-DNS based keying mechanism from scratch
>   3) Support the use of existing non-DNS keying mechanisms that are
> approved standards

I agree.

(As I said before, I don't think the charter should a priori exclude
non-DNS mechanisms for key storage and retrieval.  I'm fine, though,
with leaving the design of entirely new mechanisms out of scope.)

Regards,
-- 
Thomas Roessler, W3C   <tlr@xxxxxx>

Follow-Ups:
- Re: PROCEDURAL ISSUE: RE: QUERY: Key Server Choices
  - From: domainkeys-feedbackbase02

References:
- PROCEDURAL ISSUE: RE: QUERY: Key Server Choices
  - From: Hallam-Baker, Phillip

Prev by Date: Re: QUERY: Relationshipt to other IETF work
Next by Date: Re: QUERY: Key Server Choices
Previous by thread: PROCEDURAL ISSUE: RE: QUERY: Key Server Choices
Next by thread: Re: PROCEDURAL ISSUE: RE: QUERY: Key Server Choices
Index(es):
- Date
- Thread