Re: Pre-picking one solution (Re: [ietf-dkim] Re: WG Review: Domain Keys Identified Mail) (dkim)

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

 



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 think this is part of "divide and conquer" that is generally argued to be an useful strategy in the IETF: once we buckle down and start writing specs, we're documenting one approach, with one set of advantages and disadvantages, and are trying to prove that *this approach* is feasible.

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 characteristics than DKIM is currently assumed to have.

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

b) a situation that large numbers of DNS queries may be required to validate a single signature

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 can then be encoded in the certificates, allowing those policies to be specified on a per-user basis. This gets out of the trap of having to specify policy on a per-domain basis, and doesn't require any more DNS queries than current DKIM. IMHO it would make DKIM much more flexible and adaptable to diverse domain situations (and thereby much more acceptable as a standard) than the current proposal.

Keith

_______________________________________________

Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]