dkim-dev
[Top] [All Lists]

[dkim-dev] ATPS v01 comments

2010-09-30 12:47:38
Murray,

Comments regarding recently published draft-kucherawy-dkim-atps-01.txt [1]

Suggestions:

1) Optional v=atpsXX tag;

I suggest adding a tag to the value like:

     v=atps01

where 01 represents the current specification revision and hashing 
algorithm.  If the method changes in the future, then v=atpsXX would 
tell the verifier what method to use.

We already have implementations our our verifier with the old MD5 
method so I will need to use this to determine if the old MD5 or 
BASE32(SHA1) method is used.

If text is added, it might be written as optional and default to v=atps01

2) Optional d=signer-domain tag

I would also add text to make it optional to add a tag

    d=signer-domain;

IMV, there is no security here of hiding what is hashed and I believe 
most admins will want to make it easier to maintain a zone folder 
MANUALLY (with some text editor).

My MAKEATPS01.EXE tool for example will produce this:

  c:\src\wcdkim> MakeATPS01 santronics.com one.example.net mipassoc.org

  ;
  ; ATPS (v01) Zone Records for author-domain: santronics.com
  ;

  QSP4I4D24CRHOPDZ3O3ZIU2KSGS3X6Z6._atps  TXT ("v=atps01; 
d=one.example.net;")
  N3LSEHML2WGBFXOV7HSAK2QZSUBSEFHB._atps  TXT ("v=atps01; 
d=mipassoc.org;")

3) Short Circuit Multiple Proposal issue.

Murray, there is no doubt my mind that if we have multiple similar 
I-Ds, we will be asked to MERGE them.

I am still working out the details and drafting my ASL (Allowed Signer 
List) and it includes support for ATPS as a fallback lookup rule.

In other words, the asl= tag is designed to be light weight 
optimization where no additional DNS lookups as required with ATPS.

The example verifier procedure as currently outlined:

   1) Obtain the AUTHOR-DOMAIN and perform TXT query the ADSP
      record to obtain the value.:

       _adsp._domainkey.AUTHOR-DOMAIN

   2) If no ADSP record is found (NXDOMAIN), return ADSP=NONE

   3) Obtain the SIGNER-DOMAIN and compare with the AUTHOR-DOMAIN

      If the two domains are the same, return ADSP=PASS, otherwise
      continue with third party authorization checking.

   4) If an asl= tag is present, check the SIGNER-DOMAIN within
      the asl= list of domains. See section X.XX for asl= parsing rule.

      If SIGNER-DOMAIN is found in the asl= list, return ADSP=PASS

   5) If an atps=y tag is present, perform the steps as outlined in
      [ATPS]

   6) return ADSP=FAIL

What I suggest is to  add ASL= tag support to the ATPS I-D that way 
the community will be better served.  I rather have you be the main 
editor here because of your strong IETF ties to push this through.

ASL= should be considered as an optimizer for domains that can fit 
their policy requirements in one record and don't want to adding ATPS 
records thus avoiding additional DNS lookups.

Please think about this first before issuing a quick reply - talk to 
barry.  If not merged, there will be definitely be an ASL draft I-D 
proposal, open source code provided, working with ALT-N to add to the 
their API library and implementations will (and currently) support it.

-- 
Sincerely

Hector Santos
http://www.santronics.com

[1] http://tools.ietf.org/id/draft-kucherawy-dkim-atps-01.txt

_______________________________________________
dkim-dev mailing list
dkim-dev(_at_)mipassoc(_dot_)org
http://mipassoc.org/mailman/listinfo/dkim-dev