Subject: RE: [ietf-dkim] All done on potential SSP requirements?

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Fri, 4 Aug 2006 08:41:26 -0700

> From: Stephen Farrell [mailto:[email-masked]] 

> I could quibble, but I don't think I need to. To be clear, my 
> understanding is that we really, really, strongly want to 
> maintain compatibility with the existing key records (and 
> we've not broken that so far). If some new field were defined 
> s.t. it didn't force, or practically require, changes to 
> existing records, that'd be ok on the face of it (if there's 
> WG consensus etc.) I'm not sure if SSP related stuff would 
> cause a problem there or not.

Adding attributes does not break backwards compatibility.

The point here is that the key record is in effect a policy statement. It describes a possible set of signing options. If a signature verifies against a key record that describes a trusted signature mechanism it is assumed authentic.

So the key records have to contain 90% of the constraints you would want in the policy language. I think that they are all there already and I suspect that should any be missing we woul consider it to be a defect in base.

What I am saying here is that we may be able to dramatically simplify the policy language, effectively reducing it to a series of AND conditions of the form

"I always sign with a key selector of the form X"  AND
"I always sign with a key selector of the form Y"

This has two major advantages over the approach "I always sign with RSA-SHA256 with relaxed C18N....)

1) All the algorithm descriptions are concentrated in the key records, the is no need for the policy language to repeat any of that discussion. Administration is simplified because all the algorithm information is concentrated in one place.

2) The risk of the policy record getting too long and exceeding the 500 byte DNS limit is avoided. The complexity of the policy record is proportional to the number of signatures that you always add to a message. It is independent of the size and complexity of your email configuration. I very much doubt that it would be necessary to ever add more than two signatures and 90% of the time it would be sufficient to add one.

The policy part of the policy record is thus:

POLICY ::=   NEVER-SEND |
             ALWAYS-SIGN |
             ALWAYS-SIGN-WITH (x) [AND ALWAYS-SIGN-WITH (x)]* |
             UNSPECIFIED

Where UNSPECIFIED is the same as not putting a policy record there at all and covers the set of policies it is not useful to differentiate between, i.e. signing some messages but not all of them.

The other half of the policy record is *suggesting* what to do in the case of an error.

EXCEPTION ::=  (SUGGEST-REJECT | SUGGEST-ACCEPT | IGNORE ) EXCEPTION-ENTRY*
EXCEPTION-ENTRY ::=
             REPORT (mechanism) 

> If there's consensus that its worthwhile adding to the key 
> record for SSP-related reasons then I guess we do that. 
> (However, I'd expect there to be some opposition to modifying 
> key records at all unless there's a compelling case. I've no 
> strong opinion myself, but I guess we'll see.)

As I said I don't think it should be necessary at all and if it does turn out to be necessary that is only because we goofed somehow.

The only exception to that is that it may be desirable to allow a 'key' record that has no key value but does have use constraints. This would allow a bulk mailer to send mail that included a DKIM record consisting only of a selector declaration where the selector restricts this use to a single mail address. 

This might help ease the deployment process somewhat as it is much easier to add a static header to a bulk mailer system than add in infrastructure to do signing. It means that policy can be phased in gradually rather than being an all or nothing thing.

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