DomainKeys Identified Mail (DKIM) Authorized Third-Party Signatures
RFC 6541

[Ballot discuss]
IANA suggests that the registry be created now, even if it will not
  be used for some time.  Thanks to Alexey Melnikov for asking the
  question in his Gen-ART Review.

[Ballot comment]
This is a fine document. It's especially helpful to describe how the experiment will be run.

I have one small comment: please consider adding a brief sentence about internationalized domain names (IDNs). I realize that RFC 6376 specifies encoding of IDNs as A-labels, but it might be good to reinforce that message here, such as (in Section 4.2):

  "domain-name" and "key-h-tag-alg" are defined in [DKIM].  Note
  that according to [DKIM] internationalized domain names are to be 
  encoded as A-labels, as described in Section 2.3 of [RFC5890].

This would necessitate adding an informative reference to RFC 5890, if you decide to make such a change.

[Ballot comment]
This is a fine document. It's especially helpful to describe how the experiment will be run.

I have one small comment: please consider adding a brief sentence about internationalized domain names (IDNs). I realize that RFC 6376 specifies encoding of IDNs as A-labels, but it might be good to reinforce that message here, such as (in Section 4.2):

  "domain-name" and "key-h-tag-alg" are defined in [DKIM].  Note
  that according to [DKIM] internationalized domain names are to be 
  encoded as A-labels, as described in Section 2.3 of [RFC5890].

[Ballot comment]
This is a fine document. It's especially helpful to describe how the experiment will be run.

I have one small comment: please add a brief sentence about internationalized domain names (IDNs). I realize that RFC 6376 specifies encoding of IDNs as A-labels, but it might be good to reinforce that message here, such as (in Section 4.2):

  "domain-name" and "key-h-tag-alg" are defined in [DKIM].  Note
  that according to [DKIM] internationalized domain names are to be 
  encoded as A-labels, as described in Section 2.3 of [RFC5890].

[Ballot comment]
1. "ATPS" is never expanded in the text before its use. Please do so in the intro.

2. The ABNF for atps-query should put an upper limit of 63 for the number of BASE32 characters:

  atps-query = 1*63BASE32 %x2e.5f.61.74.70.73.2e domain-name

3. Is there reason to believe that, in practice, the hashing is really needed? Do we really believe that the combination of the two domain names will exceed 255 characters?

4. Given that this is an experiment, is there any reason not to give this a go with a new DNS query type? (Yeah, yeah, I know. But I thought I'd ask.)

[Ballot discuss]
IANA suggests that the registry be created now, even if it will not
  be used for some time.  Thanks to Alexey Melnikov for asking the
  question in his Gen-ART Review.

[Ballot comment]
intro: is "treated the same" a good way to describe this? It seems
vague, maybe you mean "treated identically for ADSP purposes" or
something like that? If not, then I think you want to say that
"same" means for all possible uses of DKIM signing I think.

s3: "communicated via a new tag in the DKIM signature"  seems to
conflict with s4.1 "via the presence of a DNS TXT record" I think
the "This" in "This is communicated to..." in s3 is unclear, maybe
replace that with "The fact that a signature is ostensibly by a
delegate for another domain is communicated..." or something
similar.

s4.4: "MUST continue to the next query" seems wrong when you get an
NXDOMAIN - what if there's only one query ever? I know you sort of
explain after the bullet list but it seems oddly phrased.

s8.3: Why is [AUTHRES] only discussed in the IANA section?  Surely
at least a mention that those exist should occur in the intro as
well.

[Ballot discuss]
#1 I don't agree that sha1 is really ok as default here.  If the
hash function is broken for collisions then I could generate a
colliding domain name and them my signatures with d=
will be accepted by the Verifier as the author's ADMD. That
will not be detectable from the DNS queries and responses.
(Adding the good guy atps domain name into the DNS
response would help with collision resistance btw.) I think the
experiment therefore needs to be based on our best current hash
function which is sha256 (and that matches DKIM anyway). If that
causes some DNS response size issues then the experiment can report
on that and a future spec can deal with it if necessary. 

#2 s4.4: if version=2 is returned to a version 1 Verifier should it
treat that as ok or not? I don't care, but best to say really.

We understand that this document doesn't require any IANA actions.

Actions will be required if the document is moved to Standards Track
status, but we understand that another Last Call would be issued at that
time.

State changed to In Last Call from Last Call Requested.

The following Last Call Announcement was sent out:

From: The IESG
To: IETF-Announce
CC: ietf-dkim@mipassoc.org
Reply-To: ietf@ietf.org
Subject: Last Call:  (DKIM Authorized Third-Party Signers) to Experimental RFC


The IESG has received a request from an individual submitter to consider
the following document:
- 'DKIM Authorized Third-Party Signers'
  as an Experimental RFC

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2011-12-28. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract

  This memo presents an experimental proposal to supplement Domain Keys
  Identified Mail (DKIM) by allowing advertisement of third-party
  signature authorizations on behalf of an email originator.

The file can be obtained via
http://datatracker.ietf.org/doc/draft-kucherawy-dkim-atps/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-kucherawy-dkim-atps/

No IPR declarations have been submitted directly on this I-D.

PROTO writeup for draft-kucherawy-dkim-atps-11

The publication of draft-kucherawy-dkim-atps-11 as an Experimental RFC is requested by an individual contributor.

  (1.a) Who is the Document Shepherd for this document? Has the
        Document Shepherd personally reviewed this version of the
        document and, in particular, does he or she believe this
        version is ready for forwarding to the IESG for publication?

Barry Leiba is the document shepherd.  I have reviewed this version, and am satisfied that it's ready.

  (1.b) Has the document had adequate review both from key WG members
        and from key non-WG members? Does the Document Shepherd have
        any concerns about the depth or breadth of the reviews that
        have been performed? 

The document has adequate review, and I have no concerns.

  (1.c) Does the Document Shepherd have concerns that the document
        needs more review from a particular or broader perspective,
        e.g., security, operational complexity, someone familiar with
        AAA, internationalization or XML?

I have no concerns.

  (1.d) Does the Document Shepherd have any specific concerns or
        issues with this document that the Responsible Area Director
        and/or the IESG should be aware of? For example, perhaps he
        or she is uncomfortable with certain parts of the document, or
        has concerns whether there really is a need for it. In any
        event, if the WG has discussed those issues and has indicated
        that it still wishes to advance the document, detail those
        concerns here. Has an IPR disclosure related to this document
        been filed? If so, please include a reference to the
        disclosure and summarize the WG discussion and conclusion on
        this issue.

I have no concerns.  There is no IPR involved.

  (1.e) How solid is the WG consensus behind this document? Does it
        represent the strong concurrence of a few individuals, with
        others being silent, or does the WG as a whole understand and
        agree with it? 

This is an individual submission, and has been reviewed on the former DKIM mailing list.  There is good consensus on proceeding with it as Experimental.

  (1.f) Has anyone threatened an appeal or otherwise indicated extreme
        discontent? If so, please summarise the areas of conflict in
        separate email messages to the Responsible Area Director. (It
        should be in a separate email because this questionnaire is
        entered into the ID Tracker.)

No.

  (1.g) Has the Document Shepherd personally verified that the
        document satisfies all ID nits? (See the Internet-Drafts Checklist
        and http://tools.ietf.org/tools/idnits/). Boilerplate checks are
        not enough; this check needs to be thorough. Has the document
        met all formal review criteria it needs to, such as the MIB
        Doctor, media type and URI type reviews?

The document is clean and nit-free.  IDnits has some false positives, where it thinks some things in square brackets are citations, which aren't.

  (1.h) Has the document split its references into normative and
        informative? Are there normative references to documents that
        are not ready for advancement or are otherwise in an unclear
        state? If such normative references exist, what is the
        strategy for their completion? Are there normative references
        that are downward references, as described in [RFC3967]? If
        so, list these downward references to support the Area
        Director in the Last Call procedure for them [RFC3967].

All references are properly separated and labelled.  There are no downward references.

  (1.i) Has the Document Shepherd verified that the document IANA
        consideration section exists and is consistent with the body
        of the document? If the document specifies protocol
        extensions, are reservations requested in appropriate IANA
        registries? Are the IANA registries clearly identified? If
        the document creates a new registry, does it define the
        proposed initial contents of the registry and an allocation
        procedure for future registrations? Does it suggest a
        reasonable name for the new registry? See [RFC5226]. If the
        document describes an Expert Review process has Shepherd
        conferred with the Responsible Area Director so that the IESG
        can appoint the needed Expert during the IESG Evaluation?

The IANA Considerations section is correct and adequate.  It is unusual, in that it specifies future IANA actions, to be taken if/when the document should move to Standards Track.  At this time, there are no IANA actions to be taken, and IANA Considerations says that.  We need to make sure that IANA understands that.

  (1.j) Has the Document Shepherd verified that sections of the
        document that are written in a formal language, such as XML
        code, BNF rules, MIB definitions, etc., validate correctly in
        an automated checker?

The formal grammar is correct, and validates.

  (1.k) The IESG approval announcement includes a Document
        Announcement Write-Up. Please provide such a Document
        Announcement Write-Up? Recent examples can be found in the
        "Action" announcements for approved documents. The approval
        announcement contains the following sections:

    Technical Summary
        Relevant content can frequently be found in the abstract
        and/or introduction of the document. If not, this may be
        an indication that there are deficiencies in the abstract
        or introduction.

DKIM deliberately makes no binding between the DNS domain of the signer of a message and any other identity found in the message.  Despite this, there is an automatic human perception that an author domain signature (one for which the RFC5322.From domain matches the DNS domain of the signer) is more valuable or trustworthy than any other.  There is currently no 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 presents an experimental mechanism for doing so.


    Working Group Summary
        Was there anything in WG process that is worth noting? For
        example, was there controversy about particular points or
        were there decisions where the consensus was particularly
        rough?

This is an individual submission, but was discussed with the former DKIM participants, on the DKIM mailing list.  Note that there is NOT general agreement that this protocol is important, or even useful.  There is good consensus that experimentation is needed to determine utility, and this document sets up that experiment by proposing a protocol for it.

    Document Quality
        Are there existing implementations of the protocol? Have a
        significant number of vendors indicated their plan to
        implement the specification? Are there any reviewers that
        merit special mention as having done a thorough review,
        e.g., one that resulted in important changes or a
        conclusion that the document had no substantive issues? If
        there was a MIB Doctor, Media Type or other expert review,
        what was its course (briefly)? In the case of a Media Type
        review, on what date was the request posted?
       
ATPS has been prototyped, in preparation for this experiment, and is available in an open-source implementation.  Other implementations are expected as the experiment proceeds.