////// Full Disclosure Policy (RFPolicy) v2.0 //////
   
   This policy is available at https://www.wiretrip.net/rfp/policy.html
   
   \\\ Executive overview for vendors and software maintainers \\\
   
   This policy states the 'guidelines' that an individual intends to
   follow. You basically have 5 days (read below for the definitions and
   semantics of what is considered a 'day') to return contact to the
   individual, and must keep in contact with them *at least* every 5
   days. Failure to do so will discourage them from working with you and
   encourage them to publicly disclose the security problem.
   
   This policy is not set in stone--in fact, it is encouraged that all
   parties regularly communicate with each during the process, adjusting
   as situations arise.
   
   \\\ Table of contents \\\
   
     Purpose of this policy
   
     Policy definitions
   
     Policy
   
     Detailed/commented explanation of policy
   
     Difference between version 1 and version 2 of RFPolicy
   
     RFPolicy FAQ
   
     Using this policy
   
     Credits
   
   \\\ Purpose of this policy \\\
   
   This policy exists to establish a guideline for interaction between a
   researcher and software maintainer. It serves to quash assumptions and
   clearly define intentions, so that both parties may immediately and
   effectively gauge the problem, produce a solution, and disclose the
   vulnerability.
   
   First and foremost, a wake-up call to the software maintainer: the
   researcher has chosen to NOT immediately disclose the problem, but
   rather make an effort to work with you. This is a choice they did not
   have to make, and a choice that hopefully you will respect and accept
   accordingly.
   
   The goal of following this policy, above all else, is education:
   
     Education of the vendor to the problem (ISSUE, as defined below).
   
     Education of the researcher on how the vendor intends to fix the
   problem, and what caveats might cause a solution to be delayed.
   
     Education of the community of the problem, and hopefully a
   resolution.
   
   With education, through continued communication between the researcher
   and software maintainer, it allows both parties to see where the other
   one is coming from. Coupled with compensation*, the experience is then
   beneficial to the researcher, vendor, and community. Win/win/win for
   everybody. :)
   
   (*Compensation is meant to include credit for discovery of the ISSUE,
   and perhaps in some cases, encouragement from the vendor to continue
   research, which might include product updates, premier technical
   subscriptions, etc. Monetary compensation, or any situation that could
   be misconstrued as extortion, is highly discouraged.)
   
   \\\ Policy definitions \\\
   
     The ISSUE is the vulnerability, problem, or otherwise reason for
   contact and communication.
   
     The ORIGINATOR is the individual or group submitting the ISSUE.
   
     The MAINTAINER is the individual, group, or vendor that maintains
   the software, hardware, or resources that are related to the ISSUE.
   
     The DATE OF CONTACT is the point in time when the ORIGINATOR
   contacts the MAINTAINER.
   
     All dates, times, and time zones are relative to the ORIGINATOR.
   
     A work day is generally defined in respect to the ORIGINATOR.
   
   \\\ Policy \\\
   
   A. The ORIGINATOR will send email regarding the ISSUE to the
   MAINTAINER; the point in time when email is sent from the ORIGINATOR
   is considered the DATE OF CONTACT.
   
   It is important that the ORIGINATOR review any documentation included
   with the object of the ISSUE for indication of a proper method of
   contact. That failing, the ORIGINATOR should check the web site of the
   MAINTAINER for methods of contact. Should the ORIGINATOR not be able
   to locate a suitable email address for the MAINTAINER, the ORIGINATOR
   should address the ISSUE to:
   
   security-alert@[MAINTAINER]
   secure@[MAINTAINER]
   security@[MAINTAINER]
   support@[MAINTAINER]
   info@[MAINTAINER]
   
   regardless of their existence. Anyone who could be deemed as a
   'MAINTAINER' is encouraged to populate at least some of the above
   email addresses. Email auto-responses should not be considered as a
   message from the MAINTAINER.
   
   Note: addressing the ISSUE to InterNIC handles may cause the email to
   be misdirected (for example, to a virtual hosting company who happens
   to host the MAINTAINER's web site). Addressing the ISSUE to the above
   listed email addresses may cause the email to be received by
   non-authoritative persons (for example, to an online service provider
   who happens to have an user named 'security-alert').
   
   B. The MAINTAINER is to be given 5 working days (in respects to the
   ORIGINATOR) from the DATE OF CONTACT; should no contact occur by the
   end of 5 working days, the ORIGINATOR should disclose the ISSUE.
   Should the MAINTAINER contact the ORIGINATOR within the 5 working
   days, it is at the discretion of the ORIGINATOR to delay disclosure
   past 5 working days. The decision to delay should be passed upon
   active communication between the ORIGINATOR and MAINTAINER.
   
   C. Requests from the MAINTAINER for help in reproducing problems or
   for additional information should be honored by the ORIGINATOR. The
   ORIGINATOR is encouraged to delay disclosure of the ISSUE if the
   MAINTAINER provides feasible reasons for requiring so.
   
   D. If the MAINTAINER goes beyond 5 working days without any
   communication to the ORIGINATOR, the ORIGINATOR may choose to disclose
   the ISSUE. The MAINTAINER is responsible for providing regular status
   updates (regarding the resolution of the ISSUE) at least once every 5
   working days.
   
   E. In respect for the ORIGINATOR following this policy, the MAINTAINER
   is encouraged to provide proper credit to the ORIGINATOR for doing so.
   Failure to document credit to the ORIGINATOR may leave the ORIGINATOR
   unwilling to follow this policy with the same MAINTAINER on future
   issues, at the ORIGINATOR's discretion. Suggested (minimal) credit
   would be:
   
   "Credit to [ORIGINATOR] for disclosing the problem to [MAINTAINER]."
   
   F. The MAINTAINER is encouraged to coordinate a joint public
   release/disclosure with the ORIGINATOR, so that advisories of problem
   and resolution can be made available together.
   
   G. If the ISSUE is publicly disclosed, by a third-party, the
   ORIGINATOR is encouraged to discuss the current status of the ISSUE
   with the MAINTAINER; based on that discussion, the ORIGINATOR may
   choose to disclose the ISSUE. The MAINTAINER is encouraged to credit
   the ORIGINATOR for discovering the ISSUE. Should the MAINTAINER
   disclose the ISSUE, or items supporting/relating to the ISSUE
   (patches, fixes, etc), the ORIGINATOR may choose to disclose the
   ISSUE.
   
   \\\ Detailed/commented explanation of policy \\\
   
   This section serves to elaborate on the items in the policy, for
   better understanding.
   
   A. Pretty self explanatory--the ORIGINATOR is to email the MAINTAINER
   about the problem. The ORIGINATOR should do their homework and try to
   find the correct address to email (by checking the MAINTAINER's web
   site, by looking in documentation distributed with the
   software/product, etc). Emailing InterNIC handles or addresses such as
   'postmaster' or 'webmaster' is not good, since they are most likely IT
   support staff and not the proper representatives to handle such a
   situation.
   
   B. The MAINTAINER has 5 work days respond. Note that all times of work
   days are relative to the ORIGINATOR, not the MAINTAINER. Suggestion to
   the MAINTAINER: sooner is better than later--just because you have 5
   days does not mean you need to take them all. The ORIGINATOR is
   technically free to do whatever they want to do after 5 work
   days--however, they should be fair and wait if the MAINTAINER shows
   adequate initiative to fix the ISSUE.
   
   C. Just as the MAINTAINER shouldn't ignore the ORIGINATOR, neither
   should the ORIGINATOR ignore the MAINTAINER. The ORIGINATOR should
   help the MAINTAINER recreate the problem, if necessary. It's probably
   in the best interest of the ORIGINATOR to help the MAINTAINER confirm
   the problem--otherwise, the ORIGINATOR stands to disclose a
   potentially false ISSUE.
   
   D. The MAINTAINER has to actively give status reports. Note that it's
   the MAINTAINER's responsibility to do so, and not the ORIGINATOR's
   responsibility to request them.
   
   E. If the ORIGINATOR does indeed take the time to follow this policy,
   they should be acknowledged not only for doing so, but in general,
   acknowledged for finding the problem. There are proper ways to cite
   references, credit sources, and otherwise respect the origination of
   information--I suggest vendors do the same. If you can not respect the
   ORIGINATOR enough for taking the time to notify you of the ISSUE, the
   ORIGINATOR (and possibly others) may feel reluctant to follow this
   policy with the same MAINTAINER in the future.
   
   F. Making the problem and solution advisories available together
   allows the community to have immediate access to both the problem
   description and the appropriate fix.
   
   G. If the MAINTAINER feels it's appropriate to alert the public of the
   issue, then there's no reason why the ORIGINATOR should not.
   Traditionally, alerting the community of a problem (but not providing
   full exploit details) has proven to be futile; other researchers are
   then just as likely to discover the problem as well--and they may not
   bide by the guidelines set by this policy. Therefore, if the issue is
   to be disclosed, all aspects of it should be disclosed. If a
   third-party discovers and publishes the vulnerability, the MAINTAINER
   and ORIGINATOR should evaluate the status of a fix, and act
   accordingly. No matter what, the MAINTAINER should always credit the
   ORIGINATOR.
   
   \\\ Difference between version 1 and version 2 of RFPolicy \\\
   
     Version 1 required a 2 day initial contact period, and then a 5 day
   wait before disclosure. Due to all the possible ways '2 days' could be
   mishandled, it was removed in favor of a solid 5 day period.
   
     The email section in version 2 was reworked to discourage emails to
   InterNIC handles, and encourage trying to locate the correct email
   address (RTFM :)
   
     Version 2 better defines what should happen at the end of the
   initial 5 day waiting period.
   
     Version 2 adds the provision for sustained contact from the
   MAINTAINER.
   
     Version 2 defines possible actions should the ISSUE become public
   before disclosure by the originator.
   
     "This is not a legal contract" mumbo-jumbo removed from version 2.
   
   \\\ RFPolicy FAQ \\\
   
   Q. This policy uses dates and times for gauging responses. How do time
   zones/holidays/weekends/cultural differences factor in?
   A. First off, as noted above, all dates and times are relative to the
   ORIGINATOR. Now, it is quite possible that a difference in date/time
   perspective occurs, due to: the ORIGINATOR being on a different
   continent than the MAINTAINER, the MAINTAINER having a different work
   week than the ORIGINATOR, the MAINTAINER being sick, the MAINTAINER
   taking an extended weekend, the MAINTAINER having a holiday, etc.
   Therefore the initial contact period was extended to 5 days--we feel
   that 5 days should be adequate to surmount any date/time differences.
   
   Q. I'm a software maintainer, and I can't possibly fix the problem in
   5 days....
   A. You don't have to. If you (re)read the above, you have 5 days to
   establish communication. Provided you cooperate with the researcher
   and keep them 'in the loop', they should provide you with whatever
   time necessary to resolve the ISSUE (within fair reason).
   
   Q. I'm a software maintainer, and I want more than 5 days!
   A. Well, considering that, in general, you don't have *anything*
   technically, this document hopes to provide you with at least 5. Be on
   your best behavior, cooperate with the ORIGINATOR, and you should get
   more. :)
   
   Q. You mention compensation--do ORIGINATORs expect to be paid?
   A. NO! (Well, they shouldn't...I can't definitely predict the
   expectations of people) Compensation, as mentioned in this policy, is
   meant first-and-foremost to be PROPER CREDIT. Academia has
   historically and religiously provided credit when referencing all
   types of works and research; the ISSUE provided by the ORIGINATOR
   should also be thought of as research, and the ORIGINATOR should be
   credited accordingly. Now, beyond that, it may be in the vendor's best
   interest to promote good relations with the researcher, and one
   suggested way is to provide updates and product licenses. A lot of
   research is done on evaluation and trial versions of
   software--providing a single, full license/copy should produce little
   impact on the vendor, but greatly help the researcher. Another
   suggestion is to allow access to support sites/technical content, such
   as TechNet (if you happen to be Microsoft :)
   
   \\\ Using this policy \\\
   
   This policy is free for anyone to modify, republish, sell, or
   otherwise use. The goal is to establish communication and interaction
   amongst the security community (users, researchers, and vendors)--not
   hamper it with copyrights and trademarks.
   
   People are encouraged to use this policy or derivatives. You can make
   use this policy by supplying the URL (found at the top of this
   document) in the initial vendor contact email, and giving indication
   that you intend to following the guidelines stated.
   
   If you intend to be an ORIGINATOR, we suggest you prefix your advisory
   sent to the MAINTAINER with something similar to:
   
   "This advisory is being provided to you under the policy documented at
   https://www.wiretrip.net/rfp/policy.html. You are encouraged to read
   this policy; however, in the interim, you have approximately 5 days to
   respond to this initial email. This policy encourages open
   communication, and I look forward to working with you on resolving the
   problem detailed below." 
   
   In addition, should the ORIGINATOR and MAINTAINER arrive at a unified
   resolution and disclosure, it may be of interest to contact the CVE
   officials (https://cve.mitre.org) to assign a CVE identifier to the
   vulnerability. Doing so allows the vulnerability to be referenced and
   cataloged, facilitating it's acceptance and use into the community.
   
   \\\ Credits \\\
   
   Since this is an important part of what this policy attempts to
   achieve, I should follow the same advice. :)
   
   Version 2 was drafted after extensive input of the community (some
   400+ individual suggestions were received). Apologies for not listing
   all 400+.
   
   Thanks to the following people for initial concepts and input (version
   1):
   
   Aleph1 [aleph1-at-securityfocus.com]
   Steve Manzuik [steve-at-securesolutions.org]
   Weld Pond [weld-at-atstake.com]
   Russ Cooper [russ.cooper-at-rc.on.ca]
   
   Special thanks to Russ Cooper for the large amounts of feedback that
   helped shape version 1 of this policy.
   
   - rain forest puppy [rfp-at-wiretrip.net]