Subject: [ietf-dkim] FW: New Version Notification for draft-kucherawy-authres-vbr-00

From: "Murray S. Kucherawy" <[email-masked]>
Date: Sun, 7 Nov 2010 21:25:40 -0800

I've introduced a draft to register the relaying of VBR results via Authentication-Results header fields.  I imagine this will be something the new APPS area working group can pick up, but it also seems appropriate to let the DKIM WG know about it.

Comments welcome, even if it's just "I read this, looks good to me" so that some support or consensus can be recorded.

-MSK

Subject: New Version Notification for draft-kucherawy-authres-vbr-00
From: IETF I-D Submission Tool <[email-masked]>
To: "Murray S. Kucherawy" <[email-masked]>
Date: Sun, 7 Nov 2010 21:20:11 -0800

A new version of I-D, draft-kucherawy-authres-vbr-00.txt has been successfully submitted by Murray Kucherawy and posted to the IETF repository.

Filename:	 draft-kucherawy-authres-vbr
Revision:	 00
Title:		 Authentication-Results Registration For Vouch By Reference Results
Creation_date:	 2010-11-07
WG ID:		 Independent Submission
Number_of_pages: 7

Abstract:
This memo updates the registry of properties in Authentication-
Results: message header fields to allow relaying of the results of a
Vouch By Reference query.

The IETF Secretariat.

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

---

From: Alessandro Vesely <[email-masked]>
Date: Mon, 08 Nov 2010 13:03:50 +0100

> Vouch By Reference query.

Nice one, Murray!

Section 4 (Definition) is ambiguous, though.  It says "the DNS domain 
name used to perform the VBR query", but a VBR query takes two domain 
names.  I think mentioning the tag (md, according to the example) 
would make it clearer.

However, why not structure all the available domains?  E.g. delivering 
something like (modified from section A.1)

  Authentication-Results: mail-router.example.net;
        dkim=pass (good signature) header.d=newyork.example.com
              header.b=oINEO8hg;
        vbr=pass (all) header.mv=voucher.example.net
              header.md=newyork.example.com

where the comment contains the actual content of the TXT record.  A 
machine readable voucher name could be used by clients to learn what 
vouchers a server trusts.

Another item that may need clarification is the "positive response" 
given in the definitions of "pass" and "fail".  It could be expanded 
as, say,

  pass:  A VBR query was completed and the vouching service queried
     gave a positive response.  That is to say, it returned a record
     consisting of strings of lowercase letters separated by spaces,
     as per section 5 of [VBR].

The added sentence is meant to dispel any question on whether the 
verifier should attempt to match the text in the RR with the content 
of the mc= tag in the VBR-Info header field, if any.
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 8 Nov 2010 10:28:32 -0800

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Alessandro Vesely
> Sent: Monday, November 08, 2010 4:04 AM
> To: [email-masked]
> Subject: Re: [ietf-dkim] FW: New Version Notification for draft-kucherawy-authres-vbr-00
> 
> [...]

This is actually off-topic for DKIM.  I just wanted to announce the work here.

Discussion would be better held on [email-masked], [email-masked], or off-list.  I'll reply to your points on the former for starters.

Thanks!
-MSK

---

From: John Levine <[email-masked]>
Date: 12 Nov 2010 23:12:07 -0000

>Comments welcome, even if it's just "I read this, looks good to me"
>so that some support or consensus can be recorded.

I read it, it almost looks good to me.  A VBR-Info header can list
multiple certifiers, so unless there's something I missed, the vbr
clause in the A-R header should include the name of the certifier.
I imagine that in a scoring system different certifiers would be
weighted differently, e.g., a list of spamless signers vs. a list
of signers that send a mix but it's not all spam.

The domain name being verified seems redundant since it should appear
in a previous DKIM, DK, SPF, or S-ID clause, but it doesn't hurt
anything and I suppose makes parsing easier.  I'd suggest calling the
fields vbr-certifier and vbr-domain, So your example would be:

Authentication-Results: mail-router.example.net;
    dkim=pass (good signature) header.d=newyork.example.com 
               header.b=oINEO8hg;
    vbr=pass header.vbr-certifier=voucher.example.net
               header.vbr-domain=newyork.example.com

R's,
John