PROCEDURAL ISSUE: RE: QUERY: Key Server Choices

["Hallam-Baker, Phillip" <pbaker@xxxxxxxxxxxx>]

The point of Dave's poll if you have not guessed is to rule out of scope
alternative key proposals.

The usual procedure when taking a group poll is first to discuss on the
list what the question should be. In this case the question is
essentially:

  1 Should the group endorse:
  1a) Motherhood
  1b) Ebola

  2 Should the group endorse:
  2a) Apple Pie
  2b) Botulism

The choices given do not include the choices that I have been arguing
for. The 'poll' is thus irrelevant to the choice the group must make as
currently worded.

The poll is clearly intended to 'settle' the issue in accordance with
Dave's choice. That is not acceptable behavior for a BOF co-chair. 


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

Giving only a choice between 1 or 2 is not a true description of the
alternatives.

We have been arguing this point for over a week now.


> -----Original Message-----
> From: owner-ietf-mailsig@xxxxxxxxxxxx 
> [mailto:owner-ietf-mailsig@xxxxxxxxxxxx] On Behalf Of Dave Crocker
> Sent: Monday, July 25, 2005 1:19 PM
> To: 'IETF-MAILSIG'
> Subject: QUERY: Key Server Choices
> Importance: High
> 
> 
> 
> >  There was no agreement from this mail list that storing 
> public keys 
> > in  dns is the way to go. In fact if anything arguments had 
> been given 
> > that  it is not the best way to create PKI architecture and 
> that using 
> > some form  of HTTP retrieval or HTTP key server would be better.
> 
> 
> Folks,
> 
> Well, let's do a query of mailing list participants.
> 
> As currently specified, DKIM is based on domain names and 
> defines a mechanism 
> for using that domain name to obtain a DNS record containing 
> the public key 
> associated with that name.  There are multiple 
> implementations of the mechanism.
> 
> As of now, I am not aware of any specifications for doing 
> DKIM using any other 
> mechanism, for obtaining keys.  Defining such a mechanism 
> will take unknown 
> resources and time.  The output of that effort is not certain.
> 
> 
> So I think the questions are:
> 
> 1. Key Server:
> 
>    1a. Do you agree that storing public keys in the DNS is 
> the way to go? or
> 
>    1b Would using some form of HTTP retrieval or HTTP key 
> server be better?
> 
> 
> 2. Working group project management
> 
>    2a. Should the working group focus on the current, DNS-based 
> mechanism now, and pursue additional mechanisms later? or 
> 
>    2b. Should the working group include development of a 
> non-DNS-based mechanism as part of its initial delivery?
> 
> 
> 
>   d/
>   ---
>   Dave Crocker
>   Brandenburg InternetWorking
>   +1.408.246.8253
>   dcrocker  a t ...
>   WE'VE MOVED to:  www.bbiw.net
> 
> 
> 
> 
>