-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
In message <[email protected]>, Hannah Stern
<[email protected]> writes
thank you for the detailed proof-reading, I have snipped the items where
I have corrected the errors you found and all I would say is "yes, done"
>For Message-Instance, v= is limited to 2 digits. Perhaps for
>consistency the EBNF for v= for the DKIM2-Signature (section 6) could
>also changed to allow only 1*2DIGIT for consistency.
I've made it consistent, but 1*DIGIT rather than 2DIGIT (the latter
would mean you had to write v=01)
>There is talk about feedback requests elsewhere in the draft (e.g. 10.2)
>but they are not specified for the DKIM2-Signature header.
For the moment we have punted on what feedback might be or where it
might be sent... there are existing schemes which provide feedback to
entities whose DKIM1 signatures are present in messages and where a
request has been made out-of-band.
It may be that the best thing to do here in DKIM2 is to provide a
destination email address, rather than a mere flag. Senders of feedback
would need to check for appropriate authorisation in the DNS -- as is
the practice for DMARC reports.
>In section 8: 'and any header fields whose name starts with "ARC" MUST
>be ignored': Is this really "ARC*" or "ARC-*" or "ARC" *1("-" 1*ftext)?
>(That is, would something like "Archived-At: <uri>" as per RFC5064 be
>ignored?)
It should be "ARC-*" ... or we could list the headers from RFC8617 by
name (I think implementing ARC-* is easier, and I doubt people would
invent new ARC-headerfields any time soon).
>9.2: 'one by one from the left hand side of the mf= domain and compared
>with the rt= domain until there is an exact match or no labels remain'
>Perhaps say explicitly "rt= domain of the previous signature"?
I've done a major rewrite of this to provide more clarity. In particular
there was confusion between the check that a Verifier must do when
receiving an email (check for an exact match of mf= rt= with the RFC5321
values) and the "chain of custody" scheme which ignores the local part
and strips off labels to try and get a match.
>10.2.2 step 4: This may lead to ambiguity. If a verifier choses to
>iterate all keys, fine, if any fits, the signature validates (possible
>partial DoS potential), but if the verifier doesn't, they can't know if
>another key would actually work or if the signature is just invalid -
>i.e. if "permfail" is the actually correct result. The associated draft
>for DKIM2 DNS actually says the RRs MUST be unique. Perhaps make 10.2.2
>step 4 consistent with that MUST (as suggested in step 5 in connection
>with the DKIM2 DNS draft).
this step is copied verbatim from DKIM1, and the uniqueness requirement
is in RFC6376 as well (ie this is essentially an Errata against that
document). I will fix this to say that multiple keys should cause a
PERMFAIL.
I am working through further emails ... once I finish them I will issue
a new version of my document (hopefully today!)
- --
richard @ highwayman . com "Nothing seems the same
Still you never see the change from day to day
And no-one notices the customs slip away"
-----BEGIN PGP SIGNATURE-----
Version: PGPsdk version 1.7.1
iQA/AwUBaUxFGmHfC/FfW545EQKw0QCfZRCc2fGmkEHwNmCT+QsJnMk1UrQAoMo3
gOip4T4+MkvPsZbbilLFoytt
=VaBg
-----END PGP SIGNATURE-----
_______________________________________________
Ietf-dkim mailing list -- [email protected]
To unsubscribe send an email to [email protected]
