Subject: [ietf-dkim] Corrected copy - Requirements addition: Policy/Practice record for first party signatures

From: Scott Kitterman <[email-masked]>
Date: Wed, 9 Aug 2006 13:15:39 -0400

*** 574,580 ****
             blacklist repository.]

     9.   The Protocol MUST NOT be required to be invoked if a valid first
!         party signatures is found.

     10.  [PROVISIONAL] A domain holder MUST be able to publish a Practice
          which enumerates the acceptable cryptographic algorithms for
--- 581,594 ----
             blacklist repository.]

     9.   The Protocol MUST NOT be required to be invoked if a valid first
!         party signatures is found, [PROVISIIONAL] but the Protocol SHOULD
!         support publishing Practices for First Party DKIM signatures.
!
!            [INFORMATIVE NOTE: the provisional requirement to support First
!            Party Practices is intended as an aid to the receiver.  While
!            SSP lookups aren't required for First Party DKIM signatures,
!            there may be utility to receivers to determine Practices
!            associated with First Party DKIM signatures.]

     10.  [PROVISIONAL] A domain holder MUST be able to publish a Practice
          which enumerates the acceptable cryptographic algorithms for
***************

This addition is suggested for a couple of reasons...

1.  Completeness.  I think there is some value in providing a reasonably 
complete list of Practices.  There will likely be effective uses for policy 
information by receivers that we haven't thought of yet.  An incomplete set 
of practices may hamstring this kind of innovation.

2.  RFC 2821 discovery - This is the requirement change a alluded to yesterday 
in the signalling DKIM support before DATA thread.  I won't rehash that here.

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

---

From: Michael Thomas <[email-masked]>
Date: Wed, 09 Aug 2006 13:53:31 -0700

Scott ---

Scott -- I think it's both explicit and specific in other requirements 
that the protocol
must publish that data, and some of those are MUST strength. I really 
don't see why
we need to restate that here.

That and I don't think there is any explicit or implicit proscription 
here on when the
protocol ought not be invoked. The restriction on was forcing new 
behavior for a
DKIM verifier, not on how the protocol could be used.

       Mike

---

From: Scott Kitterman <[email-masked]>
Date: Wed, 9 Aug 2006 17:22:01 -0400

> DKIM verifier, not on how the protocol could be used.
OK.  You've spent a lot more time with the document than I have.  I'll accept 
that.

I'll keep an eye on it when we get to design.

Scott K

---

From: Douglas Otis <[email-masked]>
Date: Thu, 10 Aug 2006 07:30:03 -0700

On Wed, 2006-08-09 at 13:53 -0700, Michael Thomas wrote:
> that the protocol must publish that data, and some of those are MUST
> strength. I really don't see why we need to restate that here.
> 
> here on when the protocol ought not be invoked. The restriction on was
> forcing new behavior for a DKIM verifier, not on how the protocol
> could be used.
> 
>        Mike
> 
> Scott Kitterman wrote:
> 
> >*** 574,580 ****
> >             blacklist repository.]
> >

It is not clear from the definition for first party signature whether
this includes a match where the d= parameter represents a parent of the
first party address.  There might be value in checking policy for
whether the parent has been excluded as being authoritative for the
first party address.

-Doug