ietf-mailsig
[Top] [All Lists]

RE: DKIM Verification Algorithm

2005-08-04 08:48:36

Jim,

I am a little confused than of the distinction between testing DKIM and
testing Signing Policy. Can someone have a key record that is not being
tested, but an SSP record that is being tested? Does this make sense,
and what affect will this have on the matrix below?

Graham

-----Original Message-----
From: Jim Fenton [mailto:fenton(_at_)cisco(_dot_)com] 
Sent: Thursday, August 04, 2005 4:20 PM
To: Graham Finlayson
Cc: IETF-MAILSIG
Subject: Re: DKIM Verification Algorithm

Graham,

The key record also has a t= flag.  Will that do?

-Jim

Graham Finlayson wrote: 

      Jim,
      
      I also would like to not have to do this additional SSP 
DNS lookup where
      possible. Unfortunately, I think your optimization will 
not work due to
      the t= flag that can be present in the SSP. 
      
      This could be overcome if the testing information could 
be moved into
      the DKIM-Signature header field.
      
      Graham
      
        

              -----Original Message-----
              From: owner-ietf-mailsig(_at_)mail(_dot_)imc(_dot_)org 
              [mailto:owner-ietf-mailsig(_at_)mail(_dot_)imc(_dot_)org] On 
Behalf Of Jim Fenton
              Sent: Thursday, August 04, 2005 9:06 AM
              To: william(at)elan.net
              Cc: Hector Santos; IETF-MAILSIG
              Subject: Re: DKIM Verification Algorithm
              
              
              I think I missed the beginning of this thread 
somehow.  I 
              think this matrix came from Hector; I rather 
like it because 
              it frames the discussion well:
              
                  

                              I will draw the outcome table 
in text mode. View it in 
                                      

              fixed pitch mode.
                  

                              Table 1.0 - DKIM Verification 
States illustrates all possible
                                         outcomes for 
signature verifcation against SSP.
                              
                                         
+------------------------------------------------------+
                                         |            Sender 
Signing Policy Result              |
                              
                                      

              
+-----------+----------------------------------------------+-------|
                  

                              | result    |  WEAK  | NEUTRAL 
| STRONG  | EXCLU  | NEVER  
                                      

              | NONE  |
                  

                              | verify    |   OPT  | OPT/3PS 
| REQ/3PS |  REQ   |        
                                      

              |       |
                  
              
+-----------+--------+---------+---------+--------+--------+-------|
                  

                              | NONE      | accept | accept  
| reject  | reject | reject 
                                      

              | accept|
                  
              
|-----------+--------+---------+---------+--------+--------+-------|
                  

                              | PASS      | accept | accept  
| accept  | accept | reject 
                                      

              | warn  |
                  
              
|-----------+--------+---------+---------+--------+--------+-------|
                  

                              | PASS 3PS  | reject | warn    
| accept  | reject | reject 
                                      

              | warn  |
                  
              
|-----------+--------+---------+---------+--------+--------+-------|
                  

                              | FAIL      | warn   | warn    
| warn <.-+> warn  | reject 
                                      

              | warn  |
                  
              
|-----------+--------+---------+-------+-+--------+--------+-------|
                  

                              | FAIL 3PS  | reject | warn    
| warn <|-+> reject| reject 
                                      

              | warn  |
                  
              
+--------------------------------------+---------------------------+
                  

                         
                            

              Maybe I'm focusing on an optimization here, but 
I'm still 
              trying to see if we can avoid checking SSP when 
there is a 
              valid originator signature present.  The 
primary case here 
              that requires it is NEVER.  In that case, the 
originating 
              domain must have published some key records, 
but is asserting 
              that it doesn't send any mail.  This seems like 
a conflict, 
              which could be resolved in either direction.  I 
tend to think 
              that having a valid signature is a stronger 
assertion than 
              the SSP, so why not fold NEVER into EXCLUSIVE?
              
              Also, I think that a valid OA signature 
shouldn't result in a 
              warning if there is no SSP published, which 
makes NONE the 
              same as NEUTRAL, again for the reason that the 
signature is a 
              stronger statement than the policy.  It also makes 
              publication of policy optional.
              
              -Jim
              
              
              
                  

      
      "Tumbleweed E-mail Firewall <tumbleweed.com>" made the following
       annotations on 08/04/05 08:17:15
      
--------------------------------------------------------------
----------------
      This e-mail, including attachments, may include 
confidential and/or proprietary information, and may be used 
only by the person or entity to which it is addressed.  If 
the reader of this e-mail is not the intended recipient or 
his or her authorized agent, the reader is hereby notified 
that any dissemination, distribution or copying of this 
e-mail is prohibited. If you have received this e-mail in 
error, please notify the sender by replying to this message 
and delete this e-mail immediately.
      
==============================================================
================
      
        



"Tumbleweed E-mail Firewall <tumbleweed.com>" made the following
 annotations on 08/04/05 08:46:26
------------------------------------------------------------------------------
This e-mail, including attachments, may include confidential and/or proprietary 
information, and may be used only by the person or entity to which it is 
addressed.  If the reader of this e-mail is not the intended recipient or his 
or her authorized agent, the reader is hereby notified that any dissemination, 
distribution or copying of this e-mail is prohibited. If you have received this 
e-mail in error, please notify the sender by replying to this message and 
delete this e-mail immediately.
==============================================================================


<Prev in Thread] Current Thread [Next in Thread>