Some comments on the new rfc4871bis draft. Some of these comments are
continued from the discussion on -03, where in many cases I dropped the
ball on a previous thread.
A previous comment of mine, and Dave Crocker's response to which I will
finally reply:
Section 2.3, Identity: I realize this is taken from RFC 5672, but the
definition is not clear to me. Suggest that the second sentence read,
"Identities that may be associated with DKIM signatures include
authors and
their organizations, ISPs along the message handling path, and
mailing list
operators." (I'm not sure how the independent trust assessment
services apply
here, since their assessment happens AFTER signature verification).
[same as
last call comment on -02]
0. Can you clarify what it is about the definition that is not clear?
(Any guidance at all will help for understanding the nature of what
needs fixing.) The initial text is the definition and it's simplicity
makes it difficult to guess what the problem is.
1. "authors and their organizations" could be misinterpreted to mean
that the conjunction defines a single identity.
But the current text says "...examples include the author, ..." so that
misinterpretation exists there as well. I'd be fine with just "authors'
organizations".
2. It turns out that this sort of text is much clearer when it makes a
singular rather than plural reference, especially given that the term
being defined is singular.
I'm fine with singular.
3. One form of assessment service -- of which the late Goodmail was an
example
-- can give a priori assessment and then indicate tghe assessment by
providing the signature to the message before it is sent. That is,
the authoring organization passes the message to the assessment
service and the assessment service hands back the signature to be
included in the message. (The details can vary, of course, but this
describes the basic model.) Hence the signature is somewhat akin to a
capability token. [I thought I had explained this processing option a
number of times over the years, specifically citing the Goodmail
example.]
That's a specific example of an ISP along the handling path. The
potential for misinterpretation of this is greater than the benefit of
explaining this potential usage scenario, especially since "assessment"
has a very specific definition in the DKIM context.
Section 2.9, Common ABNF tokens: Two new tokens are defined based on
field-name and dkim-quoted-printable. But where are field-name and
dkim-quoted-printable defined?
field-name is defined in Section 2.10
DKIM-Quoted-Printable is defined in Section 2.11
Would it be beneficial to rearrange the sections to avoid the forward
reference?
Section 3.2, paragraph 2: dkim-quoted-printable is now defined in
section 2.11, not 2.6.
6.3 paragraph 5 has changed "signing identity" to SDID. The signing
identity
really corresponds to the AUID.
That has not been correct for any version of rfc4871bis. The term
Signing Identity has no normative value and is now only used in the
introductory text.
Also note that the Update removed any meaningful semantics for AUID:
The AUID comprises a domain name and an optional
<Local-part>. The domain name is the same as that used for the
SDID or is a sub-domain of it. For DKIM processing, the domain
name portion of the AUID has only basic domain name semantics; any
possible owner-specific semantics are outside the scope of DKIM.
In fact, the AUID is not part of DKIM's formal output. So the formal
specification cannot then direct it be supplied to the assessment engine.
Nevertheless, suppose a message with From address
<joe(_at_)marketing(_dot_)example(_dot_)com> was properly signed with
i=marketing.example.com and d=example.com. What the text is telling us
is that the mail system SHOULD take pains to ensure that example.com is
visible to the user. This is counter to all of the text in the DKIM
specification that permits keys for a subdomain to be managed in a
parent domain. If these is consensus to eliminate signing for
subdomains, there is a lot of other stuff that needs to be removed from
the spec, including the i= tag itself, the "s" flag in the key record,
the text in section 3.9, and the security consideration in section 8.13.
The Update removed semantics associated with the local part of the AUID,
and not the domain-part.
If there is not consensus to remove subdomain signing, the wording
described here makes it meaningless. This goes to the heart of why I
have been arguing that the output of DKIM should be the AUID (or its
default value, which is the SDID), and not the SDID itself.
=====
In today's meeting, I took an action on the Jabber chat to write some
informative text cautioning signers not to put empty g= values in their
key records. Here is an attempt:
Appendix C. Key Record Considerations (INFORMATIVE)
C.1. Creating a Public Key
[current Appendix C text goes here]
C.2. Compatibility with DomainKeys Key Records
DKIM key records were designed to be backwards-compatible in many cases
with key records used by DomainKeys [RFC 4870] (sometimes referred to as
selector records in the DomainKeys context). One area of
incompatibility warrants particular attention. The "g" tag/value may be
used in DomainKeys key records to provide finer granularity of the
validity of the key record to a specific local-part; a null "g" value is
valid for all addresses in the domain. This differs from the usage in
the original DKIM specification [RFC 4871], where a null "g" value is
not valid for any address. In particular, the example public key record
in [RFC 4870] section 3.2.3 is not compatible with [RFC 4871].
Although the "g" tag has been deprecated in this version of the DKIM
specification, signers are advised not to include the "g" tag in key
records because some [RFC 4871]-compliant verifiers will be in use for a
considerable period to come.
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html