-----Original Message-----
From: ietf-dkim-bounces(_at_)mipassoc(_dot_)org
[mailto:ietf-dkim-bounces(_at_)mipassoc(_dot_)org] On Behalf Of Hector Santos
Sent: Wednesday, May 04, 2011 9:17 AM
To: dcrocker(_at_)bbiw(_dot_)net
Cc: ietf-dkim(_at_)mipassoc(_dot_)org
Subject: Re: [ietf-dkim] Output summary - proposing ODID "Originating Domain
Identity"
Its absolutely amazing how the main points are just blow away. Wow!
Can we remain professional, please? This flare for the dramatic only drags the
group down further into the mire (as if that's possible).
#1 NEW - The key difference as so many others has stated is the
MANDATORY mandate for the single output, SDID, with a MUST design
mandate for a futuristic single Trust Identity Assessor module.
I can't imagine any successful DKIM verifier module based on RFC4871 that
didn't output at least the SDID and a status for the signature, for each
signature. Thus, saying so in RFC4871bis doesn't seem to me to be a normative
change that breaks anything.
This is completely appropriate in another way: The SDID from a valid signature
is the only thing that DKIM "proves".
#2 NEW - RFC4871bis introduces the AUID identity as a MAY for the
trust module, *yet* this optional consideration is excluded from the
RFC4871bis Output Requirements.
It's true that the AUID is not listed as mandatory output, but that section
very clearly states that a verifier could output other stuff, including the
AUID, to a module that wants it. I can't imagine any DKIM verifier module
based on RFC4871 that would thus become non-compliant when compared to
RFC4871bis.
But the AUID is only partially "proven" by DKIM; the local-part, for example,
is potentially garbage, as is the subdomain. So it makes sense not to make it
a mandatory output of a security protocol.
So, please read the Output Requirements again and explain to me the basis for
this claim.
Incidentally, my concerns as well of many other implementors predated
RFC4871 (2007 publication) with the drafting leading to the separation
of policy and all policy related semantics from the base. This was a
major concerns cited by many including the prediction that policy will
be not be completed as a standard.
And such separation occurred. And it was good.
The goal was to remove the Author Domain (ODID) from DKIM and move it
to *purported* chartered proposed standard for policy, then called
SSP. We completed WG consensus built requirements SSP document
(RFC5017) and eventually ADSP (RFC5617).
Right.
In the name of protocol consistency and synergism with completed
chartered RFC work products, it is only natural to expect the ODID
MUST be part of the output identities for RFC4871BIS which should
reflect all the RFC work that was done since RFC4871.
No, that's not "natural".
Instead we have:
#3 NEW: RFC4871BIS Output requirements that do not reflect any other
work that as done, including this so called "DKIM Service
Architecture."
-1. RFC4871bis very clearly includes all the work that's been done, unless you
have some other input that hasn't been revealed to date.
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html