ietf-dkim
[Top] [All Lists]

Re: [ietf-dkim] A few SSP axioms

2006-07-31 20:38:50
On Monday 31 July 2006 21:22, John Levine wrote:
I think this is the key issue then and we ought to focus on it.  In
my view almost the entire point of a signing policy is constraining
whose signatures are considere authorized by the domain owner.

I'm assuming that when you say authorized, you mean authoritative.
(English definitely has its shortcomings.)

I meant authorized, as I think the SSP concept is about authorization.  I can 
see where authoritative fits better as I wrote it.  I'm not sure there is a 
distinction between the two worth arguing about.

A few scenarios:

Message from domain A, signed by A; does SSP matter at all?

There needs to be a design decision made.  Is it better to have a default 
policy where this case is authorized and no SSP lookup is required or is it 
better to have no assumptions made and lookup SSP in all cases.  I think this 
decision is an optimization decision that can be made late in the game.

Off the top of my head, I can't see why we would need an explicit SSP for this 
unless it is for completeness sake.  Completeness is not such a bad thing.

Message from A, signed by B; A's SSP says B signs all its mail

I would say that A's SSP says B is an authorized signer for all its mail.  It 
may or may not be the only signer.

Message from A, signed by A and B; does SSP matter? (I hope not.)

In my book it's the same as A signed by A.  The only concern I would have is 
if B added content, what to do about that, I'm not sure.  I expect that's 
probably a question for receiver policy and unlikely to be standardized.

Message from A, signed by C; SSP says nothing about C.

Yes.  Then how to treat this would be a question of what A's SSP says (is the 
list exclusive or not) and the receiver policy.  

I think that the matrix that Hector did back at (or possibly just before) the 
working group started was a good one.

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