Michael Thomas wrote:
Stephen Farrell wrote:
I don't see DNS as a "third party" in the same sense as a CA for
certs. Yes, DNS has to work, but it isn't a third party (unless you
want to count the root servers, I suppose). By this logic, we should
also include the multiple third parties that run the routers and all
the rest of the infrastructure.
In my little PKI-riddled mind, the DNS is a TTP since it supplies the
public keys and if/when DNSSEC were used, it starts to look quite like
a PKI. The routers etc. won't ever really be supplying signed key
records. But if no-one else thinks the same, leaving as-is if of course
right.
I think Eric captures the exact nature of the confusion. On purely
technical
level, Stephen is right, but on the 'want-to-be-understood' level,
mentioning
a ttp is good way to get un-understood in a big hurry. And even then people
try to shoe horn "certificates" into our certificateless design and proceed
misunderstanding based on that false premise.
Fair point. I guess this is part of balancing the AD/IESG readership
with the more general programming readers too.
If I go to a conference or IETF, then I generally use its smtp server.
If someone was used to mail from me being signed by tcd.ie and suddenly
see mail from me signed by ietf66.org they might react badly. I don't
want that to happen. (I know that the IETF meeting server doesn't sign
now, but I guess it may in future.)
So, my point was that I didn't see an example/use-case that mapped to
the one above.
Sure there is: the first obvious is that you can vpn into you home as
many of us do already and have your home mta's do the signing.
Not all setups support that, incl. ours in TCD at the mo. which reduces
you to webmail. I've no idea how common this still is, but I would
assume that vpn-ing in will be increasingly more the norm.
> However, the "DKIM" answer is to delegate a key/selector to
stephen(_dot_)farrell(_at_)cs(_dot_)tcd(_dot_)ie
(probably with g=stephen.farrell; ) and allow your own selector do the job.
Sure, but I didn't see a recommendation in the I-D that that be done for
that use-case. Maybe I missed it or maybe it doesn't need to be there,
but given that this is maybe one of the times that some current practice
and what we think will be dkim practice are a bit at odds, I'd have
thought it warranted a mention.
S.
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html