On 12/3/2011 12:32 AM, Murray S. Kucherawy wrote:
Does a signature by this "on behalf of" signer mean something different
from a regular DKIM signature? It appears the current text means the
answer to be yes.
Correct, inasmuch as there are some people in the community who think author
domain signatures might be more important or valuable than others. This memo
doesn't make such an assertion, but merely acknowledges that perception.
Understood. I meant the this as a writing question; the meaning wasn't clear to
me and I think it needs to be easily clear to the reader.
So I suggest for the Abstract:
This specification modifies Domain Keys
Identified Mail (DKIM) by allowing advertisement of third-party
signature authorizations that are to be interpreted as equivalent to a
signature by the administrative domain of a message's author. The supplement
initially has Experimental status.
(I think it's important for an Abstract to summarize the core semantic.)
Also, the original text said 'originator' and I think you don't mean that, since
that equates to the Sender: field and not the From: field, per RFC 5598.
I also suggest:
3. Discussion
...
o Signers, who send mail on behalf of Authors and apply [DKIM]
signatures using their own domains; and
->
o Signer, which applies a [DKIM] signature using its own domain,
but on behalf of the message's Author ADMD; and
{ Stylistically, I find that specification text is easier when things are
written in the singular. So I suggest author (ADMD), signer and verifier,
rather than their plural form. }
and
A Verifier participates in this protocol if it wishes to ensure that
a message bears one or more signatures from sources approved to sign
mail on behalf of the Author, and identify for special treatment mail
that meets (or does not meet) that criterion.
->
A Verifier participating in this protocol treats the signer's
authorization on behalf of the author's ADMD as meaning that the signer's
signature is equivalent to a signature by the author's ADMD.
That is, I'm pressing for having this semantic made clear more than once in the
document, even though it needs formal, normative assertion only once (of course).
On re-reading, I think this also warrants an enhanced statement in the
Introduction (roughly from the view that an Introduction expands on the Abstract.)
So:
Absent is a protocol by which an ADMD can announce that DKIM
signatures on its mail added by other ADMDs should also be considered
trustworthy by verifiers. This memo presents an experimental
mechanism for doing so.
->
Absent is a protocol by which an Author ADMD can announce that specific
DKIM signatures on its mail, which are added by other ADMDs, are to
treated the same as a signature by the Author ADMD itself. This memo
presents an experimental mechanism for doing so.
{BTW, the document should be sanitized of normative vocabulary that is not meant
to be normative. That is, replace should, must and may with synonyms. }
It should say this explicitly. If it is not redefining the existing,
core DKIM semantic, it should say so. If it /is/ changing basic DKIM
semantics, then this is more than an "extension" to DKIM.
It is not.
Thinking a bit more about this, actually, I think it is.
With a normal DKIM signature, the d= string is taken as the output to the
higher-level module that then makes whatever reputation (or the like) assessment
that is to be performed.
With ATPS, the requirement is to replace the d= string with the domain name from
the From: field. That replacement value is then passed to the assessment module.
In other words, DKIM provides it's own identifier to be used for assessment,
whereas ATPS dictates use of the From: field domain name for assessment.
That's a fundamental change in semantics.
Section 1 of this draft reiterates that DKIM's core semantics don't extend
toany kind of binding of the delivered, validated domain name to any part of the
message. However, there are some people who believe that such a binding is valid
and useful. This draft is meant for those people, without altering DKIM's base
semantics.
ack.
I suggest that the incremental semantic should merely be that the
signature by an authorized signer should be interpreted as if the
signature had been by the authorizing domain.
It's a simple semantic and is, frankly, what I think is intended, based
on the discussions surrounding this mechanism that I've heard.
This is stated in Sections 5 and 6.
Indeed, they do.
And while we're in Section 5 (DKIM): the SHOULD needs to be a MUST.
With respect to DKIM itself, this new mechanism has one simple semantic: Use
the domain name in the From: field as the output. That's not optional and
that's not modifiable. If the verifier is playing in the ATPS sandbox, that's
the single immutable requirement.
With respect to section 6 (ADSP), I suspect the situation is more complicated
than "SHOULD" admits. The core question is what the publisher intends and the
problem with the current spec is that the verifier cannot be sure.
One possibility is a simple, rigid definition of ATPS that says "if there is an
ADSP record and there is an ATPS record, then the verifier MUST treat the
message as passing ADSP.
If everyone agrees that this semantic is the only one to allow, then fine. make
the current SHOULD in Section 6 be a MUST.
If, however, some ADSP publishers will want that semantic but others won't, then
the ATPS publisher needs to publish another parameter to indicate the
interpretation. (Getting complicated, ain't it?)
In plain English, this reads as an update of ADSP but this draft does not update
RFC 5617.
+1
The definition used for "Updates", as I understand it, is that we say "X updates
Y" if someone implementing X really needs also to read Y in order to implement X completely.
I don't think that's true here. In this case, RFC5617 stands on its own just fine without this
addition.
If I should be using some other criteria for doing the "Updates", please let me
know.
Other tidbits:
I haven't done an audit, but is there any vocabulary from DKIM or ADSP that is
used in this draft? If so, those documents should be cited in the Definitions
section.
(Complete diligence would require declaring which terms are imported, but I'd
find that task onerous enough for myself that it makes it doubtful I'd dictate
anyone else do it...)
4.1. Extension to DKIM
...
For creating records in the DNS, a hash algorithm needs to be
selected.
This needs to be motivated. Why is this being done? Why is it required to be
done? Some introductory explanation will help quite a bit.
The Signer and the Author have to agree on which hash is
to be used, since the Author places a corresponding record in its DNS
and the Signer will have to indicate in its generated signatures
which hash algorithm the Author is using.
I'm not easily understanding why any of this is needed.
If they do match, the Verifier issues a TXT query to the DNS at a
specific name looking for confirmation by the Author that the Signer
is authorized by the Author to sign mail on its behalf. Where
It's pretty cryptic to say "specific name" and not specify what it is. Perhaps:
...at the domain name associated with the Author ADMD, as defined below...
{ actually a sub-section citation to the 'below' algorithm would also help. }
Hmmm. The hash appears to be used to generate a string that's a bit like a DKIM
selector? Is this to have a single string be used for referencing the
authorized domain name, rather than to have more DNS sub-tree name structure?
If so, I suppose that's clever, but is the added complexity worthwhile? I don't
see why just using the plain authorized domain name -- as substructure to the
authorizing domain name (separated by the _atps node) -- isn't sufficient.
7. Experiment Process
Kudos for including this section.
The working group that developed DKIM was not convinced that third
party assertions were critical to DKIM's success, nor were they
likely to be immediately useful. However, this was not based on
The working group that developed DKIM considered a third-party mechanism
like ATPS to be highly controversial, in terms of need and practicality and
decided that an alternative mechanism was sufficient. However...
I think it's important to give some sense that there was serious disagreement
and that it was vigorous. Your current language might let the reader think that
this merely wasn't considered very much...
With respect to the earlier discussion, I think the current draft also needs to
explain that the DKIM wg decided that sub-domain delegation was sufficient.
My above text asserts the existence of an alternative. I think it needs to be
explained, as well as the arguments against DNS sub-domain delegation that
motivate the current spec. I actually think that discussion belongs in the
Introduction.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf