Subject: RE: [ietf-dkim] Itemized Summary of SSP Requirements-00

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Tue, 29 Aug 2006 11:05:35 -0700

The requirement that I believe that the delegation discussion highlights is the need for controlled delegation.

I.E I delegate to Fred the ability to sign on behalf of [email-masked] but not [email-masked].

The delegation example is relevant because it is only the policy mechanism that creates the need to count a signature by Fred as a domain signature for example.com.

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Hector Santos
> Sent: Tuesday, August 29, 2006 11:40 AM
> To: IETF-DKIM
> Subject: [ietf-dkim] Itemized Summary of SSP Requirements-00
> 
> This might help folks who don't have the time to read the 
> draft details and also serve a quick summary difference when 
> requirements-01 is completed.
> Maybe it can also correct any misunderstanding, including my own.
> 
> 5.1.  Discovery Requirements
> 
> 5.1.1  [_] MUST use DNS RR TXT for Policy record.
> 5.1.2  [_] MUST converge in a deterministic number of exchanges.
> 5.1.3  [_] MUST fit in 512 octets
> 
> 5.2.  Transport requirements
> 
> 5.2.1  [_] Widespread deployment of the transport layer
> 5.2.2  [_] A low-cost query/response
> 5.2.3  [_] Caching and TTL
> 5.2.4  [_] Server Redundancy
> 
> 5.3.  Practice and Expectation Requirements
> 
> 5.3.1  [_] MUST use 2822.From domain only.
> 5.3.2  [_] MUST allow "No Mail Policy"
> 5.3.3  [_] MUST allow "DKIM Signing Complete"
> 5.3.4  [_] MUST allow "1st party signature expected"
> 5.3.5  [_] MUST allow "Known 3rd party signature"
> 5.3.6  [_] MUST NOT mandate receiver handling of mail.
> 5.3.7  [_] MUST allow "Null Practice" ("May Sign Mail?")
> 5.3.8  [_] NOT Required to have a "Blacklist of signing domains"
> 5.3.9  [_] NOT required for valid 1st party signatures 5.3.10 
> [_] MUST allow for list of acceptable hashing methods
> 
> 5.4.  Extensibility and Forward Compatibility Requirements
> 
> 5.4.1 [_] MUST NOT be used for other technology.
> 5.4.2 [_] MUST ALLOW for new policies
> 5.4.3 [_] MUST ALLOW for new protocols signed by DKIM
> 5.4.4 [_] MUST ALLOW for protocols other than DKIM
> 
> 6.  Security Requirements
> 
> 6.1 [_] Minimize DoS potential
> 6.2 [_] Amplification Attacks
> 6.3 [_] Authenticity
> 
> 
> --
> Hector Santos, Santronics Software, Inc.
> http://www.santronics.com
> 
> 
> 
> 
> 
> _______________________________________________
> NOTE WELL: This list operates according to 
> http://mipassoc.org/dkim/ietf-list-rules.html
> 
> 

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

---

From: Damon <[email-masked]>
Date: Tue, 29 Aug 2006 14:28:03 -0400

> I.E I delegate to Fred the ability to sign on behalf of [email-masked] but not [email-masked].

+1

Are we going to specifically disallow fred the ability to sign for
[email-masked] by policy or say that fred can only sign for
[email-masked]?

Regards,
Damon Sauer

---

From: Douglas Otis <[email-masked]>
Date: Tue, 29 Aug 2006 12:06:37 -0700

On Aug 29, 2006, at 11:28 AM, Damon wrote:

>> The requirement that I believe that the delegation discussion  
>> highlights is the need for controlled delegation.
>>
>> I.E I delegate to Fred the ability to sign on behalf of  
>> [email-masked] but not [email-masked].
>
> +1
>

Such granularity will be difficult to administer and resolve.   
Message annotation can help resolve this issue by allowing for a  
"direct" affirmation versus "indirect".

When the "indirect" annotation is used, the identity of the signing  
party should become visible in some manner to be part of the trust  
relationship.

It is even possible there is greater trust in the signing party than  
there is in the email-address. : )

-Doug

---

From: "Hector Santos" <[email-masked]>
Date: Tue, 29 Aug 2006 16:29:00 -0400

----- Original Message -----
From: "Hallam-Baker, Phillip" <[email-masked]>

> The delegation example is relevant because it is only the
> policy mechanism that creates the need to count a signature by
> Fred as a domain signature for example.com.

Ok, but you think it will still work or its consistent with the discovery
requirement #1 discussed in section 5.1.1?  Or is this a DNS record
preparation issue?

| 5.1.  Discovery Requirements
|
| 5.1.1  [_] MUST use DNS RR TXT for Policy record.