----- Original Message -----
From: "Hallam-Baker, Phillip" <pbaker(_at_)verisign(_dot_)com>
I suggest that a good way to try to focus the discussion
here would be to abandon the punctuation syntax while we
discuss the semantics, work out what semantics should be
there and then decide whether the punctuation syntax is
worth keeping.
I agree. When I "suggested" the terms, I clearly left it up to the
authors to make the final call on them. But I did think Exclusive and
Neutral were obvious terms. I could care less what we call them. But
using OH equal This or that, doesn't cut it during technical
conversations. Thats for software to understand.
In my view the design of the policy statement should be
based on the folowing principles:
* It is the exclusive right of the domain name owner to decide
how the domain name is used.
I agree, but he needs to be made aware what that right entails, meaning
don't park your BMW in a bad neighorhood and expect it to be safe!
* for the purpose of the spec the domain name owner should
be presumed to be the party that controls the DNS records
Ok.
* The domain name owner can decide the importance of edge
cases such as mail that does not pass through the
approved gateways.
Ok, but by doing so, he puts a burden on the edge software too. In order
words, should we be responsible in maintain the domain security?
* A policy record does not modify the semantics of a DKIM digital
signature
Hmmm, not sure what you mean. Can the signature exhibit a policy that
is conflictive with the publish policy?
* The semantics of the signature are exclusively defined by the
DKIM signature header and the referenced key record (or other
key distribution/assertion mechanism referenced in the header
or key record)
Ok.
* The purpose of a policy record is to assist a recipient interpret
the absence of a valid signature record.
No I disagree. This is the Michael Thomas's assertion:
SSP is not for signed messages, only for unsigned messags.
and it is reflective in his pseudo-code which the current API I believe
follows.
This is a Major Loophole. What if there is no domain signing policy and
the message is signed? There is something wrong here with this and
other similar policy/signature conflicts. They presents clear loopholes
in the protocol.
I have not been convinced that a valid signature is sufficient enough to
bypass, skip any further validation on the transaction and that the
message should be accepted with 100% trust behind it.
* A policy record describes the intended outbound signing policy of
the sender.
Ok, but think about it. If this assertion is to be true, then the
previous assertion needs to be corrected. :-)
* A policy record may contain additional information
to guide interpetation of the absence of a signature,
for example that the sender is a frequent target of
phishing attack.
Ok, this is new stuff that was touched on by Earl and I with "Failure
Action attributes". But in principle, there is a default expectation
when a policy states a requirement that isn't honored. So if a
signature is expected, and its not there, that should be a failed
condition. The default is reject (and by reject, I mean it is marked
for the local policy to decide). Me? Reject it!! In the waste basket.
* A policy mechanism may advertise support for specific incident
reporting mechanisms in the case that an invalid signature is found.
Ok. Similar logic worked out in SPF with some implementations. Need to
watch for Report Attacks. So maybe 1 report concepts are recommended.
* A policy mechanism may specify certain characteristics of
a valid signature, for example the signature algorithm used.
Isn't this already there?
--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com
_______________________________________________
ietf-dkim mailing list
http://dkim.org