I have quite a few comments on the proposed erratum submitted by Dave
Crocker. Detailed comments first, general comments below.
Detailed Comments:
1. Is this a working group draft? The title would seem to imply that it
is but I don't remember that happening.
2. Section 1, paragraph 2: "a consumer of the validated signing domain"
is confusing: "consumer" in particular. DKIM doesn't say anything
about how the results would be used, so all DKIM really has is a signer
and a verifier (which is the term used throughout the spec, not
validator). "...a user of successful verification results" also sounds
too much like it's a human and not some other module that acts on the
result.
3. same paragraph: '"responsible" domain name' implies that the result
is the domain name (which I probably don't agree with, see below) and
the last line talks about "details about the name". Details about the
domain name? I'm not sure what details of a domain name are, unless
you're hinting at the use of a subdomain with a particular name.
4. Section 2: Section 2.7 should come later to avoid forward
references. Identity Assessor is a poor name for this module because
it's not assessing an identity (depending on your definition of
identity, the Verifier might be doing that) but rather something based
on the signing identity. I'm not sure what it means by "optionally
consume the UAID". Does that mean that it can ignore it if it is
provided? I suppose, but DKIM-base specifies a protocol, not the API
that the verifier uses to communicate with something downstream.
5. Section 3: "identity claiming responsibility" -> "domain claiming
responsibility" since that's what the base spec says it does (4871
section 1). I don't see how this is opaque unless you say that domain
names are opaque (which I'm not going to argue) but I find the word
"opaque" in this definition confusing.
6. Section 4: User Agent Identifier is a terrible name for this. The
UAID is the value of the i= tag, it says later. i= is defined as the
"Identity of the user or agent (e.g., a mailing list manager)..." but
nobody said anything about a user agent. We already have the term
"signing identity" used in the specification, and it's quite clear what
it means.
[Aside: Having hung out with some people in the identity community
since the publication of RFC 4871, the one terminology change I would
make is to change "signing identity" to "signing identifier" because the
i= value isn't an identity, it's a pointer to an identity...an identifier.]
7. Section 5 talks a lot about how the sender can put all sorts of
things into the i= value. When we wrote the spec, there was a clear
sense that most signers wouldn't even assert a local-part in the i=
value, and unless they were doing parent domain signing (section 3.8),
probably didn't need to use i= at all. That's simple and elegant.
Instead, this section is emphasizing how signers can put all sorts of
things in the i= value if they want to. What's the motivation for
overloading the i= value with this stuff? If they want to say something
only significant to themselves (perhaps for abuse tracking), it's easy
to define another tag for that value. If they want to give a hint to a
reputation service that might want to do something below the domain
level (this is of dubious benefit; we don't know enough about reputation
yet) they can define a tag for that in an extension to the DKIM spec.
We didn't do that in DKIM-base because we didn't know enough about what
was needed (and I'm not sure we do yet).
8. Section 5: First paragraph seems to read that, even if the i= tag is
in the signature that verifies correctly, it's OK for the verifier not
to communicate that to an assessor. Since some assessors may depend on
this value, for interoperability reasons the value MUST be communicated
if present.
9. Section 6: The old definition of d= seems much clearer.
10. Section 7: The replacement with UAID loses a useful example and
implies it's always a User Agent.
Sections 8-11 just seem to be sprinkling the UAID and SDID acronyms
elsewhere into the text.
Section 13: Good grief, are the authors corporations now? What
happened to IETF being as organization of individuals?
Appendix A: Was the reference to d= intended to be humorous? Perhaps
you should have used SDID rather than d=.
=====
General comments:
Despite its intent to clarify RFC 4871, I find the new terminology at
best adds little (SDID) and sometimes adds new confusion to the document
(UAID). It emphasizes uses of the protocol, particularly "creative"
ways to use the Signing Identity, that if they need to be described at
all, probably belong in the Operations document. It also attempts to
partially specify the API between the Verifier and a downstream
Assessor, which is not the subject of the DKIM specification.
-1.
-Jim
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html