Hallam-Baker, Phillip wrote:
Attached is the set of points I think are relevant to the DKIM policy
discussion.
Phill,
A few comments below. Hope I'm not too late if you're submitting this
as an individual I-D this week.
Page 1 expires in December, and all the other pages expire in August,
according to the page footers.
Use of the word "policy". There are so many things that are called
"policy", and I'm not sure which ones you mean here. You might want to
introduce what's included in that definition, and importantly what's
not. An example of what's not might be a security policy saying that
all computers connected to your LAN must be running current anti-virus
software. There's also the concern about how imperative (vs.
declarative) such policies may be, given the recipient's freedom to do
as they choose and possible local legal considerations. That's why I
expect we'll end up with the word "practices".
Section 2, paragraph 1. SSP (currently) stands for "Sender Signing
Policy". You might also want to add a reference to the I-D.
Section 2, paragraph 5: SIP Identity is another example of a protocol
that might benefit from layered policy/practices/whatever.
Section 3.1, paragraph 2: What do you mean by "constant recourse"?
Later in the section, what constitutes a change to DNS infrastructure?
Is creation of a new RR included?
Section 3.3 example: Why can't this sort of information be included in
key records published by the domain?
Section 3.4, paragraph 1: "principle" -> "principal" As you later
mention, even if a new RR is defined, that doesn't remove the need for
heuristics or search strategies (although they may be simpler).
Paragraph 2, what you mean by the "dynamic DNS component"?
Policy discovery strategy example: As SSP is currently written (subject
to change, of course!) the lookup would be to
_policy._domainkey.alice.example.com. Alice is a subdomain, right, and
not that person at example who so often tries to communicate securely
with Bob? The example doesn't describe what happens if the result is
NXDOMAIN vs. if it's NOERROR with no answer (or is this the same?)
I'm really confused as to why the use of a PTR would help here. If
example.com wants to publish a policy, and some host named
alice.example.com exists, and a message is sent from
alice(_at_)alice(_dot_)example(_dot_)com, it still won't find example.com's
policy. We
don't want to require that an extra record be published with every A
record in the domain!
In step 3 of your example, is this the point at which the policy for
DKIM is differentiated with that of other services? Does _dkim become
_emailtls to retrieve the policy having to do with use of TLS by MTAs?
Section 4.1, DKIKM -> DKIM
Hope this helps; this was a quick and not-so-thorough review.
-Jim
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html