[ietf-dkim] Itemized Summary of SSP Requirements-00

[Hallam-Baker, Phillip]

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 marketing at example.com but not ceo at example.com.


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: ietf-dkim-bounces at mipassoc.org 
> [mailto:ietf-dkim-bounces at mipassoc.org] 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
> 
>