On July 25, 2005 at 07:56, Michael Thomas wrote:
All a valid message signature states is that a given set of data was
signed with a given key. That's it.
Note that with DKIM, you cannot functionally decompose things this
way because the public key is in the DKIM RR.
I was refering to things in the general cryptographic context vs
the specific DKIM context, which I then mention later.
For some, this may be sufficient, but for others, this is definitely
not sufficient. Because of security risks associated with DNS (along
with some of the key management aspects of it) others, including
myself, would definitely like to see hooks in DKIM to allow for
other PKI systems, systems that provide more robust trust models.
What about DNSSEC? It's about as (in)plausible as any other
supposed global PKI.
First, DNSSEC is not really deployed, while other PKI systems are.
Second, why do people assume that alternative PKI systems have to
"globally" adopted. From my perspective, altenative PKI systems will
probably get use among certain types of entities that require a more
secure trust model than what core DKIM provides. Such systems may
grow in the number of users as systems mature.
For example, the "d=" tag can be described as:
The identity of the signing agent.
That's not what d= is used for; it used to direct the verifier
to the right place in the DNS hierarchy. I'm not very keen on
trying to overload semantics for things that haven't even been
designed.
Splitting semantic hairs. Quoting from the spec:
(d= is) The domain of the signing entity (plain-text; REQUIRED).
This is the only tag that provides any form of identification of
the signing agent.
The draft also states (Section 1.2):
In particular, a signature includes the identity of the signer.
If the d= tag does not identifies the signer, than what does?
As d= is currently defined, it does explicitly denote the signing
agent to much detail, but it appears to be the only tag that
provides any form of identification of the signing agent.
This description allows alternative values for d= based upon what
is specified for "q=". BTW, I see the "q=" tag as more of a PKI
implementation identifier vs a "query method".
This is a relic of DK, but I think it was more intended as an
alternate mechanism for querying for the RR -- ala IIM's KRS.
I agree with your statement that q= intends a particular key
management model. This is what I have an issue with.
That said, I favor the crispness of the current charter/spec:
specs in this area have an almost perfect track record of
flopping in large part, IMO, due to their being unintelligablely
complex. Even the "simplicity" of the current spec brings up
deep and hard questions. Combinatorics is the enemy.
A specification that is artifically constrained can hurt adoption,
hurt future development based upon it, and potentially lead to
alternative (maybe non-open) systems being developed.
IMHO, I do not think much change (with respect to flexibility) is
needed in the spec to satisfy the concerns being raised. Some
better choice of wording will solve much of the problem, providing
for (useful) extensibility without compromising the core deliverable.
--ewh