ietf-dkim
[Top] [All Lists]

Re: [ietf-dkim] [dkim] #1: Suggestion to change text in section 2.3

2011-04-15 14:02:00
Dave CROCKER wrote:

On 4/15/2011 8:50 AM, Murray S. Kucherawy wrote:
I'd suggest further than the definition as presented simply declares, and
gives examples of, the kinds of things the RFC means when it uses the word
"Identity".  That simple definition doesn't imply (or exclude) any particular
application.  The list of examples illustrates the breadth of that simple
definition.


Examples don't exclude.  By definition, they provide a subset.

A DKIM signature makes no semantic statements about the relationship between 
the 
d= identifier and any other identifier.  Any attempts to discern or impose 
additional semantics is beyond the DKIM Signing specification.  As a 
consequence, I'm not understanding why it is being discussed at length here, 
yet 
again.

While I agree with you general philosophy here, the reason is because 
there contradictions as shown below.


As for how many identities might be trusted or expected and by whom, again, 
that's outside the DKIM Signing specification.

-1

Who will be the signing identity is the foremost important 
consideration any domain will face.  Its one of the parameters for any 
implementing DKIM:

    Please select the signing domain:

That identity selection is a deployment choice not to be taken 
lightly. Self-signing deployment will most likely start with their 
recognized, authorized and trusted domains before going to an 3rd 
party identity. And certainly a selection of the 3rd party will also 
be based on authorization and trust.

As for various post-verification processes' being outside of the DKIM signing 
spec, well yeah.  Asked, answered and documented.  Many times over many 
months:

    <http://dkim.org/specs/draft-ietf-dkim-deployment-11.html#rfc.figure.1>

We can't possibly need to revisit that issue.

And the contradiction is 6.1 Single Domain Signature

 
http://dkim.org/specs/draft-ietf-dkim-deployment-11.html#singledomainsig

The document guide is a very useful, but it is not the DKIM-BASE 
standard.  Yes, if we want to use his non-standard guide and be 
consistent to use valid 2.3 identities, it is also necessary it 
includes the authorized signer domain based on section 6.1 of the 
deployment guide.

The bottom line is that we have a specific layer violations with 2.3 
specifying the only trusted identity is independent from the domain 
selection.  Its not only untrue, its an specific implementation 
detail. I know that is what you want, no, we all want, but it is not 
the Out of the Box deployment scenario.

The text is ambiguous and does not represent the most immediate out of 
the box real world implementation and deployment.  The user of the 
author, author's organization or any other identify is always going be 
selected based on authorization and trust.

In other words, you want me to change my F1 online help for signer 
domain selection to basically says:

     Please select a domain that will sign your mail as an
     independent trust assessment service

No, its functionally broken because that deployment is not applicable 
to the domain signing mail but rather some other outside independent 
identity signing the mail.  More realistic the help will say something 
along the lines:

     Please select an domain authorize to sign mail and will hopefully
     universally trusted by all DKIM receivers.

-- 
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com


_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html