Assuming this is the accreditation thread:
When I originally introduced the term accreditation the idea was to be a
superset of certification and reputation. There is actually something of
a spectrum, when we authenticate a certificate applicant we may in
certain circumstances rely on certain types of formalized reputation
data.
Accreditation data is usually positive, reputation data can be positive
or negative. Nobody goes out and gets themselves accredited as a
criminal spammer but plenty of people get a reputation for sending spam.
The only effective way to obtain negative reputation data is to go to
the source. A spammer is not going to put out a DKIM record that says 'I
am blacklisted by MAPS'. BUT a reputable sender might well say 'I am NOT
blacklisted by MAPS, I have been accedited as a good sender by Bonded
Sender'.
Although I am promoting consideration of X.509 in this respect I will
answer the question more generally since it is in part forward looking
to the emergence of new publication mechanisms. There is clearly an
attraction to using a DNS based accreditation mechanism as a companion
to DKIM, there are also clear attractions to NOT developing such a
scheme in MASS...
What support for assessment mechanisms is required for the
core DKIM mechanism?
What support for extensible support (and, yes, that's
recursive) of assessments
is needed?
There are a sequence of problems here, where is the data attached to a
domain? What mechanism is used to publish it? How does the recipient
assess the reliability of the assesment data?
Question one: where is the data attached to a domain?
I think that there are two natural places to register assement data, the
policy record and the key record.
Of the two mechanisms the key record allows for much greater
granularity. The signer can in effect choose the assement data that is
advertised for a particular signature. This provides greater flexibility
but also increases management costs.
I would attach the assement data to the key record.
Question Two: What mechanism is used to publish it?
The next issue is the publication mechanism. Here there are a number of
established schemes and some new proposals.
The most widely used and supported publication mechanism is the
venerable X.509/PKIX mechanism. This is widely supported by an
international industry of accreditation providers. X.509 certificates
are signed objects, they are thus self-authenticating (but NOT
self-authorizing).
Another mechanism that has widespread interest and a significant degree
of support is SAML. This was designed to meet the future needs of the CA
industry, in particular the publication of third party accreditation
attribute data. Unfortunately however the rest of the TTP industry has
not shared VeriSign's enthusiasm and this is not likely to change in the
next 12 months.
The other principle assement mechanism that might be relevant to DKIM is
a scheme based on DNS. Many email blacklists already use a DNS based
mechanism. Unfortunately there is no standardization to date. There have
been several proposals to do this, in particular the proposals submitted
by Dave, Doug and others to MARID and the proposal that Meng and I
wrote.
Question Three: How does the recipient assess the reliability of the
assesment data?
Ultimately it is up to the recipient. BUT the choice of mechanism can
greatly assist. One of the big problems with the blacklists was that
they never really accepted accountability themselves.
Any mechanism to assess the reliability of senders is going to require
an authentication component and a reputation component. Fortunately the
reputation component is relatively easy to generate, all you need to do
is to have some form of feedback loop.