OASIS members, especially spec editors,
Security is growing to be a top concern in today's decentralized and highly intertwined networked world. Obviously, the work everyone does at OASIS can affect how secure -- or insecure --an implementing system may be.
In light of this and to help encourage explicit documentation of security issues in your work, TC Admin, with the help of the OASIS Technical Advisory Board, has added a new section titled "Security Considerations" to the standards track working draft template.
The section is not required but we strongly recommend giving the subject serious thought before dismissing it! While it may not be immediately obvious how your specification might make systems vulnerable to attack, most specifications, because they involve communications between systems, message formats, or system settings, open potential channels for exploit. IETF RFC3552 [1], for example, lists “eavesdropping, replay, message insertion, deletion, modification, and man-in-the-middle” as well as potential denial of service attacks as threats that must be considered in their works.
Also, depending on your downstream plans for your work, you may find this content required. For example, you will need to address it explicitly if you apply for IANA media-type registration.
Note also that this is a starting point. We expect that guidance in this area will evolve over the next year or so.
You don't need to wait for your next work product to take this up. We encourage TC members to review IETF RFC3552 "Guidelines for Writing RFC Text on Security Considerations" and consider how it may apply to the work you have underway now.
Our thanks to Bret Jordan of Symantec for the suggestion.
/chet
----------------
Organized by The World Bank, OASIS, and Georgetown University
Chet Ensign
Chief Technical Community StewardOASIS: Advancing open standards for the information society
http://www.oasis-open.orgPrimary: +1 973-996-2298
Mobile: +1 201-341-1393