From: Stephen Farrell
[mailto:stephen(_dot_)farrell(_at_)cs(_dot_)tcd(_dot_)ie]
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