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

Re: revised Proposed Charter


Earl Hood 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.

Wrt DKIM, the trust component is established via DNS.  The signature
verifier trusts that the records it achieves from a DNS query are the
records owned by the domain being queried.  The trust solely relies
on the reliability and security of the DNS transport protocol.

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.

As of now, the "q=" tag appears may be insufficient since it implies a
particular usage model that may not be adequate for some established,
or alternate, PKI systems.


Tying DKIM to X.509, for example, would be a non-trival exercise.
That and for many other reasons is why we're not doing it.

Wording in the DKIM spec could be changed to make it more flexibility,
without burdening it with details of alternate PKI systems.


DKIM allows tags to be added in the future. I'm not sure what
else you can do without doing a depth-first traversal of that
alternate PKI system.

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.

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.
Note that an alternate means of querying for the RR provides
another potential way to exploit alternative PKI's since the
query method could implicitly be, say, https where there needs
to be some binding between the d= and the identity asserted
in the cert for a TLS session.

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.

Mike