Mark Martinec wrote:
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.
I see your point... however, the current errata text does *not*
mandate (or recommend) including 'v=' with an empty 'g='.
Perhaps something like this?
The format of the DNS key record was intentionally meant to be
backward compatible between DKIM and DomainKeys. However, DKIM and
DomainKeys treat an empty "g=" tag ("g=;") differently. To ease
transition from DomainKeys to DKIM, some DKIM verifiers may attempt
to use the DomainKeys interpretation if the "v=" tag is not present.
To ensure correct processing by the verifier, it is strongly
RECOMMENDED to include the "v=" tag when using an empty "g=" tag.
See draft-ietf-dkim-deployment, Appendix A.1 for more information.
Best regards,
Pasi
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html