On Fri, 23 Dec 2005, Mark Delany wrote:
On Thu, Dec 22, 2005 at 06:35:47AM -0800, william(at)elan.net allegedly wrote:
Not necessarily. One of the proposals that went into DKIM had characteristic
of storing public key fingerprints in dns. This seems quite close to DK but
has a number of advan
On Thu, Dec 22, 2005 at 06:35:47AM -0800, william(at)elan.net allegedly wrote:
> Not necessarily. One of the proposals that went into DKIM had characteristic
> of storing public key fingerprints in dns. This seems quite close to DK but
> has a number of advantages and unlike DKIM or DK does not pu
On Dec 22, 2005, at 8:38 AM, Keith Moore wrote:
If your goal is gaining consensus on a useful specification in the
shortest amount of time, it makes far more sense to work on the
different aspects of the problem in parallel rather than serially.
My concern regarding the charter is related
> Keith Moore wrote:
> > OTOH, the assumption that _all_ public keys used to validate DKIM
> > signatures will be stored in DNS is a very limiting one, because it
> > appears to lead to either
> >
> > a) a constraint that policy be specified only on a per-domain basis
> > (which is far too coar
On Thu, 22 Dec 2005, Barry Leiba wrote:
Actually, the DKIM base spec does provide a mechanism for replacing the
DNS keystore with something else. Look at 1.4 for a general statement,
and the description of the "q=" tag in 3.5. DKIM's intended to be able
to support user-level keys in a future
Keith Moore wrote:
OTOH, the assumption that _all_ public keys used to validate DKIM
signatures will be stored in DNS is a very limiting one, because it
appears to lead to either
a) a constraint that policy be specified only on a per-domain basis
(which is far too coarse for many domains) or
On Thu, 22 Dec 2005, Keith Moore wrote:
Sometimes feed-forward _is_ useful, and I would agree that the use of DNS to
store public key information is one of the fundamental assumptions behind
DKIM. Change that assumption and you will probably produce a system with
very different characteristi
Branching off from the interminable "justifiable changes" thread
Dropping DKIM, because those people suffer enough without being subjected to
more general discussion about the nature of the universe at IETF :-)
I applaud Cullen for his note. I agree with the parts that Harald snipped
out
If there were an I-D describing such a protocol, I'd be interested in
reading it - is there one?
Not yet. But it hardly seems like the time to write an I-D when there
is at present considerable effort being invested to preclude such an I-D
being considered by the group.
Keith
_
Keith,
Keith Moore wrote:
I'm comfortable with having a domain's "root public keys" stored in DNS
but allowing the corresponding "root private keys" to sign key
certificates for "individual public keys" that can be included in
DKIM-signed messages. The policies for use of those public keys c
Related to how much the charter pre-supposes the solution, the sentence
that "Public keys needed to validate the signatures will be stored
in the responsible identity's DNS hierarchy." seems like a pretty heavy
constraint on the possible solutions and one that some proposals
disagreed with.
I t
Branching off from the interminable "justifiable changes" thread
--On onsdag, desember 21, 2005 23:54:56 -0800 Cullen Jennings
<[EMAIL PROTECTED]> wrote:
Related to how much the charter pre-supposes the solution, the sentence
that "Public keys needed to validate the signatures will be sto
12 matches
Mail list logo
