ietf-dkim
[Top] [All Lists]

Re: [ietf-dkim] Moving to consensus on draft-ietf-dkim-rfc4871-errata

2009-03-20 17:54:30
On March 10, 2009, I wrote:
DKIM Chair wrote:
  
To those who voted against draft-ietf-dkim-rfc4871-errata: given, now, that 
we 
will be using draft-ietf-dkim-rfc4871-errata to move forward, and the other 
choices are off the table, can you accept draft-ietf-dkim-rfc4871-errata as 
written?  If not, will you post specific changes, in OLD/NEW format, that 
would 
make it acceptable to you?  Acceptable changes must keep the sense of the 
draft-ietf-dkim-rfc4871-errata document with regard to the new terminology.
  
    

I can do that, but it will probably take a few days.
Here are the rest of my comments on the draft.  My comments are based on
draft-ietf-dkim-rfc4871-errata-02 with the additional change from UAID
to AUID.  Perhaps "user or agent" should also change to "agent or user"
but I'm neutral on that.

0. Change the title to "RFC 4871 Update" if it is not being processed
using the errata process per Pasi's comments.

=====

1. Introduction.  The introduction, particularly paragraphs 2 and 3,
assert that the payload (the output of DKIM verification) is only a
validated signing domain.  The output of DKIM verification is
considerably more than that:  there are a great many values, such as the
list of signed header fields, that may be useful to an assessor and that
must be made available to the assessor if the verifier is to be as
interoperable with as many assessors as possible.  Furthermore, not
requiring a verifier to output unknown tag/values makes DKIM
non-extensible:  What's the point of adding new tag/value definitions if
all the verifier is going to output is the SDID?

RFC 4871 somewhat narrowly defines a protocol between the signer and
verifier.  It does not define the semantics of everything that DKIM
might convey; that was left for the overview and/or operations
documents.  To say that RFC 4871 has the potential for non-interoperable
interpretations of how DKIM operates is to criticize the specification
for something that is out of its scope.

Suggested change:  Replace everything beginning with paragraph 2 of the
introduction with the following (and delete the remainder of the
introduction):

NEW:

Hence, DKIM has a signer that applies a signature to a message, a
verifier that confirms the signature, and DKIM interfaces with an
assessor what consumes the validated signing information.  This document
attempts to clarify the meaning of identifier fields appearing in the
DKIM signature to arrive at a more consistent use of these fields by
verifiers.

=====


6. SDID definition

I am confused by the definition of the SDID as opaque.  This makes it
sound like it's a pseudonym for the actual signing domain.  The fact
that it's possible to look up information about the SDID using DNS
doesn't seem opaque to me.

OLD: A single, opaque value that is the mandatory payload output of DKIM

NEW: A single value that is a mandatory payload output of DKIM

=====

7. AUID definition

Portions of the AUID are opaque, but not the whole thing because it has
to have a specified relationship with the SDID.  I would also clarify
that there is always an AUID, even if it isn't explicitly specified in
the signature and takes its default value.

OLD: A single, opaque value that identifies the user or agent on behalf
of whom the SDID has taken responsibility.  It is specified in Section 3.5.

NEW: A single value that identifies that agent or user on behalf of
which the SDID has taken responsibility.  The AUID has the syntax of an
email address, although the local-part and any subdomain of the SDID
which is used are opaque values which may not actually exist nor have
any relationship with other identifiers in the message.  It is specified
in Section 3.5.  The AUID takes the default value specified if it is not
explicitly present in the signature.

=====

8. Identity Assessor

The term is imprecise:  it is not assessing an identity but a message. 
Suggest replacing this name with just "assessor" as is used in the
Introduction.

=====

9. d= tag definition

The corrected text removes the required relationship between the SDID
and the AUID, which is perhaps repetitive of information in the i= tag
definition, but which we felt important to repeat in the original
document for emphasis.  The narrative about "conventions and semantics"
does not belong in the normative text describing the tag, and I'm not
clear what it's trying to say in any case.  The text also repeats much
of the wording in the definition of SDID about claiming responsibility
and such.

NEW:

The SDID of the signing entity (plain-text; REQUIRED).  This is the
domain that will be quieried for the public key.  The SDID MUST be the
same as or a parent of the domain in the AUID (the "i=" value, as
described below) and MUST meet the requirements for parent domain
signing described in Section 3.8.  When presented with a signature that
does not meet these requirement, verifiers MUST consider the signature
invalid.

=====

10. i= tag definition

paragraph 2, simple change:

OLD:

value of the "d=" tag.

NEW:

SDID.

[There are probably many more places in 4871 where words like this could
be changed to the new terminology.  Should this update those as well,
for clarity?]

=====

11. Signing by Parent Domains

Small change, also in the original text:

OLD:

domain of the AUID ("i=" flag)

NEW:

domain of the AUID ("i=" value)

=====

12. Relationship between SDID and AUID

This is another place where I'm having a problem with the premise that
all a verifier needs to output is the SDID.  This section is engaging in
considerable discussion about the relationship of the SDID and UAID to
each other and to other header fields, most of which is not actionable
by implementers of the DKIM base specification and in any case is
covered elsewhere in the specification.

I'm tempted to recommend just removing this section, but perhaps there
is a little bit to say here.  Here is what I would say:

NEW:

The SDID and AUID represent two different identifiers that may be
relevant to assessors.  Unlike the SDID, the AUID, or parts of it,
represents an assertion on the part of the signer whose meaning is not
defined by this specification.  The various constraints specified for
the AUID, principally the requirement that the domain part be a
subdomain of the SDID, are intended to prevent signing domains from
making an assertions about agents or users with which they are
unaffiliated.  The assessor MUST consider AUID values in the context of
being an assertion:  an untrusted signing domain MAY make any assertion
it wishes for the AUID subject to the constraints of Section 3.8.

The AUID local-part and any subdomain of the SDID used in the AUID are,
in general, opaque.  Signing domains MAY make specific practices known
regarding their use of the AUID, such as that it does represent an
actual email address, but in the absence of such assertions MUST NOT be
assumed by the assessor.

=====

15. MUA Considerations

I find both the original and corrected text to be too specific here,
because as it says this is a matter of continuing research.  And there
isn't really any "tendency" at present.  So I would adjust the corrected
text to say:

One option is to have the MUA highlight some identifier associated with
the signature in an attempt to represent the identity that is claiming
responsibility for the message or on whose behalf the message is signed.

=====

Appendix A.

Since the list of names here is likely to be interpreted as an
endorsement of this draft, I request that my name be removed.

=====

-Jim


_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html