Subject: [ietf-dkim] DKIM errata 1532 (v= and DomainKeys)

From: <[email-masked]>
Date: Thu, 11 Mar 2010 11:50:14 +0100

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)?

Best regards,
Pasi

_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 11 Mar 2010 13:47:50 +0000

> of draft-ietf-dkim-deployment in the Notes field)?

Works for me. Absent objections in the next week, let's
go for that.

Stephen.

---

From: Mark Martinec <[email-masked]>
Date: Thu, 11 Mar 2010 18:29:50 +0100

> Works for me. Absent objections in the next week, let's

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

---

From: "[email-masked]" <[email-masked]>
Date: Wed, 17 Mar 2010 12:42:21 +0100

Mark Martinec wrote:

> 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.
> 

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

---

From: Jim Fenton <[email-masked]>
Date: Thu, 18 Mar 2010 11:14:28 -0700

> a 'v' is mandated if an empty granularity 'g=' is (intentionally) used.

I guess I should be paying more attention to the dkim-deployment drafts.

RFC 4871 is very explicit about the meaning of the g= value.  Last 
paragraph of section 3.2:

   Tags that have an empty value are not the same as omitted tags.  An
   omitted tag is treated as having the default value; a tag with an
   empty value explicitly designates the empty string as the value.  For
   example, "g=" does not mean "g=*", even though "g=*" is the default
   for that tag.

The semantics of g= has no dependency on the presence or absence of the 
v= tag/value.  One of the ways of revoking a DKIM key is to apply a null 
g= tag (g=;) which makes it unusable.  Coming up with a way of guessing 
whether the signing domain really meant "g=;" is not a good idea and 
contradicts the specification.

-Jim

---

From: "[email-masked]" <[email-masked]>
Date: Thu, 18 Mar 2010 20:32:10 +0100

Jim Fenton wrote:

> The semantics of g= has no dependency on the presence or absence of
> the v= tag/value.  One of the ways of revoking a DKIM key is to
> apply a null g= tag (g=;) which makes it unusable.  Coming up with a
> way of guessing whether the signing domain really meant "g=;" is not
> a good idea and contradicts the specification.

Hmm -- back in IETF73 we seemed to agree (at least according to the
email below) that guessing is, while probably not a good idea,
possibly less bad than the alternative:

http://mipassoc.org/pipermail/ietf-dkim/2008q4/010820.html

Best regards,
Pasi

---

From: "[email-masked]" <[email-masked]>
Date: Thu, 18 Mar 2010 21:00:38 +0100

Jim Fenton wrote:
> Hmm, that's right; I had forgotten completely about that.  However,
> errata 1532 still shows up as "reported"; that means it still needs to
> be acted on, right?  I'm still not entirely clear on the process for
> errata.

I had also completely forgotten that email, and found it only 
earlier today! (so my email last week wasn't quite right).

The ball got dropped back in 2008, so yes, errata 1532 still
needs to be acted on. Given that we now have the dkim-deployment 
document ready (which has the recommendations for e.g. DomainKeys
deployers), we probably want to edit the errata text slightly 
(at the very least, add a pointer to dkim-deployment) before
marking it as "verified". 

Best regards,
Pasi

---

From: Jim Fenton <[email-masked]>
Date: Thu, 18 Mar 2010 12:43:44 -0700

Hmm, that's right; I had forgotten completely about that.  However, 
errata 1532 still shows up as "reported"; that means it still needs to 
be acted on, right?  I'm still not entirely clear on the process for errata.

-Jim