Hallam-Baker, Phillip wrote:
Phill, can you clarify: are you advocating the addition of
interfaces
to accreditation mechanisms, reputation systems, or both?
I am proposing merely to add an interface to allow a key record to
contain a statement that there is an X.509 certificate associated with
the key.
That is an entirely constrained and straightforward work item
If you can be a bit more specific about the type of interface you have
in mind (signature tag/value? key record tag/value? something else?) it
might be simple and straightforward enough to be a non-issue for the
charter.
If we need focus why on earth are we considering the idea of
communicating authentication results to downstream? That is an entirely
new design problem and a very complex one that has significant trust
implications.
Excellent point. The intent there was not to obligate the working group
to work on Authentication Results, but to support the ability to do so
without a charter revision. A related issue is that many DKIM
deployments will need some way of communicating results downstream, and
draft-kucherawy-sender-auth-header doesn't have another WG home. But
perhaps that's not such a good idea. How do others feel about this
paragraph of the charter?
1. Continue with the charter as currently written, and amend it at a
later time to bring in additonal scope.
2. Amend the charter to add additional scope.
3. Create a separate group to address the
accreditation/reputation problem.
I do not want to work on the accreditation/reputation problem. All I
want to do here is to allow someone who has a key to advertise the
existence of additional information defined using the existing
accreditation mechanism.
Again, please suggest some specifics.
-Jim