Subject: RE: [ietf-dkim] Attempted text for x=

From: <[email-masked]>
Date: Thu, 20 Apr 2006 02:12:10 -0400

What he said :-)

Bill Oxley 
Messaging Engineer 
Cox Communications, Inc. 
Alpharetta GA 
404-847-6397 
[email-masked] 

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Hector Santos
Sent: Thursday, April 20, 2006 2:07 AM
To: Stephen Farrell
Cc: ietf-dkim
Subject: Re: [ietf-dkim] Attempted text for x=

----- Original Message -----
From: "Stephen Farrell" <[email-masked]>

>>>        Verifiers SHOULD support checking of x= values.
>>
>> I think this must be a MUST.
>
> REQUIRING that the verifer honour the sender's wishes is
> tricky in general and a MUST there is getting close to that,
> as you say.

Agreed.

If we change it to relaxed wording like so:

    Verifiers MAY support checking of x= values. If verifiers
    supports checking the  expiration x= tag, they SHOULD
    honor the signature expiration.

Then basically, this effectively defines for implementations, the x= tag
is
worthless and that if the domains wants to truly expire a signature they
need to either:

     a) revoke the public key by setting p=data to empty, or
     b) purge the publc key DNS record from DNS.

In this case, x=tag becomes an *optional* optimization or non-DNS based
fast
rejection feature or concept.

The wording might be:

    DKIM offers an key expiration optimization option using an
x=expiration
date
    tag in DKIM signatures.  Verifiers MAY use this tag to accelerate
the
    classification of a signature to an invalid state.  Signers MAY set
this
    x= value, however, signers MUST be aware that verifiers may not
support
this
    option and the only effective way to expire a signature or revoke a
public
    key is to clear the public key or remove the selector DNS record.

That is all that basically needs to be said from my point of view as an
implementator.

Signers now will basically view x as the day the key data is cleared or
the
DNS record is removed,  and decide for themselves if they want to assist
the
verifier world with the x=tag optimizer.

Lets keep in mind, tag or not tag, you still have step 2 in section 6.2
and
the 451 recommendation is not something verifiers will just willing
honor
across the board. That is definitely a candidate for local policy
setting to
551.  In short, the coding for the verifier might be:

     NXDOMAIN, no tag, not expired  ---> 451
     NXDOMAIN, signature expired    ---> 551

--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com

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

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

---

From: "Hector Santos" <[email-masked]>
Date: Thu, 20 Apr 2006 07:44:11 -0400

True Bill.

In summary, the straw poll gave us a status quo, but now have a proposal to
water it down.  When you use SHOULD, per RFC 2119, then you must have
"carefully weighted" reason to choose to ignore the domain telling you to
reject or invalid a signature.

The bottom line, for me, it is either supported 100% (MUST Check, MUST
Honor) or you make it 100% policy driven (MAY Check, MAY Honor).  A May
Support, MUST honor is also ok per RFC 2119.

A MAY item is like Candy, Gravy.  You don't have to have it. But if you
choose to support it, then it MUST be supported 100%.

Anyway, that's my opinion. :-)

---
HLS

----- Original Message -----
From: <[email-masked]>
To: <[email-masked]>; <[email-masked]>
Cc: <[email-masked]>
Sent: Thursday, April 20, 2006 2:12 AM
Subject: RE: [ietf-dkim] Attempted text for x=

What he said :-)

Bill Oxley
Messaging Engineer
Cox Communications, Inc.
Alpharetta GA
404-847-6397
[email-masked]

----- Original Message -----

Agreed.

The wording might be:

---

From: Douglas Otis <[email-masked]>
Date: Thu, 20 Apr 2006 07:13:50 -0700

> reject or invalid a signature.

The current draft already offers too many options with respect to
rejection.  If there is a reason to reject the message or the signature,
the desire would be to have all MTAs make the same choice.  Every
difference between MTAs may create a problem down-stream.  My "tongue-
in-cheek" rewording of t= text was to draw attention to that issue.
Choices for the l=, and d= != i= should also be changed to a SHOULD
reject.  Adding x= to this list of do-what-you-want furthers these types
of problems.

Deferred issues within the AU might be a notable exception, but how
secure are these internal MTAs?

-Doug