Murray S. Kucherawy wrote:
>> 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).
My apology but please view that take like "I'm giving up, You should
read the specs correctly, Please Stop, We should be done. etc", none
attributed anyone person, does make anyone giggle either.
>> #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.
I don't think u read this right. Not saying it is bad - but its the
only receiver mandate at the expense of others. No mandate can tell
receivers what to do. All options need to be presented.
> This is completely appropriate in another way: The SDID from a
> valid signature is the only thing that DKIM "proves".
Ok, very good. It tells you the payoff value for SDID and its ok, to
say its a mandatory identity receivers to look at. but its should be
the exclusive one highlighted.
>
>> #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.
It clearly stated the obvious but not specific enough with DKIM
related semantics - "Being Specific is Terrific!"
> I can't imagine any DKIM verifier module based on RFC4871 that
> would thus become non-compliant when compared to RFC4871bis.
I didn't make that claim. What I said is that it hasn't learned.
> 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.
The problem here is that we are trying to dictate how to use it. DKIM
did it write in abstract terms and it should continue with that
exposure. You don't have to get into the details and that because
AUID is still controversial, but making it available will prepare for
the future.
Personally, I think the definition for it be the SDID domain or
subdomain should be a MAY and to begin teaching verifiers that a
mismatch should not invalidate the signature which is only a domain
comparison check and not a hash bound violation issue.
> So, please read the Output Requirements again and explain to me
> the basis for this claim.
See above.
>> 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".
Well, who's right you or me? I think its natural engineering to be
protocol consistent among all integrated parts.
>> 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.
I stated what I believe are the four minimal extracts for DKIM output
and mail integration:
signature verify status
SDID
AUID
ODID
--
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
