Subject: Re: Last Call: <draft-kucherawy-dkim-atps-11.txt> (DKIM Authorized Third-Party Signers) to Experimental RFC

From: Frank Ellermann <[email-masked]>
Date: Thu, 1 Dec 2011 12:55:21 +0100

On 1 December 2011 05:09, Murray S. Kucherawy <[email-masked]> wrote:

> so long as experimental-status drafts are allowed to make IANA
> registrations. (I thought they weren't, which is why it is the
> way it is right now.)

Depends on the registry, some registrations need standards track,
others want published RFC, some need IETF consensus, and so on,
down to first come first served.  The author of RFC 5451 wants
"published RFC with IETF review". that's below "standards track",
or in other words, IETF experimental with IETF Last Call is okay.

-Frank

---

From: Hector <[email-masked]>
Date: Fri, 02 Dec 2011 08:52:45 -0500

Dave CROCKER wrote:
> 
> On 11/30/2011 8:09 PM, Murray S. Kucherawy wrote:
>> As the draft says, the point is to make the idea available and see if 
>> it sticks to anyone or anything.  If the bulk senders (or receivers) 
>> do decide they collectively want this, there's something for them to 
>> try and report back.
> 
> if one thinks the mechanism is a bad idea, it's still worth having a 
> good document to describe it.l

The usual people with DKIM continue to utterly surprise me.

#1 The Author Domain verification was always in DKIM since its 
conception, especially as a selling and marketing point, in its 
presentations, and its description to news rags publishers.  It was 
sold DKIM to me as a proof of concept.

#2 It was burned into the APIs available.

#3 It was burned into your DKIM Architectural Framework RFC5585 and it 
even included nice pretty ASCII-ART pictures that I am sure you are 
proud of:

                     |
                     |- RFC5322 Message
                     V
      +--------------------------------+
      |  Message Signed?               |
      +-----+--------------------+-----+
            |yes                  |no
            |                     |
            |SDID/AUID            |AUID
            |                     |
            V                     |
      +-------------+ SDID/AUID   |
      |  Verify     +---------+   |
      |  Signature  |         |   |
      +------+------+         |   |
         pass|            fail|   |
             V                |   |
      +-------------+         |   |
      |    SDID     |         |   |
      | Assessments |         |   |
      |             |         V   V
      +-----+--+----+      +-------+
          |    |          / Check   \
          |    +--SDID-->/  Signing  \
          |             /   Practices \
          |            +-------+-------+
          |                    |
          V                    V

The issue was always how to implement it for 3rd party Signers once 
the DKIM mindset in its eventual RFC changed to a 3rd party signer 
TRUST vendor and vainly tried unsuccessfully to remove the Author 
Domain from the DKIM picture.

The methods for 3rd party Authorization were long conceived and the 
only problem was how to scale it in DNS.  This I-D simply took and 
existing idea of having an Authorized Signer List (ASL) and offers a 
way to scale it.

We are probably the only vendor in the market to actively supports 
both the ASL idea and the ATPS idea.  This is a web-based wizard we 
provided to customers before an internal version was provided:

    http://www.winserver.com/public/wcadsp/default.wct

It allows for DKIM author domains to create DNS records with ASL tags 
for ADSP records and also add ATPS sub-domain records with the BASE32 
hash of the ASL domains.

The bottom line, the proof of concept works, just like it always did 
since it Author Domain validation was originally conceived in DKIM 
v1.0.    The ASL and ATPS ideas simply offers a way to address the 
long time issues of the 3rd party signer.

The idea is good for the smaller scale. For the larger scale, it still 
remains a problem.

Implementation wise, it is very complex and unless the DKIM system 
offers the automation tools, its harder to get the layman operator to 
begin doing it on its own.  After all, with ATPS, you have to get a 
utility to do the BASE32 hashing.

Finally, the public Wizard focused on Windows based records, a real 
one has to cover both and its needs to be BATCH so that any updates 
are automatically and/or delayed updated in the DNS server databases. 
  i.e. individual updating was not good enough.

Thanks

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

---

From: Dave CROCKER <[email-masked]>
Date: Fri, 02 Dec 2011 15:59:14 -0800

On 11/30/2011 12:34 PM, SM wrote:
> "Readers should be familiar with the material and terminology
> discussed in [MAIL] and [EMAIL-ARCH]."
>
> The references to RFC 5598 and RFC 5322 should be normative.

Arguably, they already are:  the text says "should" and that's a normative term 
in the document...  (but no, I doubt Murray, really intended it and for some odd 
reason, I agree both docs /should/ be normative...)

> In Section 3:
>
> "An Author participates in this protocol if it wishes to announce that
> a message from it (in the RFC5322.From sense) should be considered
> authentic as long as it bears a signature from any in a set of
> specified domains."
>
> It's the domain and not the author which participates in this protocol.

+1

Domain-based identification roughly equates to organizational, not personal, 
actors.  Although the document appears to define the term Author precisely and 
use it consistently within the document, the particular label that's been chosen 
is likely to encourage confusion with the reader who will think that "author" 
means the /person/ that wrote the message.

Alternative terms to consider:

    Author Domain

    Organization

    Administrative Domain (ADMD)

> The Abstract section uses the term "authorization" whereas "authentic" is used
> in the above text. Shouldn't that be "considered as authorized"?

+1 on the concern about using the correct term.

The document needs to be much more clear and precise about this, since it is the 
essential semantic behind the spec and I think the current text is a bit 
confusing in that regard.

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

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.

> In Section 6:
>
> "A Verifier implementing both ADSP and ATPS SHOULD treat a message for
> which the ATPS test described above passes as if it were signed by
> the author domain. That is, a pass of ATPS means a pass for ADSP."

> In plain English, this reads as an update of ADSP but this draft does not update
> RFC 5617.

+1

> In Section 8:
>
> "No actions are required by IANA at this time. The following need
> only be applied if and when this specification reaches the Standards
> Track."
>
> The IANA Considerations section is unusual. If no action is required at this
> time, the sub-sections are not needed. I suggest updating the "DKIM-Signature
> Tag Specification Registry" for the tags as they will appear on the Internet.

+1

d/
-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Sat, 3 Dec 2011 00:32:27 -0800

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Dave CROCKER
> Sent: Friday, December 02, 2011 3:59 PM
> To: SM
> Cc: [email-masked]
> Subject: Re: Last Call: <draft-kucherawy-dkim-atps-11.txt> (DKIM Authorized Third-Party Signers) to Experimental RFC
> 
> Arguably, they already are:  the text says "should" and that's a
> normative term in the document...  (but no, I doubt Murray, really
> intended it and for some odd reason, I agree both docs /should/ be
> normative...)

Yes, I've already changed my working copy.

> [...]

The working copy now uses ADMD.

> > The Abstract section uses the term "authorization" whereas "authentic"
> > is used in the above text. Shouldn't that be "considered as authorized"?
> 
> The document needs to be much more clear and precise about this, since
> it is the essential semantic behind the spec and I think the current
> text is a bit confusing in that regard.

SM and I agreed that changing it to "authorized" and also making reference to Section 1.5.2 of RFC5451 for a bit of further explanation should make it clearer, so that's done in the working copy.

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

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

Section 1 of this draft reiterates that DKIM's core semantics don't extend to any 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.

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

> > In plain English, this reads as an update of ADSP but this draft does not update

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.

> > time, the sub-sections are not needed. I suggest updating the "DKIM- Signature

The working copy already has this change; specifically, Section 8.1 is still the template for a future registry creation, but the remaining subsections are now actionable by IANA.

-MSK

---

From: "Rolf E. Sonneveld" <[email-masked]>
Date: Sat, 03 Dec 2011 13:48:31 +0100

Hi, Murray,

having read the draft I support its publication as experimental RFC. One 
suggestion: under 'Security Considerations' add a reference to what is 
said about DNSSEC in RFC6376 par. 8.5. In my opinion, the same 
consideration applies for this ATPS document.

/rolf

On 12/3/11 9:32 AM, Murray S. Kucherawy wrote:
>> Subject: Re: Last Call:<draft-kucherawy-dkim-atps-11.txt>  (DKIM Authorized Third-Party Signers) to Experimental RFC
>>
> _______________________________________________
> Ietf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ietf

---

From: Dave CROCKER <[email-masked]>
Date: Sat, 03 Dec 2011 10:37:30 -0800

On 12/3/2011 12:32 AM, Murray S. Kucherawy wrote:
> 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. }

>> semantics, then this is more than an "extension" to DKIM.

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.

> 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?)

> 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

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Sun, 4 Dec 2011 11:30:23 -0800

> From: Rolf E. Sonneveld [mailto:[email-masked]]
> Sent: Saturday, December 03, 2011 4:49 AM
> To: Murray S. Kucherawy
> Cc: [email-masked]

Thanks; I've added that to the working copy.

Cheers,
-MSK

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Sun, 4 Dec 2011 12:11:14 -0800

> From: Dave CROCKER [mailto:[email-masked]]
> Sent: Saturday, December 03, 2011 10:38 AM
> To: Murray S. Kucherawy
> Cc: [email-masked]

I'm a little worried about using this kind of language in something Experimental when referencing a Draft Standard.  My understanding is that the former can't formally modify the latter.  So instead of "This specification modifies", I'd be comfortable with "This experimental specification proposes a modification to", or suchlike.  Should it earn its way up to the Standards Track, your wording would be adopted.

>        but on behalf of the message's Author ADMD; and

OK.

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

I would agree, but in fact when ATPS is in use there are at least two ADMDs and there may be multiple signers involved for a single verifier, so the plural seems more illustrative here.

>     signature is equivalent to a signature by the author's ADMD.

That ascribes semantics that are discussed later.  This section is really trying to describe the potential audience first, leaving an actual description of the mechanism for later.  So I'd prefer a merge of the two, something like:

                <t> A Verifier participates in this protocol if it wishes
                    to ensure that a message bears one or more signatures
                    from sources authorized to sign mail on behalf of the
                    ADMD, and identify for special treatment mail
                    that meets (or does not meet) that criterion.  It
                    will do so by treating the signer's authorization on
                    behalf of the author's ADMD as meant that the signer's
                    signature is equivalent to one affixed by the
                    author's ADMD. </t>

>     presents an experimental mechanism for doing so.

OK.

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

Done.

> That's a fundamental change in semantics.

If you are using ATPS, sure.  So ATPS augments DKIM's semantics if you're using it.  But I don't think it's reasonable to say this is any kind of update to DKIM itself, at least not in the way the IETF uses the term "Updates" as it refers to RFCs.

At any rate, I think this draft already does make it clear that it's doing something quite beyond what DKIM itself does.

> And while we're in Section 5 (DKIM):  the SHOULD needs to be a MUST.

Why?  The implementation might know something about the third-party that renders it suspicious even if it otherwise trusts the author domain.  In the same way that DKIM avoided requiring specific handling of a message with (or without) a valid signature, I believe this one should avoid forcing one's hand if other information is available.

> the single immutable requirement.

Why wouldn't both the third-party domain and the author domain both be presented for evaluation?

> interpretation.  (Getting complicated, ain't it?)

I think my answer here is the same as it is for Section 5: If the Verifier knows something about the third-party or the author domain that gives it pause about considering the two equivalent, we shouldn't proscribe the use of that information by making these into MUSTs.

> used in this draft?  If so, those documents should be cited in the Definitions

In addition to them being listed as references?  That seems a bit like overkill.

> I'm not easily understanding why any of this is needed.

The Author's ADMD has to add a TXT record to its DNS whose construction is based on a digest of the third-party's name.  The third-party signer has to know which digest is used, because this will be indicated as part of the signature.  Thus, they must agree on which digest is in use.

> { actually a sub-section citation to the 'below' algorithm would also

OK.

> authorizing domain name (separated by the _atps node) -- isn't

This is discussed in Section 9.1.

> Kudos for including this section.

Credit where credit's due: It was Sean Turner's idea.

>     decided that an alternative mechanism was sufficient.  However...

OK.

> this merely wasn't considered very much...

I'm fine with "controversial".

> motivate the current spec. I actually think that discussion belongs in the

Section 3 does cover this, but I'll augment the Introduction accordingly.

-MSK

---

From: "John Levine" <[email-masked]>
Date: 4 Dec 2011 21:27:36 -0000

>whereas ATPS dictates use of the From: field domain name for assessment.

At least one of us is confused here.

ADSP already dictates use of the From: domain.  ATPS is a modification
to ADSP.  It doesn't change anything that DKIM reports, only the rule
for deciding whether ADSP finds an Author Domain Signature.  

With or without ADSP or ATPS, DKIM returns a possibly empty list of d=
domains from valid signatures.  ADSP returns the practices value
(unknown/all/discardable) and a bit whether it found an Author Domain
signature.  Since there might be multiple DKIM signatures, even if
ADSP says it found an Author Domain signature, you can't assume a d=
domain had any relationship to the From: domain.

It's true that ATPS adds a field to DKIM signatures that doesn't
affect DKIM evaluation, but DKIM already knows how to skip over fields
it doesn't understand.

R's,
John

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 5 Dec 2011 13:07:13 -0800

> From: [email-masked] [mailto:[email-masked]] On Behalf Of John Levine
> Sent: Sunday, December 04, 2011 1:28 PM
> To: [email-masked]
> Cc: [email-masked]

ATPS can be applied without ADSP by a Verifier that cares about author domain signatures in its own way, so it's not a direct modification to ADSP.  But there is a section that discusses how they work in tandem.

---

From: Dave CROCKER <[email-masked]>
Date: Mon, 05 Dec 2011 15:54:19 -0800

On 12/4/2011 1:27 PM, John Levine wrote:
> ADSP already dictates use of the From: domain.

The the nature ADSP's use of the From: domain is fundamentally different from 
ATPS' use.

Broadly, we can distinguish:

    Name extraction:    determining what name is being claimed

    Name verification:  determining that the use of the name is authorized

    Name assessment:    determining whether the name is associated with good
                        or bad actor.

ADSP adds a constraint on name verification; it mandates that at least one DKIM 
d= name match the domain in the From: field.

ATPS essentially modifies name extraction, by making it a two-step process. The 
first step is the usual one, with d=, for use with validation, but the second 
one takes the domain in the From: field and makes it the output string to the 
assessment process.

 > ATPS is a modification

While yes it has text pertaining to ADSP, I will claim that with ADSP, too, the 
modification is in name extraction rather than validation or assessment.

d/

-- 

   Dave Crocker

---

From: Dave CROCKER <[email-masked]>
Date: Mon, 05 Dec 2011 15:59:07 -0800

On 11/30/2011 1:03 PM, Barry Leiba wrote:
>> In plain English, this reads as an update of ADSP but this draft does not
>> >  update RFC 5617.
> It does not.  There's no reason that anyone implementing ADSP need pay
> attention to this.*IF*  you implement this, it might change your
> behaviour with respect to ADSP, but information about that is
> contained here.  There's no reason for this to "update" 5617 in the
> IETF sense.

I think Barry's characterization is correct.  The word "update" can have some 
different uses in this realm.

In IETF RFC formal lingo, I believe "update" means that the new spec is 
modifying the core document.  It really is, therefore, to be taken as part of 
that core document's text.

In a very different sense, some specification provide optional value-add to a 
core spec.  Using that enhancement is optional; so it's no part of the core. 
However, if one chooses to use the enhancement, then yes the enhancements 
"updates" some aspect of the core.

I believe that ATPS is the latter form of update to DKIM and ADSP.

d/

-- 

   Dave Crocker

---

From: "John R. Levine" <[email-masked]>
Date: 5 Dec 2011 17:24:36 -0800

> ATPS essentially modifies name extraction, by making it a two-step process. 
> The first step is the usual one, with d=, for use with validation, but the 
> second one takes the domain in the From: field and makes it the output string 
> to the assessment process.

If you're referring to the second paragraph in section 5, I agree that the 
second sentence should go, or at least be rewritten to clarify that the 
client is supposed to pretend that the message passed ADSP.  If it's 
anything else in atps-11, you'll have to help me out with references to 
specific language.

R's,
John

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 5 Dec 2011 17:48:35 -0800

> From: [email-masked] [mailto:[email-masked]] On Behalf Of John R. Levine
> Sent: Monday, December 05, 2011 5:25 PM
> To: Dave Crocker
> Cc: [email-masked]
> If you're referring to the second paragraph in section 5, I agree that
> the second sentence should go, or at least be rewritten to clarify that
> the client is supposed to pretend that the message passed ADSP.  If
> it's anything else in atps-11, you'll have to help me out with
> references to specific language.

But that's what Section 6 says.

Section 5 is for those people that do DKIM without ADSP but care about giving author domain signatures preferential treatment.

---

From: "John Levine" <[email-masked]>
Date: 6 Dec 2011 05:05:04 -0000

>Section 5 is for those people that do DKIM without ADSP but care about
>giving author domain signatures preferential treatment.

Since there's nothing in the DKIM spec that suggests that's a correct
way to use DKIM, I'd be fairly unhappy about any language that
purports to legitimize it.

Here in standards-land, if you think that author domain signatures
matter, you're supposed to use ADSP.

R's,
John

---

From: Douglas Otis <[email-masked]>
Date: Thu, 08 Dec 2011 10:11:50 -0800

I support adoption of dkim-atps as an experimental RFC.  It would have 
been clearer to use the term Author-Domain rather than Author.  Clearly, 
it is not the Author offering Authorization.

-Doug

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 8 Dec 2011 11:11:58 -0800

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Douglas Otis
> Sent: Thursday, December 08, 2011 10:12 AM
> To: [email-masked]
> been clearer to use the term Author-Domain rather than Author.
> Clearly, it is not the Author offering Authorization.

This has already been fixed in the working copy, which I'll post after the IETF LC closes.

-MSK