Dave CROCKER wrote:
On 8/1/2011 8:41 AM, Scott Kitterman wrote:
In fairness to Hector, the functionality that he is complaining is
missing was
part of the original working group charter.
please cite the text from the original charter that promises such work
and, just to be safe, please cite the current text that claims it should
be there.
In other words, the current complaint is about something missing.
Please quote the specification of that and then the part of the original
charter that said we would do it.
We are perfectly aware you never believed in policy, never really
acknowledge it, fought hard against its progress. I can respect that
position. But I am bit vex as to why you are questioning its existence
as an original and still current WG work item.
The DKIM WG always had among its charter work items to produce a
Domain Policy standard and even thought the charter was revised over
the years, Policy is still today among the WG chartered item today. I
personally have not seen or read of any official statement to conclude
the WG and stop all remaining work, nor a change in the charter to
official remain policy as a work item.
Attached is 2005 copy of the charter I have on disk. Please note how
reputation was declared of out of scope, yet it continued to disrupt
the WG and revamped DKIM to its present condition.
Two other WG RFC work items were completed; one directly related to
producing the "Requirements for a DKIM Signing Practices Protocol"
RFC5016, and a Threat Analysis RFC4686 which includes among its
analysis how policy can mitigate certain security threats using Policy.
You, yourself, wrote a RFC5585 called
"DomainKeys Identified Mail (DKIM) Service Overview"
with signing practices peppered over all the document as a major piece
of the system. This sentence is found in the abstract:
DKIM also enables a mechanism that permits potential email signers to
publish information about their email signing practices; this will
permit email receivers to make additional assessments about messages.
And the RFC includes a spiffy process flow illustration titled
"DKIM Service Architecture"
with a Checking Signing Practice component as a major piece of this
design.
So I am "scratching my head" here wondering why you are now
questioning how a framework designed over 5 years had major work
productions dismissed, especially those related to security, in the
pursuit of the unrestricted resigner and 3rd party trust vendor
service market and now seem to suggest the DKIM WG Domain Signing
Practices standardization efforts was not a work item and never
existed in the first place as a charter item, when in fact, it is
still today a WG charter item.
Very odd.
--
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com
DRAFT IETF WORKING GROUP CHARTER
14 Oct 2005
Domain Keys Identified Message (DKIM)
CHAIRS:
TBD
AREA DIRECTORS:
Russell Housley, Sam Hartman
AREA ADVISOR:
Russell Housley <housley@xxxxxxxxxxxx>
MAILING LISTS:
General Discussion: ietf-dkim@xxxxxxxxxxxx
To Subscribe: http://mipassoc.org/mailman/listinfo/ietf-dkim
Archive: http://mipassoc.org/pipermail/ietf-dkim/
DESCRIPTION OF WORKING GROUP:
The Internet mail protocols and infrastructure allow mail sent from one
domain to purport to be from another. While there are sometimes legitimate
reasons for doing this, it has become a source of general confusion, as well
as a mechanism for fraud and for distribution of spam (when done
illegitimately, it's called "spoofing"). The DKIM working group will
produce standards-track specifications that allow a domain to take
responsibility, using digital signatures, for having taken part in the
transmission of an email message and to publish "policy" information about
how it applies those signatures. Taken together, these will
assist receiving domains in detecting (or ruling out) certain forms of
spoofing as it pertains to the signing domain.
The DKIM working group will produce summaries of the threats that are
addressed by the standards-track specifications, while acknowledging their
limitations and scope. The DKIM working group will also produce security
requirements to guide their efforts, and will analyze the impact on senders
and receivers who are not using DKIM, particularly any cases in which
mail may be inappropriately labeled as suspicious or spoofed.
While the techniques specified by the DKIM working group will not prevent
fraud or spam, they will provide a valuable tool for defense against them by
allowing receiving domains to detect spoofing of known domains. The
standards-track specifications will not mandate any particular action by the
receiving domain when spoofing is detected. The DKIM working group will not
attempt to define such actions, to establish requirements for trust
relationships between domains, or to specify reputation or accreditation
systems.
The signatures will use public-key cryptography and will be based on domain
name identifiers. Public keys needed to validate the signatures will be
stored in the responsible identity's DNS hierarchy. The specifications will
be based on the following Internet Drafts:
* draft-fenton-dkim-threats
* draft-allman-dkim-base
* draft-allman-dkim-ssp
which represent experimentation and consensus from a number of designers and
early implementors.
Since experimentation resulted in significant Internet deployment of these
specifications, the DKIM working group will make every reasonable attempt to
keep changes compatible with what is deployed, making incompatible changes
only when they are necessary for the success of the specifications.
The resulting protocols must meet typical criteria for success. In addition
to security, these include usability, scalability, ease of deployment, and
cryptographic algorithm independence.
To prevent this task from becoming unwieldy, several related topics are
considered out of scope for the DKIM working group. These topics include:
* Reputation and accreditation systems. While we expect these to add value
to what is defined by the DKIM working group, their development will be
separate, and is out of scope for the DKIM working group.
* Message content encryption.
* Additional key management protocols or infrastructure.
* Signatures that are intended to make long-term assertions beyond the
expected transit time of a message from originator to recipient, which is
normally only a matter of a few days at most.
* Signatures that attempt to make strong assertions about the identity of
the message author, and details of user-level signing of messages (as
distinguished from domain-level keys that are restricted to specific
users).
* Duplication of prior work in signed email, incuding S/MIME and OpenPGP.
Once the primary goals are met, the DKIM working group may also study
whether to adopt a work item for specifying a common mechanism to
communicate the results of message verification to the message recipient.
The generation of a standards-track specification will require an update to
the DKIM working group charter.
The deliverables for the DKIM working group are:
* an informational RFC providing an overview of DKIM, how it can fit
into overall messaging systems and outlining potential DKIM applictions
and future extensions
* an informational RFC presenting a detailed threat analysis of, and
security requirements for, DKIM
* a standards track specification for DKIM signature and verification
* a standards track specification for DKIM policy handling
* a standards track specification for a DKIM DNS Resource Record
GOALS AND MILESTONES:
02/06 WG last call on DKIM threats and security requirements
05/06 WG last call on DKIM signature specification
09/06 WG last call on DKIM policy specification
12/06 WG last call on DKIM DNS Resource Record
12/06 WG last call on overview document
_______________________________________________
Ietf mailing list
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf