ietf-dkim
[Top] [All Lists]

Re: [ietf-dkim] Attempted text for x=

2006-04-19 11:27:18
Proposed change:

3.5  The DKIM-Signature header field
   
      ...


 x=  Signature Expiration (plain-text; RECOMMENDED, default is no
     expiration).  Signature expiration in seconds-since-1970 format
     as an absolute date, not as a time delta from the signing
     timestamp.  The value is expressed as an unsigned integer
     in decimal ASCII, with the same constraints on the value in
     the "t=" tag.

     The expiration is a DKIM signature descriptor exposing the
     responsible domain intent to expire or revoke a DKIM 
     signature validity. Although, in practice, this control might 
     be viewed as a domain key management and security concept, 
     the domain's true intent and purpose is out of the scope.

     If present, the expiration time MUST be compared against
     the Transaction Reception Time (TRT).  

     Extracting the TRT depends on where the DKIM verifier 
     is implemented. For transport (SMTP) level verifier
     operations, the TRT is the current system time.  For non-SMTP
     verifier operations, the TRT is the time extracted from 
     the 2822.Received: header as  required to be added by the 
     transport SMTP receiver.  

     To satisfy step 2 in section 6.2, verifiers MAY choose to 
     perform a DKIM verification before the expiration 
     time is checked.  This will help on deciding between
     a permanent or temporary response code.

     ABNF:

        sig-x-tag    = %x78 [FWS] "=" [FWS] 1*12DIGIT


6.2  Get the Public Key

  ...
  [Editor note: Renumbered the list]

  1.  If signature has an expiration (x=) tag, check if the signature
      has expired. Signatures MUST NOT be considered valid if the
      current time at the verifier is past the expiration date.
      Verifiers MAY choose to check key selector for revocation or
      DNS removal. See Step 3.

  2.  Retrieve the public key as described in (Section 3.6) using the
      domain from the "d=" tag and the selector from the "s=" tag.

  3.  If the query for the public key fails to respond and the
      signature has not expired (in step 1),  the verifier  SHOULD 
      defer acceptance of this email (normally this will be
      achieved with a 451/4.7.5 SMTP reply code).

      If the query for the public key fails to respond and the 
      signature has expired (in step 1) the verifier SHOULD
      reject the transaction of this email (normally this will be
      achieved with a 551/5.7.5 SMTP reply code).


Editor Change Checklist:

[X] Consolidate Formatting/Type text

[X] Domain signer's reasons for expiration tag is out of scope.

[X] Change Current Time to "Transaction Reception Time" to satisfy
    the two types of SMTP operations - SMTP plug-ins verifiers 
    versus post SMTP acceptance Verifiers.  To use the "Current
    Time" for post verifiers would be technically incorrect which
    could promote premature expirations.

[X] Satisfy Step 2 in Section 6.2 (now step 3).

[X] Allow for optimization consideration (No Verification Required).

[X] Remove Information Note about replay attacks.  Considered or not, 
    DKIM can't control what the VERIFIER will experience and the
    knowledge gain to address such issues.


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





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