[ietf-dkim] semantics of message signing

[Jim Fenton]

Keith Moore wrote, responding to James Scott:

>>My understanding is that a signing party is vouching for the message.  This
>>means that it is providing an assurance that the message contents, including
>>originating address fields, are authorised.  If the signing party is
>>unwilling or unable to provide this assurance, then they should not apply a
>>signature.  The receiving party can place a value on this assurance
>>depending on a variety of factors (relationship to originating address,
>>reputation, etc).
>>    
>>
>
>I doubt that it's a good idea to insist that those semantics be
>associated with every signature, as it would drastically impede the
>ability of intermediaries to sign messages.  For instance, a list
>should be able to sign a message in such a way as to mean "this
>message was sent to you from this list" but not to make any assurances
>about the content of the message.
>  
>
Another example where this would be a problem is the "news article 
case":  recipients might be interested in receiving news articles that 
friends send them from various news sites.  The news site, though, may 
have no way of verifying the originating address field is authorized.  
Should they be able to ever sign a message, then?  The signature adds 
value to the recipient; it confirms that the message was really sent by 
nytimes.com [for example] and might be locally whitelisted by the recipient.

>Basically all that signing a message inherently means is "I saw the
>message when it looked like this".  This is a useful service by itself,
>but there are situations when we'd like a signature to say more than
>that.  If we want to add additional semantics to a particular signature
>they should be (a) explicit, and (b) decoupled from the message itself.
>
>What (b) probably implies is that any explicit semantics associated
>with a signature need to be contained in the message header(s) that
>represent the signature, rather than in any of the headers that are
>signed by the signature.
>  
>
We had a semantics indicator in IIM that indicated whether the signature 
was "live" or simply was a kind of signed Received header indicating 
that the message passed through.  I honestly didn't see much value in 
this; the passthrough signature seemed like a nice-to-have, but it 
confused manual examination and it wasn't clear to me that the problem 
it was solving was one that we really care about.

I'd be interested in what sort of semantics choices you have in mind.

-Jim