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?
Yes.
or
1b Would using some form of HTTP retrieval or HTTP key server be better?
IMO it would be worse.
2. Working group project management
2a. Should the working group focus on the current, DNS-based
mechanism now, and pursue additional mechanisms later? or
Focus on DNS delivery for now, worry about defining other mechanisms later.
2b. Should the working group include development of a
non-DNS-based mechanism as part of its initial delivery?
No.
I note in passing that none of this has anything to do with accreditation
system linkage. I support defining a linkage field for this purpose in the base
specifications. The field's syntax should be that of a URL; defining its use
should be out of scope for now.
Ned