On Thursday 11 March 2010 14:47:50 Stephen Farrell wrote:
On 03/11/2010 10:50 AM, Pasi(_dot_)Eronen(_at_)nokia(_dot_)com wrote:
Just two unprocessed errata left! Tackling the easier one first:
http://www.rfc-editor.org/errata_search.php?eid=1532
Appendix A of draft-ietf-dkim-deployment has detailed text about
this topic (differences in DNS key records between DomainKeys and DKIM),
so I'm not sure if RFC 4871 really needs this information.
How about rejecting this errata (with a pointer to Appendix A
of draft-ietf-dkim-deployment in the Notes field)?
Works for me. Absent objections in the next week, let's
go for that.
I don't think just dropping the errata works for me.
The draft-ietf-dkim-deployment-11 says:
If a DKIM verifier finds a selector record that has an empty "g"
field ("g=;") and it does not have a "v" field ("v=DKIM1;") at its
beginning, it is faced with deciding if this record was
1. from a DK signer that transitioned to supporting DKIM but forgot
to remove the "g" field (so that it could be used by both DK and
DKIM verifiers), or
2. from a DKIM signer that truly meant to use the empty "g" field
but forgot to put in the "v" field. It is advised that you treat
such records using the first interpretation, and treat such
records as if the signer did not have a "g" field in the record.
For this to work, it requires one to provide an explicit "v=DKIM1"
when a empty "g=" is intentional. On the other hand, the RFC 4871
clearly marks the v tag as entirely optional (yet recommended).
While I agree that a recommendation on how a verifier should handle
empty g tag does not belong into RFC 4871 (but only in dkim-deployment),
I think that a 4871 section 3.6.1 on tag g (or v) should require that
a 'v' is mandated if an empty granularity 'g=' is (intentionally) used.
Without this requirement, the dkim-deployment guesswork has no firm
grounds to work on.
Mark
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html