The meeting was held at:
INCITS/Information Technology Industry Council
1250 Eye Street, NW - Suite 200
Washington, DC 20005
USA
It was hosted by the InterNational Committee for Information Technology Standards and by:
Blue Pilot Consulting, Inc.
Email: John Benito
Phone: +1 (831) 427-0528
Cell: +1 (831) 212-9073
The meeting was scheduled to begin at 9:30 am on Monday but was delayed because severe weather delayed the arrival of participants. It began at approximately 9:45 as participants continued to arrive. Monday's meeting ended at about 5:00 pm. Tuesday's meeting began at 9:00 am and ended at 4:00 pm.
[The agenda was not followed in numerical order. The topics listed in the remainder of the minutes are numbered according to the agenda rather than by the order of discussion.]
Those present at the meeting introduced themselves and briefly described their interest. Attending persons included the following:
It was noted that some persons who had asked to be participants were not present. On the other hand, we were advised that Tucker Taft (USA) wishes to become a participant.
The convener's presentation [22-OWGV-N0014] outlined the background of the project.
The convener proposed that the co-convener, John Benito, serve as meeting chair. This was approved without objection.
The convener volunteered to serve as meeting secretary. This was approved without objection.
The co-convener outlined procedures for the meeting. Although our products will eventually have to be approved by National Body balloting, our New Work Item Proposal gives us substantial latitude to include liaison representatives of other organizations among our participants. Accordingly we will seek to make decisions via consensus of all participants, keeping in mind the need to gain approval from the National Bodies.
The agenda [22-OWGV-N0016] was approved.
It was noted that Canada, UK, and USA had delegations in attendance and that France, Germany and Japan have designated participants.
Derek Jones provided a brief presentation [22-OWGV-N0020] regarding our next meeting venue at BSI, London, UK, 14-15 September 2006.
[Action - Jones]: By the end of the meeting, it had become clear that a third day of meeting would be desirable. Jones agreed to investigate the possibility.
Joe Jarzombek, the Director of Software Assurance for the National Cybersecurity Division of DHS provided an informative presentation [22-OWGV-N0018] regarding the problem of software assurance.
Jim Moore made a presentation [22-OWGV-N0015] with a dual purpose: (1) to "teach" the terms of reference for the project as outlined in the approved New Work Item Proposal; (2) to develop an FAQ for the web site that will explain the project to others. The following changes were agreed during discussion:
[Action - Moore]: Update the presentation and place the resulting material on the web site. [Subsequent to the meeting, Moore prepared a revision of the presentation [22-OWGV-N0024]. He also placed the resulting material on an FAQ page of the web site.]
Derek Jones, the UK Head of Delegation, made a presentation [22-OWGV-N0022] regarding the UK proposal for a base document for the project. Jones said that the US is primarily interested in security but the UK is primarily interested in safety. It was suggested that we might get Japan more involved if we included quality.
Jones then presented the proposed base document [22-OWGV-N0012]. During discussion, the following points were made:
During discussion, the following question was asked: "Why will our document be better than previous guidelines?" Suggestions for possible answers included the following:
Jones decided that he should report back to the UK shadow that the document was favorably received (with the possible exception of the section on conformance) but that OWGV is not yet ready to designate a base document.
Steve Michell, Canada's Head of Delegation, made a presentation [22-OWGV-N0021] regarding the development of ISO/IEC TR 15942 [22-OWGV-N0013]. During the presentation, he made the point that "vulnerability" is a negative term and that we should instead emphasize a positive approach. We really intend to provide guidance on the use of language features to improve the predictability of execution.
The group discussed a number of issues concerning how it will do business.
[Action - Moore]: On the web site, change the "Resources" page to "Links".
[Action - Moore]: Create a new email reflector named, roughly, SC22 OWGV. Ask people on the current mailer if they wish to be on the new one. Check into the possibility of options to place a prefix in the subject line and sequentially number the messages.
[Decision]: It was decided that prior to each meeting, the officers should gather the relevant documents into a pre-meeting package for distribution. Similarly, after each meeting, a post-meeting package should be distributed. Documents should be harvested from each meeting's Wiki for posting in the document log of the web site and for inclusion in the post-meeting package.
We discussed the ways in which persons might participate in the OWGV. It was noted that the terms of the new work item proposal encourage participation by representatives of working groups as well as external organizations that maintain language specifications.
[Decision]: We want to remain relatively open, but want to stop short of individual free-lancers. We would want organizations in liaison to affirmatively designate their representatives, but we don't have to go so far as to require formal Category C liaison.
We reviewed the affiliations of the participants at the current meeting using Chart 11 of [22-OWGV-N0014]. The following changes were noted:
[Decision]: Although we will normally rely on liaisons to report back to their organizations as they see fit, the OWGV will occasionally create official documents for transmission to organizations in liaison.
[Decision] In general, we will schedule future meetings for 3 or 3-1/2 days. Derek will check whether BSI can be made available to us on either Wednesday or Saturday for our next meeting. In the short-term, we will probably alternate between DC and London.
No other issues were raised.
Robert Seacord, CERT, made a presentation [22-OWGV-N0023] regarding the Secure Coding Initiative at CERT. He also provided an accompanying paper [22-OWGV-N0017].
The CERT Secure Coding Initiative wants to work with developers to eliminate vulnerabilities resulting from coding errors before they are deployed. Seacord has written a book that provides exploitable coding errors in C and C++. He found that it is labor-intensive to prove that a particular error is, in fact, exploitable. CERT is interested in standard secure coding practices. CERT plans to do this work regardless of whether or not OWGV continues. [Plum] Some classes of faults cause vulnerabilities only within a particular context; some cause vulnerabilities wherever they occur, e.g. ones that permit escalation of privilege or execution of code. [Seacord] It is usually easier to fix a defect than to prove whether it is a vulnerability. The CERT initiative will provide both rules and recommendations. Rules must be followed to claim compliance. Recommendations are guidelines or suggestions.CERT is planning to set up a Wiki to gather candidates.
Bob Martin made a presentation [22-OWGV-N0019] on MITRE's Common Weakness Enumeration project.
It was suggested that the CWE, like the CERT Secure Coding Initiative, might be the source of vulnerabilities to be treated by OWGV.
Should the OWGV create a Type 2 Technical Report (a "trial-use" standard) or a Type 3 TR (an informational document)? The UK proposal used the word "conformance". But they actually mean that the document should contain pointed guidance on how different types of users should use the document and what they should say about that usage. The discussion would seem to lead us in the direction of writing a document that could be used for conformance, although we might not want to ask for a change of our Terms of Reference yet.
It was suggested by various folks that the originally scoped effort might require dedicated funding of a few millions of US dollars.
Tom Plum suggests that we should instead try to create a scheme of "levels" to discuss graded requirements for assurance; the levels might trace to particular treatments of vulnerabilities.
Moore suggested that we might capture vulnerabilities from other sources and fit them into our cross-language framework.
The primary interest of CERT is decreasing the number of vulnerabilities. The primary interest of NSA is getting a document created quickly so that it can make a difference.
Who is the audience of the report? Several participants suggested several possibilities:
Secondary audiences:
[Tentative decision]: Request SC22 to remove "[language] selection" from the title of the project.
Discussion of "Raising the Floor" versus "Raising the Ceiling": Wagoner suggested two levels: floor and ceiling. As time goes on, we arbitrarily raise the floor to consciously improve the state of the practice. De Moel suggested that we could provide advance notice to the public of the changes that will be made, providing time for them to adjust to the changes.
[Action - Plum and Seacord]: Produce a proposal for "levels" to be used.
Moore offered a "half-baked" idea for finessing the audience/usage issue. The report would be a list of vulnerabilities, annotated in various ways such as the following:
Different annotations would support different forms of usage, hence different audiences. Audiences could be added from time to time by incorporating additional annotations.
Jones noted that Annex B of UK document addresses this subject.
Moore asked if this approach is more suitable to be treated by a "registry"? Michell noted that it is difficult to conform to a registry because it changes unpredictably. Burch asked if we could snapshot a registry to produce standards/TRs? Others responded that we can do that informally without the overhead of an ISO-operated registry.
[Action - Moore, Waggoner, Jones]: Produce a more complete proposal for Moore's "half-baked" idea.
Discussion of which languages will be treated? [Decision] The general consensus was that we should treat whichever languages are represented by participants in the group. But it was also agreed that we should recruit some participants.
[Action - Benito and Jaeschke]: Recruit someone from Eiffel.
[Action - Moore]: Confirm that someone will represent Cobol.
[Action - Benito and Moore]: Follow up on current discussions with Java representative.
[Action - Plum]: Get himself, or someone else, appointed as the liaison for C#.
We discussed PL/I, SQL, LISP, Prolog as possibilities for future work.
De Moel suggested that these issues ought to be offered to the mailer for discussion.
28 July is the target for the next post-meeting mailing
28 August is the target for the next pre-meeting mailing.
[Decision 01-01]: Although we will normally rely on liaisons to report back to their organizations as they see fit, the OWGV will occasionally create official documents for transmission to organizations in liaison.
[Decision 01-02] In general, we will schedule future meetings for 3 or 3-1/2 days. Derek will check whether BSI can be made available to us on either Wednesday or Saturday for our next meeting. In the short-term, we will probably alternate between DC and London.
[(Tentative) Decision 01-03]: Request SC22 to remove "[language] selection" from the title of the project.
[Decision 01-04]: It was decided that prior to each meeting, the officers should gather the relevant documents into a pre-meeting package for distribution. Similarly, after each meeting, a post-meeting package should be distributed. Documents should be harvested from each meeting's Wiki for posting in the document log of the web site and for inclusion in the post-meeting package.
[Decision 01-05]: The OWGV should remain open to participation, but stop short of permitting individual free-lancers. We would want organizations in liaison to affirmatively designate their representatives, but we don't have to go so far as to require formal Category C liaison.
[Action 01-01 - Jones]: Investigate the possibility of scheduling a third day for Meeting #2 in London.
[Action 01-02 - Moore]: Update the proposed FAQ and place the resulting material on the web site. [CLOSED - completed.]
[Action 01-03 - Moore]: On the web site, change the "Resources" page to "Links". [CLOSED - completed.]
[Action 01-04 - Moore]: Create a new email reflector named, roughly, SC22 OWGV. Ask people on the current mailer if they wish to be on the new one. Check into the possibility of options to place a prefix in the subject line and sequentially number the messages. [CLOSED - completed. A subject prefix has been implemented but sequential numbering does not appear to be supported by the mailer software that is available to me.]
[Action 01-05 - Pygott] Request MISRA C++ to designate him, or someone else, as their liaison representative to OWGV.
[Action 01-06 - Spees] Consider making arrangements to be accredited as a US delegate. Contact Rex Jaeschke.
[Action 01-07 - Nagle] Request WG5 (Fortran) to designate him, or someone else, as their liaison representative to OWGV.
[Action 01-08 - Benito] Request a liaison representative from WG21.
[Action 01-09 - Plum and Seacord]: Produce a proposal for "levels" to be used.
[Action 01-10 - Moore, Waggoner, and Jones]: Produce a more complete proposal for Moore's "half-baked" idea for organizing the report.
[Action 01-11 - Benito and Jaeschke]: Recruit someone to serve as a liaison representative from Eiffel.
[Action 01-12 - Moore]: Confirm that someone will represent Cobol.
[Action 01-13 - Benito and Moore]: Follow up on current discussions with Java representative.
[Action 01-14 - Plum]: Request C# to designate him, or someone else, as their liaison representative to OWGV.
[Action 01-15 - Benito]: Arrange for meeting in Washington, DC during week of 11-15 Dec 2006.
[Action 01-16 - Benito]: Arrange for colocating meeting with C Working Group in UK during April 2007.
We thanked:
The meeting was adjourned upon the completion of its agenda at approximately 4:00 pm on Tuesday.