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

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 14 Apr 2011 15:52:06 -0700

> -----Original Message-----
> From: dkim issue tracker [mailto:[email-masked]]
> Sent: Wednesday, April 13, 2011 6:55 AM
> To: Murray S. Kucherawy; [email-masked]
> Cc: [email-masked]
> Subject: Re: [dkim] #1: Suggestion to change text in section 2.3
> 
> #1: Suggestion to change text in section 2.3
> [...]

Consensus so far (pulling in pre-WGLC comments on the same topic) is to keep the text as-is, and so far I concur with that position.  I don't believe any of the proposed changes so far do anything to clarify or correct anything in here.

There's been concern expressed that the list of examples in 2.3 specifically exclude some possible models of DKIM use, but I disagree.  A "person, role or organization" certainly can include an author or author's domain, a third-party signer, an MLM, a certifying service, a policy evaluator, an arbitrary intermediary, or any entity at all.  I haven't seen or invented an example yet that this doesn't cover, so I disagree that it's exclusive in some way.

Architecturally speaking, I believe the trust assessment layer is everything after the DKIM crypto piece says "yes" or "no", and that includes policy (ADSP, ATPS, TPA, whatever), reputation, and everything else that is done post-DKIM during delivery or routing (local signature parameter constraints, for example).  It is certainly important, but is also external.

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

---

From: Hector Santos <[email-masked]>
Date: Fri, 15 Apr 2011 08:27:40 -0400

Murray S. Kucherawy wrote:
> Consensus so far (pulling in pre-WGLC comments on the same topic) is to keep 
> the text as-is, and so far I concur with that position.  I don't believe any of 
> the proposed changes so far do anything to clarify or correct anything 
in here.
> 
> There's been concern expressed that the list of examples in 2.3 
> specifically exclude some possible models of DKIM use, but I disagree.  
> A "person, role or organization" certainly can include an author or author's 
> domain, a third-party signer, an MLM, a certifying service, a policy evaluator, 
> an arbitrary intermediary, or any entity at all.  I haven't seen or invented an 
> example yet that this doesn't cover, so I disagree that it's exclusive 
in some way.

Overall I don't disagree and I follow your reasoning, 2.3 is 
highlighting that among all the identities possible, only one can be 
trusted by an independent 3rd party we all have a practical reason to 
reason to trust.  All the other identity can't be trusted, regardless 
if they authorized.

If that understanding is correct, then isn't the 2.3 going into 
implementation details and risk eliminating the other implementation 
methods that uses policies to authenticate identities?

Another way to view this is the realistic (configuration & setup, 
locally or remote) question all domains will face when deploying DKIM:

       What domain is used for signing my mail?

I think it is appropriate for the Deployment Guidelines to help with 
that question, but ultimately, it comes down to selecting a domain 
that is authorized to signed and hopefully one that is remotely viewed 
as a trusted signer.

I believe section 2.3 attempts to summarized the possible signing 
identities or entities.

So in that vain, one may view all the identities are implicitly 
authorized and trusted. (Note, this is how our F1 online help 
describes the selection of the signer.)

But since 2.3 attempts to convey there is only trusted identity - the 
independent signer, I think it should made clearer one way or another 
what it says about trust for the other identities and/or add the 
semantics that they are naturally authorized with the exception that 
independent signers do not need to be authorized.

If your goal is to mature a mindset that only 1 identity can be 
trusted, then the text is good for that.

If your goal is to mature a mindset the identities are naturally 
presumed to be authorized and trusted, then the text is ambiguous in 
that regard.

My proposed text attempts to inject the idea that at least one 
identity is an author authorized signer distinct from what is already 
stated as an independent trusted identity.

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

---

From: Barry Leiba <[email-masked]>
Date: Fri, 15 Apr 2011 09:05:25 -0400

> stated as an independent trusted identity.

But I don't think the actual "author" (in the case of this message,
me, the guy who's writing it) is involved in any way in the signing.
I certainly am not authorizing anyone to sign this message, and likely
don't know whether it will be signed or not.  The DKIM model says
that's done at the domain level, independent of the author's wishes or
actions.

It's possible to have use cases where the author does decide, somehow,
whether or not the message will be signed, but I'm not aware that
anyone's doing that, or has plans to do that.

Barry, as participant

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Fri, 15 Apr 2011 08:50:04 -0700

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Barry Leiba
> Sent: Friday, April 15, 2011 6:05 AM
> To: Hector Santos
> Cc: Murray S. Kucherawy; [email-masked]
> Subject: Re: [ietf-dkim] [dkim] #1: Suggestion to change text in section 2.3
> 

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.

---

From: Dave CROCKER <[email-masked]>
Date: Fri, 15 Apr 2011 09:23:27 -0700

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.

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

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.

d/

-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Hector Santos <[email-masked]>
Date: Fri, 15 Apr 2011 13:34:57 -0400

Barry Leiba wrote:
> whether or not the message will be signed but I'm not aware that

We have plans to offer it as part of our DKIM commerce package for our 
private/public hosting customers.  It would be quite presumptuous to 
sell a DKIM package thats only sign at the domain level.

In any case, there are many DKIM deployment ideas. So I would always 
lean towards making it possible (keen it open-ended) while we can 
during specs design if its makes sense, not redundant and doesn't 
conflict with anything else.

In my last post, I was using "author" to mean the author domain or the 
"originating controlling" identity that decides who will be the 
authorized (by mere selection perhaps) identity to sign.  It did cross 
my mind thought if the current text meant:

     Author                  --> user?
     Author's Organization   --> user domain?

So maybe I should of used "Author's organization Authorized Signer" :)

-- 
HLS

---

From: Hector Santos <[email-masked]>
Date: Fri, 15 Apr 2011 14:58:53 -0400

> consequence, I'm not understanding why it is being discussed at length here, yet 

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

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

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

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Fri, 15 Apr 2011 12:10:46 -0700

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Hector Santos
> Sent: Friday, April 15, 2011 11:59 AM
> To: [email-masked]

All of that discussion belongs in the deployment document or some unwritten specs about policy or reputation (which is all semantics), not in the base specification (which is all syntax).

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Fri, 15 Apr 2011 12:30:35 -0700

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Murray S. Kucherawy
> Sent: Friday, April 15, 2011 12:11 PM
> All of that discussion belongs in the deployment document or some
> unwritten specs about policy or reputation (which is all semantics),
> not in the base specification (which is all syntax).

In fact, I suggest this is already made clear in Sections 2.5 and 2.7.

---

From: Hector Santos <[email-masked]>
Date: Fri, 15 Apr 2011 16:15:08 -0400

> not in the base specification (which is all syntax).

Exactly. +1.  It is about syntax and not about unwritten specs for 
reputation based implementation layers using an identity example of an 
independent trust assessment service.

Why isn't an authorized signer an identity example?

Or if we have trouble with the word "authorized" why isn't "signer 
domain," "responsible signer," or just "signer" listed as an examples 
when in fact, in section 2.5 the SDID is described as an identity?

Why can't any other stated examples for identities can be trusted?

I fail to understand what the base spec section 2.3 is trying to 
define as identities under the context of DKIM which should be 
independent of subjective evaluation layers?

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Fri, 15 Apr 2011 13:49:50 -0700

> Sent: Friday, April 15, 2011 1:15 PM

It is.  The question is: Is it harmful not to list it explicitly?  There doesn't seem to be support for that idea so far.

> independent of subjective evaluation layers?

But that's exactly what it's doing: It's delivering an identity specifically without assigning any value or meaning to that name.  That belongs in other layers.  It is, therefore, just as you said: It's independent of subjective evaluation layers.

And that means the definition is fine as-is.

---

From: Dave CROCKER <[email-masked]>
Date: Sat, 16 Apr 2011 09:38:01 -0700

> All of that discussion belongs in the deployment document or some unwritten specs about policy or reputation (which is all semantics), not in the base specification (which is all syntax).

+1

It's more fun to re-fight old battles that are out of scope for the current 
work, but it's not nearly as productive.

d/

-- 

   Dave Crocker

---

From: Hector Santos <[email-masked]>
Date: Sat, 16 Apr 2011 17:18:02 -0400

> work, but it's not nearly as productive.

This is not fun.

It is 100% in scope. An authorized signer is a natural identity of the 
DKIM consideration, implementation, deployment and a major efficacy 
and durability factor.

The surreal aversion to include this identity in section 2.3 needs to 
be explained based on the dearth of technical merits as an DKIM 
dentity.  That is not have been done, and doing so would be a 
productive time well spent.

The intentional neglect for excluding a valuable DKIM identity 
component is not an acceptable engineering solution.

-- 
HLS

---

From: Hector Santos <[email-masked]>
Date: Sat, 16 Apr 2011 18:11:07 -0400

Hector Santos wrote:
> identity.  That is not have been done, and doing so would be a 

As a follow up:

If the WG problem is the the simple issue compromising two word term 
"authorized signer" for section 2.3,  there is still corrections to be 
made.

Issue Evidence of Conflict:

1) Section 2.5 defines SDID as a responsible identity with a high 
emphasis *mandatory* payload output for DKIM.  However, this mandatory 
identity is excluded in section 2.3.

2) Section 2.7 Identity Assessor describes functional modeling for 
using the mandatory output SDID as the minimum input. However, this 
mandatory identity is excluded in section 2.3.

Corrective Solution:

In section 2.3:

    A person, role, or organization.  In the context of DKIM, examples
    include the author, the author's organization and responsible
    signer identities along the handling path as described in
    section 2.1.

In section 2.7:

2.7.  Identity Assessor

    A module that consumes DKIM's mandatory payload, which is the
    responsible Signing Domain Identifier (SDID).  The module is
    dedicated to the assessment of the delivered identifier, such
    as an independent trust assessment service.

    Other DKIM (and non-DKIM) values can also be delivered to
    Identity Assessor modules.  However, this additional activity
    is outside the scope of the DKIM signature specification.

---

From: Hector Santos <[email-masked]>
Date: Sun, 17 Apr 2011 11:05:42 -0400

Murray S. Kucherawy wrote:
> It is.  The question is: Is it harmful not to list it explicitly?  
> There doesn't seem to be support for that idea so far.

Which makes very strange.

If you think it is, and had proposed it as I think you might have 
being a "putting it all together" software engineer, we would get 
traction.  The question then might be: what is the harm by adding this 
natural DKIM identity?

Anyway, overall, it is about continuing and promoting positive 
development for Policy and related extensions which is almost 
certainly the most active work beyond DKIM-BASE completion. The DKIM 
trust model does not deal with the DKIM faults and has yet to prove 
itself.  It requires the model the SSL Intermediate CA market enjoys 
with all industry browsers (our DKIM verifiers) all supporting a 
common database.  It may even need something like the OCSP (Online 
Certificate Status Protocol) used by the Browsers for SSL.   This is 
going to be very long term.

Finally, I believe having the identity will reduce the need to revisit 
the spec when policy becomes more popular.  If by chance a IETF policy 
standard emerges, unrestricted 3rd party signers will be in violation 
of an IETF standard.  If the change it becomes a BCP, they will be now 
in conflict.  At the very least, it helps provide insight to active 
and future implementators that 3rd party signers are not entirely 
unrestricted. It will give software developers something to think 
about.  It will give current and future packages the vision to turn on 
the ADSP Checking Option which is already most likely supported in 
their software.

One last point, section 2.7 Identity Assessor should be the place 
where the "independent trust assessment server (module)" idea should 
be aptly moved to and in the same manner, adding "Policy Assessor 
Module" would be incredible insightful. It leads the way to the next 
phase.  I don't see any harm in that, only good can come from this.

Thanks

-- 
HLS