CAIF Format Specification - Draft                              O. Goebel
                                                            CAIF Project
                                                        November 7, 2005


 Common Announcement Interchange Format (CAIF) Version 1.2 (Revision 2)
                        (Document Version 1.2.3)


Abstract

   This memo describes an XML-based format for security announcements.
   It defines a basic but comprehensive set of elements that is designed
   to describe the main aspects of an issue related to security.
   Besides addressing more than one issue or problem within a single
   document the format allows to provide information for more than one
   target group of readers as well as multi-lingual textual
   descriptions.  It can be used to selectively produce different
   renderings of an announcement for the intended target groups,
   addressing one, a sub-set, or all problems in one or multiple
   languages.  The set of pre-defined elements can be extended to
   reflect either temporary, exotic or new requirements on a per-
   document basis.  A special markup element allows to include
   information for specific constituencies that can be removed before a
   document is interchanged.  CAIF documents may contain data that allow
   the manual or automatic determination of the affectedness of systems
   by a specific problem.

Copyright Notice

   (c) Copyright Oliver Goebel, The CAIF Project 2004-2005

Conventions Used in this Document

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119.














Goebel                                                          [Page 1]

                               CAIF Format                 November 2005


Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   6
   2.  Motivation  . . . . . . . . . . . . . . . . . . . . . . . . .   8
   3.  Scope of this Document  . . . . . . . . . . . . . . . . . . .  10
   4.  Paradigms . . . . . . . . . . . . . . . . . . . . . . . . . .  11
     4.1.   Information in Relation to an Infrastructural Context  .  11
     4.2.   Minimize Restrictions  . . . . . . . . . . . . . . . . .  12
     4.3.   Normalization and Generic Values . . . . . . . . . . . .  12
     4.4.   Separate Format and Policy . . . . . . . . . . . . . . .  13
   5.  Design Goals  . . . . . . . . . . . . . . . . . . . . . . . .  15
     5.1.   Announcements Addressing More Than One Problem . . . . .  15
     5.2.   Multi-Lingual Announcements  . . . . . . . . . . . . . .  15
     5.3.   Announcements for Multiple Target Groups of Readers  . .  16
     5.4.   Extensibility  . . . . . . . . . . . . . . . . . . . . .  17
   6.  Basic Terminology . . . . . . . . . . . . . . . . . . . . . .  18
     6.1.   Announcement . . . . . . . . . . . . . . . . . . . . . .  18
       6.1.1.   Urgency  . . . . . . . . . . . . . . . . . . . . . .  18
       6.1.2.   Levels . . . . . . . . . . . . . . . . . . . . . . .  19
       6.1.3.   Flavors  . . . . . . . . . . . . . . . . . . . . . .  19
     6.2.   Rendering  . . . . . . . . . . . . . . . . . . . . . . .  19
     6.3.   System . . . . . . . . . . . . . . . . . . . . . . . . .  19
     6.4.   Issuer . . . . . . . . . . . . . . . . . . . . . . . . .  20
     6.5.   Issuing  . . . . . . . . . . . . . . . . . . . . . . . .  20
     6.6.   Distribution or Redistribution . . . . . . . . . . . . .  20
     6.7.   Distributor  . . . . . . . . . . . . . . . . . . . . . .  20
     6.8.   Constituency . . . . . . . . . . . . . . . . . . . . . .  20
     6.9.   Environment  . . . . . . . . . . . . . . . . . . . . . .  20
     6.10.  Reader . . . . . . . . . . . . . . . . . . . . . . . . .  21
     6.11.  Section  . . . . . . . . . . . . . . . . . . . . . . . .  21
     6.12.  Container  . . . . . . . . . . . . . . . . . . . . . . .  21
     6.13.  Markup Text  . . . . . . . . . . . . . . . . . . . . . .  21
     6.14.  Non-Markup Text  . . . . . . . . . . . . . . . . . . . .  21
     6.15.  The Syntax Used in the Synopses  . . . . . . . . . . . .  21
   7.  Using XML to Write Announcements  . . . . . . . . . . . . . .  25
     7.1.   XML Basics . . . . . . . . . . . . . . . . . . . . . . .  25
       7.1.1.   Major XML Components . . . . . . . . . . . . . . . .  25
       7.1.2.   Basic Rules  . . . . . . . . . . . . . . . . . . . .  27
     7.2.   Document Type Definitions (DTD)  . . . . . . . . . . . .  28
   8.  The Main Sections of a CAIF Announcement  . . . . . . . . . .  29
     8.1.   Identification . . . . . . . . . . . . . . . . . . . . .  29
     8.2.   Intended Readers: Target Groups  . . . . . . . . . . . .  29
     8.3.   Constituencies . . . . . . . . . . . . . . . . . . . . .  30
     8.4.   Revision Data  . . . . . . . . . . . . . . . . . . . . .  30
     8.5.   The Subject of the Announcement  . . . . . . . . . . . .  30
     8.6.   The Summary  . . . . . . . . . . . . . . . . . . . . . .  30
     8.7.   "Problem-IDs" - References to the Addressed Problems . .  31
     8.8.   Affected and Not Affected  . . . . . . . . . . . . . . .  32



Goebel                                                          [Page 2]

                               CAIF Format                 November 2005


     8.9.   Determination of the Affectedness  . . . . . . . . . . .  32
     8.10.  Mitigating Factors . . . . . . . . . . . . . . . . . . .  32
     8.11.  The Description in Detail  . . . . . . . . . . . . . . .  33
     8.12.  Context Information  . . . . . . . . . . . . . . . . . .  33
     8.13.  Information about a Possible Solution  . . . . . . . . .  34
     8.14.  References to Other Documents - The Bibliography . . . .  34
     8.15.  Credits  . . . . . . . . . . . . . . . . . . . . . . . .  35
     8.16.  Disclaimer . . . . . . . . . . . . . . . . . . . . . . .  35
     8.17.  Including Other Douments in the Announcement . . . . . .  35
     8.18.  Renderings Included in the Announcement  . . . . . . . .  35
   9.  Text Markup Elements  . . . . . . . . . . . . . . . . . . . .  36
     9.1.   Text Emphasis  . . . . . . . . . . . . . . . . . . . . .  36
       9.1.1.   Emphasizing Text  with The "em" Element  . . . . . .  36
       9.1.2.   Bold Face Text - The "b" Element . . . . . . . . . .  36
       9.1.3.   Very Bold Face Text - The "vb" Element . . . . . . .  37
     9.2.   Special Strings and Text Markup  . . . . . . . . . . . .  37
       9.2.1.   Preformatted Text -The "pre" Element . . . . . . . .  37
       9.2.2.   Vendor Names - The "vendor" Element  . . . . . . . .  38
       9.2.3.   The "code" Element . . . . . . . . . . . . . . . . .  38
       9.2.4.   Program Names - The "program" Element  . . . . . . .  39
       9.2.5.   Services and Daemons - The "service" Element . . . .  39
       9.2.6.   Protocols - The "protocol" Element . . . . . . . . .  39
       9.2.7.   System Features - The "sys-feat" Element . . . . . .  40
       9.2.8.   File Names and Contents - the "file" Element . . . .  40
       9.2.9.   User Text Input - The "user" Element . . . . . . . .  41
       9.2.10.  System Text Output - The "output" Element  . . . . .  42
       9.2.11.  Terminal Interaction - The "terminal" Element and
                its Sub-Elements . . . . . . . . . . . . . . . . . .  42
       9.2.12.  Menus - The "menu" Element . . . . . . . . . . . . .  45
     9.3.   Markup Elements for internal and external Referencing  .  48
       9.3.1.   Internal Cross-References - The "ilink" Element  . .  48
       9.3.2.   Targets of Internal Cross-References - The
                "itarget" Element  . . . . . . . . . . . . . . . . .  49
       9.3.3.   The External Reference "elink" . . . . . . . . . . .  50
       9.3.4.   The "const" Markup Element . . . . . . . . . . . . .  50
       9.3.5.   The "aff" Markup Element . . . . . . . . . . . . . .  51
       9.3.6.   The "update" Element . . . . . . . . . . . . . . . .  54
   10. Document Structuring Elements . . . . . . . . . . . . . . . .  56
     10.1.  The Paragraph Element "p"  . . . . . . . . . . . . . . .  56
     10.2.  The "table" Element and its Sub-Elements "tr" and "td" .  56
     10.3.  Lists: The "list" Element and its Sub-Element "li" . . .  58
     10.4.  The "body" element . . . . . . . . . . . . . . . . . . .  59
     10.5.  The Refencing List "rlist" . . . . . . . . . . . . . . .  60
       10.5.1.  The "tg-ref" Attribute of "rlist"  . . . . . . . . .  61
       10.5.2.  The "headline" Attribute of "rlist"  . . . . . . . .  61
       10.5.3.  The "style"  Attribute of "rlist"  . . . . . . . . .  61
       10.5.4.  The "rli" Element - Sub-Element to "rlist" . . . . .  61
       10.5.5.  An "rlist"-Example . . . . . . . . . . . . . . . . .  63



Goebel                                                          [Page 3]

                               CAIF Format                 November 2005


   11. The Announcement: The Top-Level-Element "caif"  . . . . . . .  66
   12. REQUIRED Elements in a CAIF Announcement  . . . . . . . . . .  67
   13. The Elements Defining the Main Sections . . . . . . . . . . .  68
     13.1.  The "identification" Element and its Sub-Elements  . . .  68
       13.1.1.  The "issuer" Element . . . . . . . . . . . . . . . .  68
       13.1.2.  The "announcement" Element . . . . . . . . . . . . .  69
       13.1.3.  The "type" Element . . . . . . . . . . . . . . . . .  70
       13.1.4.  The "author" Element . . . . . . . . . . . . . . . .  73
       13.1.5.  The "distribution-allowed" Element . . . . . . . . .  73
       13.1.6.  The "earliest-release" Element . . . . . . . . . . .  74
       13.1.7.  The Overall Syntax and an Overall Example for the
                "identification" Element . . . . . . . . . . . . . .  75
     13.2.  The "target-groups" Element  . . . . . . . . . . . . . .  75
       13.2.1.  The "target-group" Element . . . . . . . . . . . . .  76
     13.3.  The "constituencies" Element . . . . . . . . . . . . . .  79
       13.3.1.  The "constituency" element . . . . . . . . . . . . .  79
     13.4.  The "revision" Element . . . . . . . . . . . . . . . . .  80
       13.4.1.  The "issued" Element . . . . . . . . . . . . . . . .  81
       13.4.2.  The "re-issued" Element  . . . . . . . . . . . . . .  82
       13.4.3.  The "revision" Element . . . . . . . . . . . . . . .  83
     13.5.  The "category" Element . . . . . . . . . . . . . . . . .  84
     13.6.  The "subject" Element  . . . . . . . . . . . . . . . . .  86
     13.7.  The "summary" Element  . . . . . . . . . . . . . . . . .  86
     13.8.  The "problems" Element . . . . . . . . . . . . . . . . .  88
       13.8.1.  The "problem" Element  . . . . . . . . . . . . . . .  88
     13.9.  The "mitigation" Element . . . . . . . . . . . . . . . . 106
     13.10. The "affected" Element . . . . . . . . . . . . . . . . . 108
     13.11. The "not-affected" Element . . . . . . . . . . . . . . . 109
     13.12. The "possibly-affected" Element  . . . . . . . . . . . . 110
     13.13. The "determine-affectedness" Element . . . . . . . . . . 111
       13.13.1. The "detitem" Element  . . . . . . . . . . . . . . . 112
     13.14. The "context" Element  . . . . . . . . . . . . . . . . . 114
     13.15. The "description" Element  . . . . . . . . . . . . . . . 115
     13.16. The "workaround" Element . . . . . . . . . . . . . . . . 116
     13.17. The "solution" Element . . . . . . . . . . . . . . . . . 117
     13.18. The "arbitrary" Element  . . . . . . . . . . . . . . . . 117
     13.19. The "bibliography" Element . . . . . . . . . . . . . . . 121
       13.19.1. The "bibitem" Element  . . . . . . . . . . . . . . . 121
     13.20. The "credits" Element  . . . . . . . . . . . . . . . . . 124
     13.21. The "disclaimer" Element . . . . . . . . . . . . . . . . 125
     13.22. The "other-documents" Element  . . . . . . . . . . . . . 126
       13.22.1. The "other-document" Element . . . . . . . . . . . . 126
     13.23. The "rendered-copies" Element  . . . . . . . . . . . . . 127
       13.23.1. The "rendered-copy" Element  . . . . . . . . . . . . 128
   14. Security Considerations . . . . . . . . . . . . . . . . . . . 129
   15. References  . . . . . . . . . . . . . . . . . . . . . . . . . 130
     15.1.  Normative References . . . . . . . . . . . . . . . . . . 130
     15.2.  Informal References  . . . . . . . . . . . . . . . . . . 130



Goebel                                                          [Page 4]

                               CAIF Format                 November 2005


   Appendix A.  Glossary . . . . . . . . . . . . . . . . . . . . . . 132
     A.1.   Well-Formedness  . . . . . . . . . . . . . . . . . . . . 132
     A.2.   Validity . . . . . . . . . . . . . . . . . . . . . . . . 132
   Appendix B.  Keys and Standard Values . . . . . . . . . . . . . . 133
     B.1.   Pre-Defined Values for the "target-group" element  . . . 133
       B.1.1.   The Set of Pre-Defined Values for the
                "tech-background" Attribute of the "target-group"
                Element  . . . . . . . . . . . . . . . . . . . . . . 133
       B.1.2.   The Set of Pre-Defined Values for the
                "orga-overview" Attribute of the "target-group"
                Element  . . . . . . . . . . . . . . . . . . . . . . 134
     B.2.   The Key Values for the "problem" element . . . . . . . . 134
       B.2.1.   The Keyset for the "key" Attribute of the "class"
                Element  . . . . . . . . . . . . . . . . . . . . . . 135
       B.2.2.   The Set of Pre-Defined Values for the  "key"
                Attribute of the "attack-requirements" element . . . 136
       B.2.3.   The Set of Pre-Defined Values for the the  "key"
                Attribute of the "impact" element  . . . . . . . . . 136
       B.2.4.   The Set of Pre-Defined values for the  "key"
                Attribute of the "exploit-status" Element  . . . . . 137
       B.2.5.   The Pre-Defined Values for the "key" Attribute of
                the "risk" Element . . . . . . . . . . . . . . . . . 138
       B.2.6.   The Set of Pre-Defined Values for the "key"
                Attribute of the "probability-of-occurrence"
                Element  . . . . . . . . . . . . . . . . . . . . . . 138
       B.2.7.   The Set of Pre-Defined Values for the  "key"
                Attribute of the "threat" Element  . . . . . . . . . 139
   Appendix C.  The Document Type Definition (DTD) of CAIF . . . . . 141
   Appendix D.  Acknowledgements . . . . . . . . . . . . . . . . . . 162
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . . 163





















Goebel                                                          [Page 5]

                               CAIF Format                 November 2005


1.  Introduction

   This document describes the Common Announcement Interchange Format
   (CAIF), designed to produce, store, and exchange security
   announcements in a standardized way using the Extensible Markup
   Language (XML [2]).  It provides a basic but comprehensive set of
   elements meeting the requirements that have been defined for CAIF [6]
   according the experience gathered over time and that is part of the
   most announcements issued by the various vendors and security teams
   currently established.

   The format can be extended easily and flexibly on a per-document
   basis.  Extensions can be grouped with existing elements or other
   extending elements.  This mechanism enables authors and issuers to
   use CAIF for the representation of various existing annoucement
   formats and putting them into a normalized form without forcing
   issuers to omit valuable or provide unnecessary information.  CAIF
   also can be used as a basis to develop new document formats since the
   set of required elements is small.  Although flexible, CAIF is a
   fully featured document format providing an extensive set of pre-
   defined elements identifying the various sections of a security
   announcement (Section 8) as well as high-level markup elements.
   Since there are only few mandatory sections in a CAIF document, the
   format can be used not only for security announcements but other
   types like briefings or background documents.

   CAIF provides a set of markup elements (Section 9) enabling authors
   to produce highly informative and easy-to-read documents.  These
   elements are intended to transport the information on the special
   meaning or value of the markup text as well as the intention of the
   author to the various renderings and document formats provided to the
   constituency of a (re)distributor according her presentation
   policies.

   Various structuring elements (Section 10) enable authors to structure
   announcements as well as to store textual descriptions in multiple
   languages and for more than one target group of readers (see
   Section 10.4 and Section 10.5).  The format also provides mechanisms
   to address multiple issues in a single document (see Section 10.5).
   A rendering of such can produce a single document that addresses all
   issues or several documents that each address a sub-set of the
   issues.

   By using this XML-based format, announcements can effectively be
   interchanged between issuers and redistributors without loosing
   information or meaning.  The format itself imposes minimal
   restrictions upon the rendering of an announcement, thus makes it
   possible to efficiently reuse of announcements.  A redistributor can



Goebel                                                          [Page 6]

                               CAIF Format                 November 2005


   process an exchanged document according his own presentation policies
   mechanically.

   The format uses a DTD to define the syntax of an announcement.  The
   DTD is provided in Appendix C.

   Issuers and re-issuers can use XSL (XML Style Language) to produce
   specific renderings.

   For authenticity purposes, CAIF can store rendered versions of the
   original announcement -- digitally signed if necessary -- of the
   issuer in a container.  Also, to provide availability, CAIF documents
   MAY contain rendered copies of documents that provide source or extra
   information.





































Goebel                                                          [Page 7]

                               CAIF Format                 November 2005


2.  Motivation

   Due to the way information technology is being deployed, soft- and
   more seldomly hardware defects relevant to security are and will be a
   threat to the operation of IT infrastructure, especially if it is
   connected to the world-wide Internet.  Therefore, information on
   security issues and their solutions are vital for operating such
   infrastructure.

   Information about vulnerabilities is available from many sources, in
   very different formats.  Over time, a specific notification method
   for security issues has evolved: the security announcement sometimes
   called "advisory" (see also Section 6.1 for a discussion about the
   specific meaning of these terms).  However, while there is consensus
   among authors that such a class of documents exists, current security
   announcements differ substantially in almost any aspect.  This
   diversity leads to three major problems:

   o  Infrastructure operators who read original security announcements
      need a considerable amount of time, experience, and expertise, to
      decide if action is necessary and which countermeasures have to be
      taken.

   o  Providers of security-related information have to prepare their
      own announcement, in a format familiar to their audience or
      constituency, resulting in a massive multiplication of work.

   o  It is not immediately obvious if two security announcements
      address the same problem.  Readers have to check carefully every
      source of information, in order not to fail to notice a different
      issue or crucial details on the same issue.

   Experience shows that a uniform structure for security announcements
   can help to reduce these problems.  Structured announcements also
   have the potential to facilitate augmented redistribution, e.g. the
   preparation of derived documents tailored to meet reader-
   requirements and contain constituency-specific information (see
   Section 6.8).

   Although there have been several activities going on (e.g.  the EISPP
   Common Format [19] and [17]), that are and have been intended to help
   structuring the dissemination of information about security issues,
   no standardized format, that meets the requirements from the various
   actors and is flexible enough to meet new requirements quickly, has
   evolved yet.  Thus, a huge amount of information is available but
   still it represents a challenging task for most potential users of
   such information to collect and evaluate it, and make sure not to
   miss an essential bit.  A mitigation for one of the major problems,



Goebel                                                          [Page 8]

                               CAIF Format                 November 2005


   that was acute in the past, seems to establish: issuers have adopted
   reference databases (like the CVE Project [12], or the iCAT Metabase
   [13]) to uniquely identify the problems their documents provide
   information about.

   However, distributors of security announcements need to present the
   documents according to their presentation policy and local
   typesetting conventions.  This is the reason why a presentation-
   independent interchange format is needed, to avoid that many
   different announcements are issued regarding the same topic, thus
   producing extra work and confusing readers.

   A standardized structure for security announcements helps authors to
   include information that readers need to quickly decide the relevance
   of an announcement.  Combined with the familiarity a standard format
   can be expected to create among readers, this potentially results in
   easier access to security-relevant information.  The format should be
   not too restrictive in its regulations and extensibility since
   requirements may change quickly in detail and other formats in the
   security context should be covered as well.  Thus, extensibiliy is a
   desirable goal to achieve when designing the format.

   As a conclusion, a standardized structure for security announcements
   can help to disseminate essential information on security issues both
   more quickly and more widely.  A canonical way of reading security
   announcements should help to increase security awareness amongst
   readers who lack the time and experience needed to cope with the
   flood of announcement in different formats and using different
   terminology.

   In January 2003 RUS-CERT has issued a paper that outlines a set of
   requirements such a format should meet [6].  Based on this set and on
   some further requirements that have been identified, the Common
   Announcement Interchange Format (CAIF) has been developed.

















Goebel                                                          [Page 9]

                               CAIF Format                 November 2005


3.  Scope of this Document

   This document describes the syntax and sematics of the Common
   Announcement Interchange Format (CAIF).

   The complete set of CAIF documents will presumably consist of the
   following documents:

   o  the requirements document, first issued in January 2003

   o  this document describing the format specification (based on the
      requirements described in the document mentioned above

   o  a technical quick-start document, describing how to use the
      features of the format

   o  guidelines for issuers (based on previous experience of issuers
      and early adopters of the CAIF standard)

   o  guidelines for readers (amongst other things, outlining the data
      and procedues readers need to know to use CAIF announcements
      efficiently).

   None of these documents will try to enforce a specific policy
   regarding the disclosure of security-related information.  CAIF
   describes the structure (and, indirectly, the content) of security
   announcements.
























Goebel                                                         [Page 10]

                               CAIF Format                 November 2005


4.  Paradigms

4.1.  Information in Relation to an Infrastructural Context

   Experience shows, that it is very important to distinguish between
   information that is independent from an infrastructural context (i.e.
   a given constituency (Section 6.8)) and information that is depending
   on such, when writing and exchanging announcements.  Especially the
   risk assessments of the various types, that represent a substantial
   part of an announcement, divide in those two categories.  When an
   announcement is distributed (Section 6.6) and SHALL be reusable by a
   third party, it MUST be possible to decide mechanically which parts
   of the information provided is depending on the distributors's
   constituency's IT infrastructure.

   In order to avoid confusion, the CAIF document format generally
   provides information that SHALL be independent from a given
   infrastructural context.  Especially the "risk" element
   (Section 13.8.1.7) MUST contain such an assessment, i.e. it describes
   the "technical risk".

   Some sections are intended to contain assessment information that is
   dependent from an infrastructural context.  These sections can be
   removed from an announcement either by the distributor before the
   distribution or before the rendering of the distributed announcement.
   The following elements may contain context-dependent assessment
   information:

   probability-of-occurrence -- This element (see Section 13.8.1.8)
      provides an assessment on the probability the problem or its
      exploitation by an attacker causes the impacts (Section 13.8.1.5)
      described.

   threat -- This element (see Section 13.8.1.9) may contain an
      assessment on the threat the problem described imposes upon a
      given infrastructural context.

   All other sections SHOULD NOT contain information that is specific to
   a given constituency unless it is enclosed in the tags of the markup
   element "const" (Section 9.3.4) which refers to a defined
   "constituency" (Section 13.3.1).  When the document is distributed
   outside the constituency, the distributor can decide whether the
   constituency-specific information is to be kept or removed.

   If used carefully the "const" markup element with its reference to
   the constituency description given in the "constituency" section
   makes clear which piece of information is specific to which
   constituency.  The "constituency" element can also be used to define



Goebel                                                         [Page 11]

                               CAIF Format                 November 2005


   abstract IT environments.  Thus an issuer can write special text
   paragraphs referring to the various abstract constituencies.

4.2.  Minimize Restrictions

   To be usable it is vital for a standardized format to impose only
   minimal restrictions upon an issuer or distributor of an announcement
   when writing or rendering announcements.  Especially the rendering of
   an announcement should be possible according local preferences and
   policies.

   CAIF provides a minimal mandatory framework for announcements that
   allows to identify the document, its issuer, as well as its revision
   history uniquely.  For all other aspects that are considered as being
   useful data structures are available and may be present optionally in
   an announcement, thus restrictions are minimal when using the format
   for documents.

4.3.  Normalization and Generic Values

   The field of IT-security is very complex and many things and aspects
   are highly interwoven.  Thus identifying the aspects of security
   issues and defining classifications to describe them to help evaluate
   and assess their risk and threat is a crucial although hard job.

   Since there may arise security issues that have different or new
   aspects which are important to be described and considered when
   assessment is done, it is important to identify generic aspects that
   are as atomic as possible and do not change over time.  Besides
   possible conflicts that may occur when new requirements arise it has
   proven useful to use atomic elements to describe more complex
   circumstances, in other words, a normalization of a description
   scheme minimizes space requirements and provides flexibility when it
   comes to map hitherto unknown issues.

   For example, it is very common to describe an impact a problem has on
   IT-infrastructure as a "remote root exploit".  Its meaning is quite
   intuitive.  If this value would be used as a standard value it would
   combine several aspects that do not necessarily belong to the
   "impact" aspect.  It says "remote" which is rather a requirement to
   attack successfully than a part of the impact.  Besides the fact that
   the use of the term "root" is not generic, because only on UNIX
   derivates there is a user "root" that has system privileges, the term
   "exploit" rather describes the act of attacking and exploiting the
   problem than an aspect of the impact.  Especially in this case the
   proper impact would be a "compromise" instead of an "exploit".  Hence
   "remote root exploit" migles up three (more or less) atomic aspects.
   When it comes to categorize other impacts, these aspects again have



Goebel                                                         [Page 12]

                               CAIF Format                 November 2005


   to be included in the values, like: "local root exploit", "remote
   service denial-of-service", "local system denial-of-service", "remote
   user compromise", and so on.

   To avoid such a flood of categorization values normalization is a
   good approach, having the side effect, that generic new aspects can
   be defined independently from all existing values.  Such then can be
   combined with the exiting ones to create a set of new expressions
   describing an issue.  E.g. "remote root compromise" could be devided
   into the values "remote" for the aspect "attack-requirements" and
   "root compromise" -- being converted in the generic value "system
   compromise" -- for the aspect "impact".

   CAIF tries to identify atomic aspects of security issues as well as
   generic values for them to achieve the goal of providing a compact,
   comprehensve and easy-to-extend categorization scheme.

4.4.  Separate Format and Policy

   When writing documents that describe security relevant problems an
   assessment of the risk or threat this problem imposes on a given
   system or infrastructure usually is a relevant part of the document.
   Such assessments are done using a policy that define the aspects that
   have to be taken into account as well as their weighting when
   calculating the result.  Currently, there are many different policies
   in use, in fact most of the issuers use their own way to assess
   problems.

   There are being made efforts to standardize the way such assessments
   are done (e.g. in the Common Vulnerability Scoring System (CVSS)
   [15]) to make them comparable and enable users to evaluate them more
   easily.  Although this is a highly desirable approach, its
   implementation is a challenging task since there are many other
   systems in use and even some of the projects proposing a standardized
   format for security advisories also define a fixed policy for the
   assessment (e.g. the the EISPP Common Format [19]) and hence cannot
   adopt a policy that is defined elsewhere, like CVSS is.

   Therefore, one of the paradigms of CAIF is the separation of the
   format and the policy to assess problems.  In some respect this
   aspect is a part of the paradigm to "minimize restrictions"
   (Section 4.2) but it is of such prominent importance, that it is made
   paramount to the development of CAIF.  When producing documents with
   CAIF authors are not forced to use a specific policy and pre-defined
   values when making an assessment of the issue described in the
   document.

   Nevertheless to be operational in the absence of an external policy,



Goebel                                                         [Page 13]

                               CAIF Format                 November 2005


   CAIF implements a set of OPTIONAL elements, that are designed to
   contain results of an assessment of the issues described in the
   document (see Section 13.8.1.7, Section 13.8.1.9, and
   Section 13.8.1.8) as a minimum framework.  Besides an OPTIONAL "key"
   attribute that may have one of four values (see Appendix B.2.5,
   Appendix B.2.6, and Appendix B.2.7), each element also provides a
   "policy" attribute that allows to reference the policy used to make
   the assessment.

   This rather generic approach allows authors to assess the issues
   described according to any policy either by using the "key"
   attributes with their built-in values or any other value within the
   various elements provided by CAIF.  If the set of elements is not
   sufficient, additional elements can be defined via the "arbitrary"
   element (Section 13.18).




































Goebel                                                         [Page 14]

                               CAIF Format                 November 2005


5.  Design Goals

5.1.  Announcements Addressing More Than One Problem

   When designing CAIF one of the major goals was the ability to address
   more than one problem within a single document, e.g. if issues have
   to be described, that consist of more than one problem, vulnerability
   or exposure, or an issuer wants to produce a cumulative patch
   announcement or a bulletin digest.

   CAIF provides mechanisms to include information for several
   distinctive issues within a single XML document.  It is possible to
   individually describe the aspects (Section 6.11) for the problems or
   provide information that fits for a sub-set or all problems at the
   same time.  For example: if a set of three problems is described, the
   announcement may have three description sections (Section 13.15) each
   providing information about one of the problems, but only one impact
   element (Section 13.8.1.1) providing information about the impact of
   all three problems, if it is the same, e.g. a "denial of service"
   condition (Appendix B.2.3).

   To each problem, vulnerability or exposure an ID unique to the
   document (Section 13.8.1) is assigned.  Within the document these IDs
   then can be referenced (Section 10.5.4), either individually or as a
   set.

5.2.  Multi-Lingual Announcements

   In many cases it is useful to provide an announcement in more than
   one language.  Vendors, for example, who deliver their products to
   more than one speech area may be in need to deliver announcements in
   several languages.  In this case it is useful to be able to render an
   announcement in multiple languages.  Maintaining the various language
   versions in a single document facilitates the handling of
   announcements for example if they are interchanged.

   CAIF provides mechanisms to maintain various language versions within
   a single document.  The "target-group" mechanism (see Section 5.3 and
   Section 13.2) definines the language a textual description is written
   in.

   Rendering the announcement then can produce several documents in the
   different languages.

   When maintainig an announcement, a former mono-lingual announcement
   can become multi-lingual by simply adding the appropriate target
   group and text sections.




Goebel                                                         [Page 15]

                               CAIF Format                 November 2005


5.3.  Announcements for Multiple Target Groups of Readers

   In some cases, it is useful to provide the information of the
   announcement for more than one target group of readers.  Since these
   target groups may have different knowledge of the technology that
   affected systems base on and possibly need a different sight on the
   problem and its impacts, the issuer probably will have to provide
   different textual descriptions on the details.  It MUST be possible
   to reference the specially worded text paragraphs to the several
   target groups so that renderings addressing a special target group
   can be generated.  The default target group usually are system
   administrators who generally have a certain amount of technical
   background knowledge.  If other target groups like users or non-
   technical management have to be notified about security problems,
   less technical descriptions might be useful.  Nevertheless all
   information concerning one issue should be kept within one XML
   document to minimize administrative overhead when handling
   announcements.

   CAIF provides mechanisms (see Section 13.2, Section 10.4, and
   Section 10.5) to include passages for more than one target group in a
   single announcement, thus enabling renderers to produce either one
   document addressing all or several documents each addressing one or a
   sub-set of target group.  CAIF addresses the following aspects of
   target groups:

   language -- besides the other aspects, the language is a basic
      attribute of a target group.

   technical background -- this aspect describes the technical
      background the reader has.  For example: if the intended reader is
      a system administrator good technical background knowledge can be
      assumed whereas little to no background knowledge can be expected
      from an ordinary user.

   organizational overview -- this aspect describes the overview the
      intended reader has within the organization an affected system is
      used.  A system administrator usually has less organizational
      overview than a member of the management, thus the information
      given within sections to the latter probably differs from the bare
      technical facts.  For example: if a system is affected that is
      vital for web-based sales, a manager responsible for sales might
      want to know how the problem described in an announcement affects
      the web-services essential for her scope of responsibility.







Goebel                                                         [Page 16]

                               CAIF Format                 November 2005


   the environment in which the problem occurs -- in CAIF the term
      'environment' indicates the context in which the affected system
      is used.  The context could be a software suite like a personnel
      management system in which the affected ware is a component.  Such
      could be an application like a web-server or the underlying
      operating system that is certified for a special version and
      patch-level by the manufacturer of the suite.  In many cases it is
      a hard job for the administrator of the suite or the hosting
      computer system(s) to decide whether the countermeasures described
      (e.g. a patch for the underlying operating system) in an
      announcement can be applied and which effects they may have on the
      suite.  Defining a target group having this aspect allows issuers
      to provide such extra information.

5.4.  Extensibility

   CAIF introduces a mechanism to flexibly reflect new requirements on a
   per-document basis.  Although the format is very generic and is
   designed to meet the requirements of most major announcement formats
   currently in use, it may be necessary to extend it.

   To enable authors to quickly and easily do so, CAIF introduces the
   element "arbitrary" (Section 13.18) that can be used to contain an
   extra section.  The element has the attribute "name" providing the
   title for the extra section.  The OPTIONAL attribute "extends" has
   the name of a regular CAIF element or another "arbitrary" element as
   value, thus can be grouped with this element to describe a semantic
   relation.  For example: if the author wants the element "workaround"
   (see Section 13.16) to have an extra sub-element "vendor_status", he
   could add the following:

      <arbitrary name="vendor-status" extends="workaround">
        <body headline="Vendor Status" tg-ref="en-admin">
        The vendor has been contacted and is developing a patch to
        fix the problem.  The workaround described has been confirmed
        as being a temporary solution to the problem.
        </body>
      </arbitrary>

   Rendering software could produce an extra section "Vendor Status"
   that belongs to the element "workaround".  Since this new element has
   the name "vendor-status" it may be extended by another "arbitrary"
   element.  Note the "tg-ref" attribute that references the "body"
   element to the target group with the ID "en-admin" (see Section 5.3
   and Section 13.2).






Goebel                                                         [Page 17]

                               CAIF Format                 November 2005


6.  Basic Terminology

   To provide a uniform usage of terms this section defines the basic
   terminology used in this document.

6.1.  Announcement

   Over time the term "advisory" has become common for documents
   describing a problem, vulnerability, or exposure that threatens the
   security of IT infrastructure.  Besides a more or less detailed
   description of the problem itself, such a document usually provides
   information about a solution.  Such could be a vendor patch or a
   workaround.

   Unfortunately "advisory" does not transport a lot of information
   about the degree of urgency the document should be read or the
   provided solution should be applied.  There are some issuers, who use
   the terms "alert" and "warning", but there is no uniquely recognized
   meaning to these terms.  On the other hand a background document
   would not be called an "advisory".  Thus we prefer the more general
   term "announcement" to reflect the more general scope of CAIF,
   although "advisory" is a very good description for a document that
   contains advice for operators of IT infrastructure.  We do not
   abandon the term but define its meaning a little bit more precisely.

   A "CAIF announcement" is an XML document containing information about
   one or more IT security problems or solutions of such or provides
   background information about one ore more IT security issues.  An
   announcement is the source for the various "renderings"
   (Section 6.2).

   An announcement can have several urgency states, content levels, and
   flavors (see Section 13.1.3).

6.1.1.  Urgency

   Depending on the problem the announcement addresses, its "urgency"
   state describes the urgency to solve the problem or take action to
   mitigate it.

   "alert" -- An announcement that describes a serious problem requiring
      immediate action.

   "warning" -- An announcement that describes a potentially serious
      problem, thus requiring early action.






Goebel                                                         [Page 18]

                               CAIF Format                 November 2005


   "advisory" -- An announcement that describes a problem and advises
      action.  Such could be a theoretical problem which is hard to
      exploit and therefore does not impose an acute risk.  Note that
      this state may change over time.

   "informational" -- A general document like a background document
      about a security issue.

6.1.2.  Levels

   The content "level" defines the detailing of the description.

   "brief" -- A brief announcement about a security issue or problem.
      This level can be used as a cross-reference announcement if the
      issue has been described somewhere else.

   "full" -- A fully qualified announcement, providing all or a
      substantial sub-set of the informative sections (Section 8).

   "digest" -- An annoucement that addresses more than one issue or
      problem, e.g. a description of a patch bundle.

6.1.3.  Flavors

   "vulnerability-description" -- The announcement describes a
      vulnerability but does not provide a patch as a solution.
      Nevertheless another solution like a workaround can be provided by
      an announcement with this flavor.

   "patch-notification" -- The announcement describes a problem and
      provides a patch as a solution.

   "heads-up" -- The announcement is neither describing a known
      vulnerability nor a patch but rather a an issue that requires the
      reader to raise attention on some special activity or
      circumstances.

6.2.  Rendering

   A rendering is a document in a presentation format that has been
   generated from the XML code of an announcement (Section 6.1).
   Presentation formats can be Spartan, like plain text, or rich like
   PDF.  Note, that HTML and its derivates are presentation formats too.

6.3.  System

   The term "system" used in an announcement refers to a platform, soft-
   or hardware product, a protocol, or any other IT element that can be



Goebel                                                         [Page 19]

                               CAIF Format                 November 2005


   "affected" of a security problem or issue (see Section 13.10).

6.4.  Issuer

   The author of an announcement, or, if the author works for an
   institution which chooses to attribute announcements to itself, that
   institution.  The issuer initially generates and publishes the
   announcement.

6.5.  Issuing

   The act of an issuer (Section 6.4) giving their constituency
   (Section 6.8) or the public access to a rendering of an announcement
   produced by the issuer.  The issuer is said to "issue" an
   announcement.

6.6.  Distribution or Redistribution

   The act of letting others access to renderings or the XML-source of
   an announcement after it has been received from the issuer
   (Section 6.4) or another distributor (Section 6.7)).  The distributor
   is said to "distribute" an announcement, if the latter applies it is
   also said to "redistribute" an announcement.

6.7.  Distributor

   A party who distributes or redistributes announcement renderings or
   XML-sources.  For clarification the term "redistributor" can be used
   for a distributor who redistributes an announement.

6.8.  Constituency

   The set of users and administrators of the IT infrastructure
   consulted by the issuer (Section 6.4) or (re-)distributor of an
   announcement as well as the infrastructure itself

6.9.  Environment

   In CAIF an "environment" describes the context in which an affected
   system is used.  Usually this is a set of wares that work together to
   create a suite.  Such could be a piece of application software that
   relies on an underlying operating system.  If there is a problem in
   this OS it most probably would affect the application as well, even
   if the latter is bug-free.  Besides the problem, the solution of the
   problem may affect the application as well.  Hence, the description
   of the problem in the OS itself may be quite different from the
   description of the same problem within the "environment".




Goebel                                                         [Page 20]

                               CAIF Format                 November 2005


6.10.  Reader

   A person who reads an announcement, usually a member of the
   constituency (Section 6.8).

6.11.  Section

   A part of an announcement containing specific information.  "Standard
   sections" have well-defined content, which sometimes can be processed
   automatically.  CAIF defines a set of sections (Section 8).

6.12.  Container

   A mechanism for transport and storage that allows to include data in
   arbitrary formats (like pdf or other) in XML-based announcements.
   Such also can be documents in XML formats other than CAIF.

6.13.  Markup Text

   Text that MAY contain CAIF's markup (Section 9) and structuring
   elements (Section 10) except the rlist element (Section 10.5) and
   body element (Section 10.4).

6.14.  Non-Markup Text

   Text that does not contain any of CAIF's elements, neither markup
   (Section 9) nor structuring elements (Section 10), or any other
   elements, i.e. plain text.

6.15.  The Syntax Used in the Synopses

   In this document the syntax of XML elements and their usage are given
   in a syntax scheme similar the one used in the "man" pages of the
   UNIX/Linux world.  It defines expressions that consist of the
   following elements:

   o  Literals -- All characters and strings that are not metacharacters
      or keywords are to be read literally, i.e. they represent the real
      text that is present in the code.

   o  Tokens -- Strings enclosed or separated by metacharacters.  They
      can consist of literals or tokens.

   o  Metacharacters -- Special characters that allow to define wether
      and how often a token may occur or define alternatives.  The
      following metacharacters are used:





Goebel                                                         [Page 21]

                               CAIF Format                 November 2005


      1.  Square brackets "[]" are used to enclose literals or tokens
          that may or may not occur in a token.  For example

            [token1] token2

          matches

            token2

          as well as

            token1 token2

      2.  Winged brackets "{}" are used to enclose literals or tokens
          that may occur zero or multiple times.  For example:

            token1{ token2}

          matches

            token1

          as well as

            token1 token2 token2 token2 token2

          or any other number of " token2".  Note the blank space
          character right after the obenin bracked, it is part of the
          string, that to be matched.






















Goebel                                                         [Page 22]

                               CAIF Format                 November 2005


      3.  The separation bar "|" is used to define an alternative.  To
          clarify to which tokens or literals the alternative apply,
          round brackets "()" can be used grouping the expression.  For
          example:

            token1|token2
           or
            (token1|token2)

          match

            token1

          or

            token2

   o  Keywords -- are used to describe special values that are used
      within XML.  The following keywords are used:

      1.  ID -- An ID is an identifyer string that MUST be unique within
          a CAIF document.  It MUST NOT contain any whitespace
          characters.  The ID is an anchor for IDREFs (see below) that
          refer to them.  E.g. the expression:

            <element id="ID"/>

          matches the following code:

            <element id="This_is_an_id"/>

          but not

            <element id="This is an id"/>

      2.  IDREF -- An IDREF refers to an ID (see above).  To establish a
          reference it MUST have the same value as the referenced ID.
          E.g. the expression:

            <the-other-element ref="IDREF{ IDREF}"/>

          matches the following code:

            <the-other-element ref="This_is_an_id"/>

          This element refers to the ID "This_is_an_id"





Goebel                                                         [Page 23]

                               CAIF Format                 November 2005


          The expression also matches:

            <the-other-element ref="These are all ids"/>

          Here, the element refers to the IDs "These", "are", "all", and
          "ids".


          If an IDREF in a CAIF document has a value that is not defined
          by an ID (see above), the validation of the document fails.
          Note, that this is not characteristic to CAIF but to its
          nature as an XML format.



   o  The ellipse "..." is used, whenever arbitrary text can be
      provided.  In some cases, the synopses contain explaining text
      instead of an ellipse.



   Note, that this pseudo syntax is not intended to be processed
   mechanically but rather as a possibility to compactly display the
   syntax of a CAIF element.



























Goebel                                                         [Page 24]

                               CAIF Format                 November 2005


7.  Using XML to Write Announcements

   In this chapter neither a formal nor comprehensive description of XML
   is given.  The chapter provides some basic knowledge useful when
   producing announcements according to the syntax described in CAIF's
   Document Type Definition (see Appendix C).  For the definition of XML
   and further reading see [2].

   If you're already familiar with XML, you might want to skip this
   section.

7.1.  XML Basics

   XML requires few but strict rules when writing documents.  XML looks
   very much like HTML because both share the same roots, but unlike
   usable HTML, writing XML requires more discipline.

7.1.1.  Major XML Components

   There are four major components XML is made up from (an "empty
   element" is a special peculiarity of "element" thus passes not for a
   "major component").

7.1.1.1.  Entity

   An Entity is a textual macro unique to a document that is replaced
   with text or XML components, when the document is processed.  An
   element starts with an ampersand character "&" and ends with a
   semicolon ";".

   Example:

           &entity;

   Meta characters like the ampersand are expressed as entities: "&amp;"
   is replaced by the character "&" in a document rendering.

7.1.1.2.  Element

   Elements are the main components of an XML document.  An element
   usually refers to a start tag, an end tag, and all the characters
   and/or XML components in between.  Each element has a unique name.
   The element name enclosed in angle brackets -- "<" and ">" --
   represents the start tag wheras the element name preceeded by a slash
   "/" represents the end tag.






Goebel                                                         [Page 25]

                               CAIF Format                 November 2005


   Example:

           <element>enclosed text and components</element>

7.1.1.3.  Empty Element

   There is a special form of an element that is called "empty element".
   An empty element draws the start and the end tag into one tag and
   consequently does not enclose any text or XML components.  The name
   of an empty element has a trailing slash "/".  Empty elements usually
   have attributes (see next paragraph).  Empty elements are not used in
   HTML.

   Example:

           <empty-element/>

7.1.1.4.  Attribute

   An "attribute" is an extension to an element.  It has a name and a
   value, where the value MUST be quoted in single or double quotes.  An
   element can have multiple attributes.  Attributes MAY only occur in
   the start tag of an element or in an empty element.

   Examples:

           <element attribute="value">
             enclosed text and components
           </element>

           <empty-element attribute="value"/>

7.1.1.5.  Comment

   Comments are (usually ;-) ignored by XML-processing software.  A
   comment starts with the string "<!--" and ends with the string "-->".
   All text enclosed in these strings is ignored.  Comments can contain
   arbitrary text except two dashes immediately following each other
   "--".

   Example:

           <!--
             This text is regarded as comment and not to be processed.
           -->






Goebel                                                         [Page 26]

                               CAIF Format                 November 2005


7.1.2.  Basic Rules

   The following rules apply to produce "well-formed" (Appendix A.1)
   documents:

   1.  Elements MUST be nested correctly.  Every element's start tag
       MUST match its end tag like brackets in program code, e.g.

           <first>
                   blah
                   <second>
                           foo
                   </second>
                   <third>
                           bar
                   </third>
                   blubber
           </first>

       This is allowed in XML because the elements are nested correctly.


           <first>
                   blah
                   <second>
                           foo
           </first>
                   blubber
                   </second>

       This is not allowed in XML because the elements are not nested
       correctly.



   2.  The characters "<", ">", and "&" are meta characters and MUST NOT
       be used in a document except for enclosing element names and
       starting entity names.  There are generic entities for these
       characters: "&lt;" for "<", "&gt;" for ">" and "&amp;" for "&".



   3.  XML is case sensitive; for example: the element "<element>" is
       different to the element "<Element>".  Consequently, the
       following is not correct:






Goebel                                                         [Page 27]

                               CAIF Format                 November 2005


           <element> blah </Element>


       This is not allowed in XML because the end tag "</Element>" does
       not match the start tag "&element>".



7.2.  Document Type Definitions (DTD)

   A "Document Type Definition" (DTD) describes the syntax of the XML
   elements and entities used in a particular class of documents.  It
   defines an XML-based language serving the needs of the issue it was
   designed for.

   Software that processes an XML document can use a DTD to validate it.
   A valid (Appendix A.2) document is well-formed (Appendix A.1) and
   matches the definitions of the DTD, i.e. it features all the elements
   that are REQUIRED by the DTD to be part of a document, and - on top
   of that - uses only optional elements and entities that are allowed
   by the DTD.  All elements and entities MUST be used in the correct
   order and syntax.

   CAIF's DTD (Appendix C) describes a language that can be used to
   write security announcements.  It defines the elements to markup
   text, and the elements for structuring text in the document.
   Furthermore it defines elements to provide external references as
   well as document-internal cross-references.  Finally and chiefly it
   defines the overall format of a CAIF document by describing its
   mandatory and optional sections.





















Goebel                                                         [Page 28]

                               CAIF Format                 November 2005


8.  The Main Sections of a CAIF Announcement

   Based on the requirements to CAIF [6] published in January 2003 a set
   of useful sections, reflecting the needs of almost all announcement
   issuers, has been identified.  On top of that, extra sections
   (Section 5.4) can be added to a CAIF document if necessary.  Such
   extra sections can be grouped with CAIF standard sections to let them
   be processed together.  The following chapters give an overview over
   the main sections and their meaning in an announcement.  In CAIF's
   DTD (Appendix C) all sections are defined as top-level elements
   (Section 13), some having sub-elements, some just containing text
   that is to be displayed in a rendering of the document.

8.1.  Identification

   This section contains information about the author (Section 13.1.4),
   and the issuer (Section 13.1.1) of the announcement.  Furthermore it
   identifies the document by an id (Section 13.1.2) that (at least)
   MUST be unique to the set of announcements published by the issuer.
   This section also provides information on the type (Section 13.1.3)
   of the announcement.

   Finally it contains a flag that indicates if the announcement MAY be
   interchanged or shall be kept internal to a specific constituency
   (see Section 13.3.1 and Section 13.1.5).  The "earliest-release"
   element tells processing systems and parties, when the announcement
   or a rendering MAY be published for the first time (see
   Section 13.1.6).

   This section is defined by the "identification" element
   (Section 13.1) which is REQUIRED in a CAIF announcement.

8.2.  Intended Readers: Target Groups

   In the OPTIONAL "target group" section (Section 13.2) the author can
   define the quality of the intended audience of the document.  It is
   possible to define multiple target groups each having a unique ID as
   the reference anchor for paragraphs (Section 10.4, Section 10.5,
   Section 13.19.1, Section 13.23.1) within the document that are
   intended to be read by the members of one or a set of the target
   groups.  Hence it is possible, to create target group specific
   renderings of the announcement containig information taylored for the
   readers (see also Section 5.3.).

   Besides a free text description some attributes (see Section 13.2.1)
   can be provided with values that allow for the mechanical
   categorization of and rendering for the target groups.  They comprise
   the language ("lang"), the assumed technical background knowledge



Goebel                                                         [Page 29]

                               CAIF Format                 November 2005


   ("tech-background"), the overview and responsibility a member has
   within his organization ("orga-overview"), and some information about
   a possible "environment" (Section 6.9) in which the problem described
   has immediate or mediate effects.

8.3.  Constituencies

   The OPTIONAL "constituency" section (Section 13.3.1) can be used to
   describe a specific constituency (Section 6.8).  Since "constituency"
   MAY occur multiple times in an announcement (see Section 13.3), it is
   possible to describe more than one IT infrastructure and its users.
   The element provides an ID that can be referenced by the markup
   element "const" (Section 9.3.4) to allow the provision of
   constituency-specific text passages.  The constituency-specific
   pieces MAY be removed before an announcement is interchanged if the
   issuer does not want them to be distributed.  Another valid use of
   the "constituency" section and the referencing "const" markup element
   is the description of abstract constituencies that have several
   technical characteristics like enabled features of affected systems
   (Section 8.8).  The "const" markup then can be used to enclose text
   passages that reference to these specific characteristics.

8.4.  Revision Data

   This section contains data on the version in combination with the
   date of the first issue (Section 13.4.1) of the announcement.  If the
   announcement has been revised (but not re-issued) this section
   provides data on the changes made as well as the dates of all
   revisions (Section 13.4.3).  Finally, the section provides
   information about re-issuings (Section 13.4.2) of the announcement.

   This section is defined by the "revisions" element (Section 13.4) .
   It is REQUIRED in a CAIF announcement.

8.5.  The Subject of the Announcement

   This is the single subject line of the announcement.  Since email is
   a very important distribution mechanism for plain text renderings,
   the subject of a CAIF announcement MUST meet the same requirements
   like an email subject line.

   The subject is defined by the "subject" element (Section 13.6) which
   is REQUIRED in a CAIF announcement.

8.6.  The Summary

   To provide an overview over the problem described in a CAIF
   announcement this section SHOULD contain a comprehensive summary.



Goebel                                                         [Page 30]

                               CAIF Format                 November 2005


   The summary SHOULD be brief and usually SHOULD NOT contain more than
   two or three phrases.  Of course this is not a 'MUST' criterion
   especially if the announcement describes more than one issue, e.g. in
   a cumulative patch announcement.

   This section is provided in the "summary" (Section 13.7) element
   which is REQUIRED in a CAIF announcement.  If the document is a
   "brief" announcement (Section 13.1.3) the summary SHOULD be more
   exhaustive, replacing the description (Section 13.15) that then MAY
   be omitted.

8.7.  "Problem-IDs" - References to the Addressed Problems

   This is a very important section although OPTIONAL in an
   announcement.  It contains references to issues or problems
   described.  Such references ingeniously are IDs of established
   projects like the Common Vulnerability and Exposures Project (CVE)
   [12] or vulnerability IDs of vendors or the CERT (R) Coordination
   Center [11].  On top of a definite identification of the issues
   described, this section also provides IDs internal to the document
   that identify possible sub-issues or - if the announcement addresses
   multiple topics - each single topic.  Referenced lists (Section 10.5)
   can back-reference to the IDs provided by the "problem" elements
   (Section 13.8.1) that are sub-elements of the "problems" element
   (Section 13.8).

   Within this section the following problem specific characteristics
   can be described:

      -- a classification of the problem for statistical reasons.  An
      example for a common classification is a "buffer overflow bug".

      -- the vector by which the problem can be exploited to perform a
      successful attack, e.g. a specially crafted tcp packet to a port.

      -- the prerequisites an attacker would need to sucessfully exploit
      the problem and achieve the described impact (see below), e.g.
      access to a network that allows to communicate with an affected
      system or console access to such a system.

      -- informaton on the traces an attack trying to exploit the
      problem leaves, like specific traffic or log file entries.  The
      signatures can be provided in the syntax of intrusion detection
      systems (IDS).

      -- the impact a successful attack has on an affected system, like
      its compromise or its non-availability due to a denial of service
      condition.



Goebel                                                         [Page 31]

                               CAIF Format                 November 2005


      -- information about the availability of exploit code like a worm.

      -- constituency (Section 13.3.1) specific and non-specific
      assessments of the risk the problem imposes on affected
      infrastructure.

8.8.  Affected and Not Affected

   CAIF provides several elements to contain information about affected
   (Section 13.10), possibly affected (Section 13.12), and not affected
   (Section 13.11) systems by the problem described.  All three sections
   are OPTIONAL in an announcement.  The term "system" itself is not
   used within the format specification, thus enables authors to
   flexibly use these sections: affected may be a platform, a product,
   either in hard- or software, a protocol, or a concrete implementation
   of a specific system in use, like one special server.  It also could
   be a rather abstract procedure how data is processed in a more
   complex environment comprising of severeal systems -- and users -- or
   a client-server relationship.  The format does not impose
   restrictions here.  The "category" (Section 13.5) contains more
   general information on the quality of the affected systems.

   Information about possibly and not affected systems require
   maintenance in some cases, since these sections SHOULD be updated
   whenever new versions are available that are not affected or evidence
   about the affectedness of hitherto possibly affected systems is
   gained.  Each update of an announcement MUST be documented in the
   "revisions" (Section 13.4) section.

8.9.  Determination of the Affectedness

   In many cases it is useful to provide the reader with information on
   how to determine if the systems she has in use are affected by the
   problem described or not.  Such could be a simple command that
   returns the version number as well as a more sophisticated set of
   steps that have to be performed to get the desired answer.

   It is also possible to include some information that can be fed into
   a parser that automatically is trying to determine if a system is
   affected by the problem dealt with in the announcement.

   Within the section defined by the OPTIONAL element "determine-
   affectedness" (Section 13.13) this infomation can be provided and the
   method (manual vs. the various automatic ones) can be identified.

8.10.  Mitigating Factors

   Sometimes it is useful to describe a problem in a system that is not



Goebel                                                         [Page 32]

                               CAIF Format                 November 2005


   enabled by default or is not configured in a way that makes it
   possible to exploit the problem using the described attack vector.
   Such aspects are called "mitigating factors".

   According to CAIF's paradigm to be as generic as possile and allow
   for the description of issues independently from a given constituency
   (Section 4.1) as well make the primary risk assessment in a worst
   case view, the information contained at first SHOULD address the
   problem or issue regardless if affected systems commonly are deployed
   in a way that makes them vulnerable or not.

   Nevertheless "mitigating factors" are valuable information and SHOULD
   NOT be omitted especially when compiling an announcement since it
   helps to determine whether a given System is affected or not.

   The section "Mitigating factors" is intended to contain information
   about factors that mitigate the risk potential or "technical risk"
   (Section 13.8.1.7) the problem described imposes on affected systems.
   The presence of this section MUST NOT have an effect on the
   assessment of the technical risk.

   Note, that the information provided in this section SHOULD NOT
   generally refer to a specific constituency (Section 8.3) but be
   rather impartial and independent from a constituency.

   Nevertheless CAIF provides mechanisms to include text paragraphs,
   that refer to a specific constituency and can be stripped off the
   document, when distributing it (Section 9.3.4).

   This section is implemented by the "mitigation" element
   (Section 13.9).

8.11.  The Description in Detail

   In this section a detailed description of the issue is given.  CAIF
   does not restrict the content of this section but it is recommended
   that the problem is being described comprehensively, including the
   attack, its requirements and vector the impact and possibly
   subsequent impacts, if applicable.  The information provided SHOULD
   be sufficient for a reader to decide whether the issue is a threat to
   her IT infrastructure or not.

   This section is defined by the "description" element (Section 13.15)
   which is OPTIONAL in an announcement.

8.12.  Context Information

   This section provides background information to enable readers to put



Goebel                                                         [Page 33]

                               CAIF Format                 November 2005


   a described problem in the technical appropriate context.  Issuers
   MUST be aware of the fact, that potential readers of an announcement
   are not necessarily experts in systems that are affected (see
   Section 13.10), thus may have problems in deciding, whether there is
   a threat to their infrastructure.  Therefore it is vital to the
   intended effect of an announcement to be not too brief in providing
   background information about the technical context of a problem.

   Note, that the information provided in this section SHOULD NOT
   generally refer to a specific constituency (Section 8.3) but be
   rather impartial and independent from a constituency.

   Nevertheless CAIF provides mechanisms to include text paragraphs,
   that refer to a specific constituency and can be stripped off the
   document, when distributing it (Section 9.3.4).

   This section is provided by the OPTIONAL "context" element
   (Section 13.14).

8.13.  Information about a Possible Solution

   There are two sections containing information about possible reliefs
   of the problem(s): "solution" (Section 13.17) and "workaround"
   (Section 13.16).  While "solution" provides information about a more
   or less final remedy to the problem, e.g. a patch or the installation
   of a not affected version, "workaround" introduces a temporary
   solution, like the termination of an affected service.

   The elements "workaround" and "solution" are OPTIONAL in an
   announcement.

8.14.  References to Other Documents - The Bibliography

   This section contains a list of references to external documents.  It
   is provided by the "bibliography" element (Section 13.19) which is
   OPTIONAL in an announcement.  References MAY contain Uniform
   Ressource Identifiers (URIs), other references like ISBNumbers, or
   anything else that qualifies as a unique pointer to an external
   document.  Every reference also MAY have a time-stamp that tells the
   reader, when the referenced document has been considerend by the
   author.  Since external documents can change over time, such a time-
   stamp may proove useful.

   There are "primary" references identifying the main sources of the
   information described in the announcement and "informal" references
   that provide additional information e.g. a background paper
   describing the system that is affected by a problem described in the
   announcement.



Goebel                                                         [Page 34]

                               CAIF Format                 November 2005


8.15.  Credits

   This section, implemented by the OPTIONAL "credits" element
   (Section 13.20), can be used to document credits, e.g. to the
   discoverer of the issue.

8.16.  Disclaimer

   This section can contain a standard or special disclaimer for the
   announcement limiting warranties and other legal aspects.  CAIF does
   not provide prefabricated disclaimers since legal regulations vary in
   different countries.

   The section is implemented by the OPTIONAL "disclaimer" element
   (Section 13.21).

8.17.  Including Other Douments in the Announcement

   For authenticity purposes as well as for availability reasons the
   element "other-document" (Section 13.22.1) provides a container to
   include rendered copies of other documents and/or CAIF announcements
   related to the topic.

   Note, that the inclusion of third-party documents MAY imply the
   consideration of copyright issues.

8.18.  Renderings Included in the Announcement

   For authenticity purposes the element "rendered-copy"
   (Section 13.23.1) provides a container to include a rendered,
   possibly digitally signed copy of the orginal issue of the CAIF
   announcement.



















Goebel                                                         [Page 35]

                               CAIF Format                 November 2005


9.  Text Markup Elements

   In order to facilitate the presentation of the description of the
   issue in various renderings (rendered formats, like HTML or PDF) CAIF
   provides an extensive set of markup elements.

9.1.  Text Emphasis

   The CAIF Requirements Document [6] defines a set of three different
   types of emphasis for text, a minor type, that can be omitted in
   Spartan rendering formats, a normal type that MUST be visible in all
   renderings and a major type, that MUST catch the readers eyes in all
   rendered documents.  The following sections describe the elements,
   that are implementing these types of text emphasis.

9.1.1.  Emphasizing Text  with The "em" Element

   The markup element "em" ('emphasis') implements the "minor" emphasis
   defined in Section 6 of the CAIF Requirements Document [6].  Text
   empasized by "em" SHOULD be visible in renderings of a CAIF
   announcement but can be omitted in Spartan formats like plain text.
   Within the "em" element other markup elements are allowed.

   Synopsis:

           <em>...</em>

   Example:

           It is <em>nice</em> to have pretzels with a pint of beer.

   could result in a rendering like this:

           It is nice to have pretzels with a pint of beer.

   Note, that this document is in a Spartan format, thus the rendering
   of this example is in this format too: the emphasis has been omitted.

9.1.2.  Bold Face Text - The "b" Element

   The markup element "b" ('bold') implements the "normal" emphasis
   defined in Section 6 of the CAIF Requirements Document [6].  Text
   empasized by "b" MUST be visible in all renderings of a CAIF
   announcement.  Within the "b" element other markup elements are
   allowed.






Goebel                                                         [Page 36]

                               CAIF Format                 November 2005


   Synopsis:

           <b>...</b>

   Example:

           For major pleasure it is <b>important</b> to drink
           <b>fresh</b> beer.

   could result in a rendering like this:

           For major pleasure it is *important* to drink *fresh* beer.

9.1.3.  Very Bold Face Text - The "vb" Element

   The markup element "vb" ('very bold') implements the "major" emphasis
   defined in Section 6 of the CAIF Requirements Document [6].  Text
   emphasized by "vb" MUST be clearly visible in all renderings of a
   CAIF announcement.  Authors and issuers SHOULD use this type of
   emphasis with care.  Within the "vb" element other markup elements
   are allowed.

   Synopsis:

           <vb>...</vb>

   Example:

           Usually, no beer in the refrigerator means <vb>red alert</vb>
           and should result in immediate actions to solve this
           severe problem!

   could result in a rendering like this:

           Usually, no beer in the refrigerator means *RED ALERT*
           and should result in immediate actions to solve this
           severe problem!

9.2.  Special Strings and Text Markup

   CAIF provides markup elements for special text strings to increase
   the readability of renderings.

9.2.1.  Preformatted Text -The "pre" Element

   The "pre" (pre-formatted) element is similar to the HTML-element of
   the same name.  Formatting rules take no effect to the text enclosed
   by the "pre"-tags in a rendering, i.e. processing software MUST NOT



Goebel                                                         [Page 37]

                               CAIF Format                 November 2005


   re-format text within the "pre" element.  Within the "pre" element no
   other elements are allowed.

   Synopsis:

           <pre>...</pre>

   Example:

           <pre>
           Pre-formatted can text be used for ASCII-art:

           +--------+         --------       +--------+
           | Client |------>/ Packet /------>| Server |
           +--------+       --------         +--------+

           Because it is not re-formatted when rendered.
           </pre>

9.2.2.  Vendor Names - The "vendor" Element

   The "vendor" element identifies vendor names, e.g. the name of a
   company or organization that are distributing systems (Section 6.3).
   Within the "vendor" element other markup elements are allowed.
   Formatting rules SHOULD apply to the text enclosed.

   Synopsis:

           <vendor>...</vendor>

   Example:

           <vendor>Microsoft</vendor> and the
           <vendor>Debian Project</vendor>
           have announced security patches.

9.2.3.  The "code" Element

   The "code" element marks up source-code snippets within the text
   flow.  It is recommended to use a mono-spaced font to display text
   marked up with "code" in a rendering.  Within the "code" element no
   other elements are allowed.  Formatting rules SHOULD apply to the
   text enclosed.

   Synopsis:

           <code>...</code>




Goebel                                                         [Page 38]

                               CAIF Format                 November 2005


   Example:

           <code>#!/bin/bash</code>

9.2.4.  Program Names - The "program" Element

   The element "program" identifies program names and their options
   (also if used without the program name).  For this element too it is
   recommended to display text enclosed by the tags of "program" in a
   mono-spaced font.  Within the "program" element no other elements are
   allowed.  Formatting rules SHOULD apply to the text enclosed.

   Synopsis:

           <program>...</program>

   Example:

           <program>/bin/tcsh</program>

9.2.5.  Services and Daemons - The "service" Element

   The "service" element identifies services and daemons providing
   (network) services of an operating system.  Of course, names of
   daemons can be marked up with the "program" element (Section 9.2.4)
   too, especially if the author wants to describe the program and not
   the service.  Nevertheless if a daemon is mentioned, authors often
   want to describe the service provided by the daemon.  The element
   "service" then can help to make clear the intention of the author.

   Within the "service" element no other elements are allowed.
   Formatting rules SHOULD apply to the text enclosed.

   Synopsis:

           <service>...</service>

   Example:

           ...the <service>Tooltalk</service> service...

           ...<service>statd</service> is a daemon used by NFS...

9.2.6.  Protocols - The "protocol" Element

   The "protocol" element identifies protocols, such as H.325, SMTP or
   HTTP.




Goebel                                                         [Page 39]

                               CAIF Format                 November 2005


   Within the "protocol" element no other elements are allowed.
   Formatting rules SHOULD apply to the text enclosed.

   Synopsis:

           <protocol>...</protocol>

   Example:

           <protocol>HTTPS</protocol> is used to transport encrypted
           HTML pages as well as authenticate servers to clients and
           vice versa.

9.2.7.  System Features - The "sys-feat" Element

   CAIF defines "system features" as aspects of operating systems and
   programs like UIDs, flags, privileges etc.  Within the "sys-feat"
   element no other elements are allowed.  Formatting rules SHOULD apply
   to the text enclosed.

   Synopsis:

           <sys-feat>...</sys-feat>

   Example:

           arbitrary code can be executed under the
           <sys-feat>UID=0 (root)</sys-feat>

9.2.8.  File Names and Contents - the "file" Element

   The "file" markup element is used to identify file names and
   contents.  Within the "file" element no other elements are allowed.

   The element has the OPTIONAL attribute "path".

   If the author wants to markup filenames or paths within continous
   text the element "file" MUST be empty and the file name or path is
   the value of the attribute "path".  Formatting rules SHOULD apply to
   the text in "path".

   If used to markup file content the element is not empty and the
   content is enclosed in the tags of "file".  Text enclosed SHOULD be
   rendered like preformatted text (Section 9.2.1) (whereat the font can
   be different), i.e. formatting rules MUST NOT apply to the enclosed
   text.  If "file" is not empty it is up to the rendering policy if the
   value of the "path" attribute is visible in a rendering or not.




Goebel                                                         [Page 40]

                               CAIF Format                 November 2005


   The element has the OPTIONAL attribute "type" that defines the type
   of the file.  The following values may be used:

   "text" -- a regular text file

   "log" -- a log file

   "config" -- a configuration file

   "source" -- a file containing source for a script or a program, e.g.
      C code or /bin/sh code

   "binary" -- any binary files like pictures, proprietary document
      formats, or compiled code

   Synopsis:

           <file [path="..."]
                 [type="(text|log|config|source|binary)"]>
                       ...
           </file>

   Examples:

           <file path="/home/rustler/RUS-CERT/CAIF/caif.dtd"
                 type="text"/>

           <file path="C:\MyDocuments\CAIF_presentation.ppt"
                 type="binary"/>

           <file path="motd"/>

           <file path="/home/rustler/caif/caif.dtd" type="source">
           <!ELEMENT em            %MTEXT;>
           <!ELEMENT b             %MTEXT;>
           <!ELEMENT vb            %MTEXT;>
           </file>

9.2.9.  User Text Input - The "user" Element

   The markup element "user" contains text a user should put in within a
   terminal session.  It is intended to be used within the "terminal"
   element (Section 9.2.11) but can be used outside this element as
   well.  The text marked up MUST be rendered like text in the "file"
   element (Section 9.2.8).

   Within the "user" element no other elements are allowed.




Goebel                                                         [Page 41]

                               CAIF Format                 November 2005


   The "user" element has an OPTIONAL attribute "prompt" that defines
   the system prompt, e.g. "root@sun", "#", "user@box", or "$".  It is
   recommended to use "$" as a prompt for an ordinary user and "#" for
   the user "root", especially within terminal sessions Section 9.2.11.

   Synopsis:

           <user [prompt="..."]>...</user>

   Example:

           <user prompt="user@sun">ls /home/rustler/RUS-CERT/CAIF</user>

9.2.10.  System Text Output - The "output" Element

   The element "output" contains system text output in a terminal
   session or from a program.  It is intended to be used within the
   "terminal" element (Section 9.2.11) but can be used outside this
   element as well.  The text marked up MUST be rendered like text in
   the "file" element (Section 9.2.8).

   Within the "output" element no other elements are allowed.

   Synopsis:

           <output>...</output>

   Example:

           <output>
           caif-draft.txt    caif-draft.xml         caif.dtd
           CVS/              example_1155.xml       requirements.txt
           RFC/              todo.txt               YeOldeStuffe/
           </output>

9.2.11.  Terminal Interaction - The "terminal" Element and its Sub-
         Elements

   The "terminal" element contains a set of sub-elements to describe a
   terminal session, e.g. to describe in detail how to change
   configuration files or execute commands.  The elements "user"
   (Section 9.2.9), "output" (Section 9.2.10), and "file"
   (Section 9.2.8), that can be used outside the "terminal" element, can
   appear within a "terminal" session.  Other markup text MAY appear
   within the "terminal" element to support remarks between the lines of
   the session.





Goebel                                                         [Page 42]

                               CAIF Format                 November 2005


   Synopsis:

           <terminal>
             {<user>...</user>|
             <output>...</ouput>|
             <file>...</file>|
             other CAIF markup elements}
           </terminal>











































Goebel                                                         [Page 43]

                               CAIF Format                 November 2005


   Example:

           <terminal>
           Log in as <sys-feat>root</sys-feat>:
           <user prompt="$">
           su
           </user>
           <output>
           Password:
           </output>
           <user prompt="#">
           </user>
           Edit <file path="/etc/inetd.conf" type="config"/>:
           <user prompt="#">
           vi /etc/inetd.conf
           </user>
           Scroll to the following line:
           <file path="/etc/inetd.conf" type="config">
           ident  stream  tcp  wait  identd  /usr/sbin/identd  identd
           </file>
           Change to the <sys-feat>insert mode</sys-feat> by typing
           <user>i</user>. Insert a hash symbol <code>#</code>
           at the beginning of the line:
           <file path="/etc/inetd.conf" type="config">
           #ident  stream  tcp  wait  identd  /usr/sbin/identd  identd
           </file>
           Leave the <sys-feat>insert mode</sys-feat> by pressing the
           &lt;ESC&gt; key.
           Write the file and leave <program>vi</program> by typing
           <user>:wq!</user>. Restart <service>inetd</service>:
           <user prompt="#">
           killall -HUP inetd
           </user>
           Drop <sys-feat>root</sys-feat> privileges:
           <user prompt="#">
           exit
           </user>
           <user prompt="$">
           </user>
           </terminal>











Goebel                                                         [Page 44]

                               CAIF Format                 November 2005


   This could be rendered (in the Spartan format of this document) into
   something like:

         Log in as "root":

          $ su
          Password:
          #

         Edit /etc/inetd.conf:

          # vi /etc/inetd.conf

         Scroll to the following line:

          ident  stream  tcp  wait  identd  /usr/sbin/identd  identd

         Change to the insert mode by typing
         "i". Insert a hash symbol '#' at the beginning of the line:

          #ident  stream  tcp  wait  identd  /usr/sbin/identd  identd

         Leave the insert mode by pressing the <ESC> key.  Write the
         file and leave vi by typing ":wq!".  Restart inetd:

          # killall -HUP inetd

         Drop "root" privileges:

          # exit
          $


9.2.12.  Menus - The "menu" Element

   This element is intended to describe different types of menus.  When
   documenting steps to apply a solution or configure a system, modern
   operating systems often require the user to use menus and sub menus
   to do so.  Since there is no generally recommended way to display
   such menus, especially in different formats, CAIF provides some basic
   mechanisms to describe menus.  It is up to issuers and distributors
   to render such menus in the preferred way.

   The "menu" element has the OPTIONAL attribute "title" and the
   REQUIRED attribute "style" that has the following pre-defined values:






Goebel                                                         [Page 45]

                               CAIF Format                 November 2005


   pull-down -- describes a pull-down menue like the "File" menue in
      most applications

   pull-up -- describes a "reverse pull-down" menue like the "Start"
      menue in Microsoft (tm) Windows

   pop-up -- describes a menue that pops up, e.g the mouse menus that
      pop up when a button (usually the right button) is pressed
      somewhere on the background

   window -- a window that pops up, e.g. a warning or error message or a
      window that contains some "tab" menus

   tab -- a tab menue

   tree -- a tree, e.g. for directory trees or similar

   input -- an input widget, can be used to show the reader where to
      type in the required input

   button -- a button widget.

   Note, that this element SHALL NOT describe a complete window or menue
   but rather parts of menus that are necessary to instruct readers to
   execute several actions or understand a special issue.

   The element itself can contain markup text, describing the content of
   the displayed menu.  Each paragraph (Section 10.1) produces a menu
   item, if only one item is needed, the paragraph element "p" MAY be
   ommited.  The "menu" element can be used recursively to describe
   nested menus.

   Synopsis:

           <menu style="(pull-down|pull-up|pop-up|tab|input|button)"
                 [title="..."]>
            ...
           </menu>

   Examples:

   o  A nested pull-down menue can be described by:









Goebel                                                         [Page 46]

                               CAIF Format                 November 2005


           <menu style="pull-down" title="File">
             <p><b>New</b>
             <menu style="pull-down">
             <p><b>Text Document<b></p>
             <p>...</p>
             </menu>
             ...
           </menu>

      The "b" element could be used to mark the selected menue entry.

      A rendering could look like:

           File
           +----------+
           | *New*   +-----------------+
           | ...     | *Text Document* |
           |         | ...             |
           |         +-----------------+
           |          |
           +----------+

   o  A tab in a pop-up window:

           <menu style="window" title="Certificate Manager">
             <menu style="tab" title="Your Certificates">
               <menu style="tree" title="Stuttgart University">
               <p>Oliver Goebel</p>
               </menu>
             </menu>
           </menu>

      A rendering could look like:

           +-------------------------------------------------+
           | Certificate Manager                             |
           |-------------------------------------------------|
           |                                                 |
           |   -----------------                             |
           | / Your Certificates \                           |
           ||                     --------------------------+|
           || Stuttgart University                          ||
           ||  |                                            ||
           ||  +- Oliver Goebel                             ||
           ||                                               ||
           |+-----------------------------------------------+|
           +-------------------------------------------------+




Goebel                                                         [Page 47]

                               CAIF Format                 November 2005


   o  A directory browser window

           <menu style="window" title="/home/rustler/">
             <menu style="tree" title="/">
               <p>bin/</p>
               <p>boot/</p>
               <p>dev/</p>
               <p>etc/</p>
               <p>floppy/</p>
               <menu style="tree" title="home/">
                 <menu style="tree" title="rustler/">
                 <p>draft-goebel-caif.txt</p>
                 <p>...</p>
                 </menu>
               </menu>
               <p>...</p>
             </menu>
             <p>...</p>
           </menu>

      A rendering could look like:

           +-------------------------------------------------+
           |/home/rustler/                                   |
           |-------------------------------------------------|
           |  /                                              |
           |  |                                              |
           |  +- bin/                                        |
           |  +- boot/                                       |
           |  +- dev/                                        |
           |  +- etc/                                        |
           |  +- floppy/                                     |
           |  +- home/                                       |
           |  |   |                                          |
           |  |   +- rustler/                                |
           |  |   |   |                                      |
           |  |   |   +- draft-goebel-caif.txt               |
           |  |   |   +- ...                                 |
           |  |   +-...                                      |
           |  +-...                                          |
           |                                                 |
           +-------------------------------------------------+

9.3.  Markup Elements for internal and external Referencing

9.3.1.  Internal Cross-References - The "ilink" Element

   The "ilink" element provides internal-to-document references, i.e.



Goebel                                                         [Page 48]

                               CAIF Format                 November 2005


   cross-refences.  An "ilink" element contains non-markup text and
   points to an "itarget" within the same document.  The REQUIRED
   attribute "target" references the attribute "name" of the "itarget"
   (Section 9.3.2) element.

   Synopsis:

           <ilink target="IDREF">...</ilink>

   Example:

           See <ilink target="impact">Section "Impact"</ilink>

   The "ilink" element also can be used to refer to a element defining a
   section (Section 13) by providing the "target" attribute with the
   name of the element.

   Software producing a rendering of an "ilink" reference MUST backtrack
   the scope of the ilink element and apply it to the referenced target
   if possible.  In this case the scope is defined as its location
   within a "body" (Section 10.4) or "rlist" (Section 10.5) element
   which has a a specific value in its "tg-ref" attribute.  When
   producing a working link in a rendering the target MUST dynamically
   be located in the same scope of the referenced section.

   For example: if the author places an "ilink" element pointing to a
   itarget (Section 9.3.2) in or the context element (Section 13.14)
   itself in the "body" element of "description" (Section 13.15) that
   refers to the "target-group" (Section 13.2.1) of french-speaking
   developers, then the rendering software MUST produce a link, that
   points to the "body" element of the "context" element that refers to
   the same "target-group".  If such a body element is missing, the
   software SHOULD omit the link generation and produce a warning.

   Unfortunately, the process of valitation against a DTD (Section 7.2)
   cannot find inconsistent links that do not accomplish the conditions
   described above.  Hence, the use of the "ilink" element requires good
   discipline.

9.3.2.  Targets of Internal Cross-References - The "itarget" Element

   The empty element "itarget" provides the anchor an ilink
   (Section 9.3.1) element points to.  It has the REQUIRED attribute
   "name" that contains the value of the ID, the "target" attribute of
   "ilink" points to.






Goebel                                                         [Page 49]

                               CAIF Format                 November 2005


   Synopsis:

           <itarget name="ID"/>

   Example:

           <itarget name="impact"/>

9.3.3.  The External Reference "elink"

   The "elink" element provides references to targets outside the
   containing document trough a Unifom Ressource Identifier (URI).  Like
   the "href" attribute of the "a" element in HTML the REQUIRED "target"
   attribute of "elink" contains an URI that points to the ressource.
   The element contains non-markup text.

   Synopsis:

           <elink target="URI">...</elink>

   Example:

           <elink target="http://www.caif.info/">
           The CAIF Homepage</elink>

9.3.4.  The "const" Markup Element

   The "const" element allows to include constituency (Section 13.3.1)
   specific information in the document wherever markup text is allowed.
   Due to its nature as being a markup element it can be used to enclose
   single words as well as whole text paragraphs.  It has the REQUIRED
   attribute "ref" that is used to reference to one or multiple of the
   constituencies that are defined in the document.

   The "const" element allows to distinguish between information that is
   specific to well-defined constituencies and such that is generally
   valid, thus applies not only to one or a subset of the
   constituencies.

   If used carefully, an author can produce a document that can be
   rendered for the different constituencies without providing
   information that is not intended for the chosen constituency.  If the
   issuer wants the specific information to be kept within his
   constituency the document can be "cleansed" at will from all the
   "const" elements and their content as well as the other elements that
   provide constituency-specific information (the "probability-of-
   occurrence" element, see Section 13.8.1.8, and the "threat" element,
   see Section 13.8.1.9).



Goebel                                                         [Page 50]

                               CAIF Format                 November 2005


   The "constituency" element (Section 13.3.1) can also be used to
   define abstract IT environments.  Such could be a special
   configuration or a widlely used way to deploy affected systems
   (Section 13.10) which is not the recommended way or implies new
   aspects to the threat the problem represents.  Sometimes the problem
   itself is not as critical as it becomes when affecting systems
   deployed in a special way or if the affected systems interact in a
   special way.  In such cases it can be useful to describe the problem
   itself and define the dangereous kind of deployment as an abstract
   constituency.  An issuer then can describe the problem itself and
   provide additional information referring to the abstract
   constituency.

   Synopsis:

           <const ref="IDREF {IDREF}">
            ...
           </const>

   Example:

           <constituency id="StuttgartUniversity">
           ...
           </constituency>
           ...
           <const ref="StuttgartUniversity"> Since the perimeter packet
           filter (PPF) of Stuttgart University blocks ssh connection
           attempts, this problem affects only systems that have an
           exception rule defined in the PPF's ACL.  However, the PPF
           does not inhibit connection attempts from within the
           networks of Stuttgart University.</const>

9.3.5.  The "aff" Markup Element

   The markup element "aff" is intended to provide an internal ID to the
   descriptions that are contained in the "body" (Section 10.4) or the
   "rlist items" (Section 10.5.4) elements within the "affected"
   (Section 13.10), the "not-affected" (Section 13.11), or the
   "possibly-affected" (Section 13.10) elements.  The ID acts as a
   reference target from within the document.  This is useful if the
   issuer wants to provide data for scanners that are capable to
   automatically determine whether systems in a given IT infrastructure
   are vulnerable to the problem(s) described.  The data used by such a
   scanner can be put into the "determine-affectedness" (Section 13.13)
   element that has the OPTIONAL attribute "aff-ref".  This attribute is
   intended to reference one or multiple of the IDs that are provided by
   the "aff" element.  This mechanism then provides the link between the
   definitions of affected systems, versions, as well as patch levels



Goebel                                                         [Page 51]

                               CAIF Format                 November 2005


   and the data fed into the scanner.

   The element also can be used to provide unique IDs to information
   provided in the "solution" (Section 13.17) or "workaround"
   (Section 13.16) elements, thus enable CAIF-processing software to
   automatically provide information about a possible solution.  For
   example, if there is code provided in "determine-affectedness"
   (Section 13.13) that can be used to mechanically determine wether a
   given system is affected (like OVAL code [14]), the careful use of
   the "aff" element within the "solution" element can enable CAIF-
   processing software to combine the results of the OVAL-processing
   software with the appropriate URIs to retrieve the applicable
   patches.  Thus, automatic announcement processing may help to
   facilitate the administration of a system.

   Note, that the attribute "id" is of type ID, thus its value MUST be
   unique within a document.  It is not possible, to use the same ID in
   two occurrences of the "aff" element, e.g. one used to markup text
   within the "affected" element and another in "solution".
   Nevertheless, the element is very useful if used accurately: the
   author can provide one ID to tag some text in the "affected" section
   and another ID to tag an URL pointing to the appropriate patch.  The
   corresponding "detitem" element (Section 13.13.1) then can reference
   both IDs.  If the names for these IDs are chosen carefully it is
   easily possible to read the XML code and understand that they belong
   together (see the example).

   Synopsis:

           <aff id="ID">
            ...
           </aff>

   Example:

           <affected>
             <rlist>
               <rli problem-ref="LSASS">
                 <list style="symbols">
                   <li>
                   <aff id=WXP>Windows XP</aff>
                   </li>
                   <li>
                   <aff id=WXPSP1>Windows XP Service Pack 1</aff>
                   </li>
               </rli>
             </rlist>
           </affected>



Goebel                                                         [Page 52]

                               CAIF Format                 November 2005


           ...
           <determine-affectedness>
             <detitem method="OVAL"
                      aff-ref="WXP WXP-solution"
                      content-type="base64"
                      problem-ref="LSASS">
               <body>
               ...
               </body>
            </detitem>
           <determine-affectedness>
             <detitem method="OVAL"
                      aff-ref="WXPSP1 WXPSP1-solution"
                      content-type="base64"
                      problem-ref="LSASS">
               <body>
               ...
               </body>
            </detitem>
          </determine-affectedness>
          ...
          <solution>
             <rlist>
               <rli problem-ref="LSASS">
                 <list style="symbols">
                   <li>
                     <aff id=WXP-solution>
                       <eref target="http://download.microsoft.com/...">
                         LSASS-Patch for XP
                       </eref>
                     </aff>
                   </li>
                   <li>
                     <aff id=WXPSP1-solution>
                       <eref target="http://download.microsoft.com/...">
                         LSASS-Patch for XP Service Pack 1
                       </eref>
                     </aff>
                   </li>
               </rli>
             </rlist>
          </solution>









Goebel                                                         [Page 53]

                               CAIF Format                 November 2005


9.3.6.  The "update" Element

   In some cases it may be necessary to change passages in an
   announcement sematically, e.g. if it has been issued containing an
   error that the issuer wishes to correct.  In such cases it is useful,
   if the changes made in the document can be traced back.  Of course
   all the changes made can be documented in the "revisions"
   (Section 13.4) element but such documentation within the text itself
   provides more accuracy.

   The markup element "update" allows authors to include new text, mark
   text as no longer valid and finally replace invalid text with new
   text.  The element has the REQUIRED attribute "version" that MUST be
   provided with the version number (see Section 13.4) the update refers
   to, i.e. in which version it has been made.

   Newly included text simply is enclosed in "update" tags whereas text
   that shall be marked as no longer valid is enclosed in update's sub-
   element "invalid".  If the author wants to include new text in the
   document without marking some text as being invalid the "invalid"
   element is omitted.  If there shall only be text marked invalid, the
   "update" element only contains the "invalid" element without any
   extra (new) text.  If text shall be replaced, "update" contains the
   new text whereas its sub-element "invalid" contains the text to be
   replaced.

   Synopsis:

           <update version="n.n">
             [new text]
             [<invalid>
                text to be replaced
              </invalid>]
           </update>

   Examples















Goebel                                                         [Page 54]

                               CAIF Format                 November 2005


   1.  Replacement of text by a new text.  The change is valid from
   version 1.1 on :

           <update version="1.1">
             <p>
             Microsoft Windows Server 2003
             </p>
             <invalid>
               <p>
               Microsoft Windows 3.11
               </p>
             </invalid>
           </update>




   2.  Text that has been newly added in version 1.2:

           <update version="1.2">
             Turning off the <service>ToolTalk</service> service
             is highly recommended.
           </update>



   3.  Text that has been marked "invalid" in version 1.3:

           <update version="1.3">
             <invalid>
             The process logs into <file path="/var/log/SYSLOG"/>
             by default.
             </invalid>
           </update>

















Goebel                                                         [Page 55]

                               CAIF Format                 November 2005


10.  Document Structuring Elements

   CAIF provides several elements to enable authors to structure text.
   Besides increasing the readability with paragraphs (Section 10.1),
   there are tables (Section 10.2) and lists (Section 10.3).  The tables
   are a simplified form of the tables known from HTML, the "list"
   element comprises numbered, un-numbered and bulleted lists.

   On top of that, CAIF documents can contain "referencing lists" (see
   Section 10.5) that attach the list items to references to
   vulnerability IDs like CVE numbers [12] that can be defined by the
   "problems" element (Section 13.8).  This mechanism allows for the
   addressing of more than one problem or issue in a single
   announcement, thus enables distributors (Section 6.7) to produce
   several renderings of a CAIF document each addressing one of the
   issues described in the source document.  Of course it is also
   possible to produce a rendering addressing all the issues at the same
   time - this is what the referencing list is designed for.

   In web presentations, using announcements as a knowledge base, CAIF
   documents could be stored in a database and produce renderings on
   demand, depending on a request by the reader.  If CAIF is used as a
   datastructure for a vulnerability database the "rlist" element can be
   used to group depending vulnerabilities.

10.1.  The Paragraph Element "p"

   The "p" element is similar to the equally named element in HTML; it
   defines a paragraph containing arbitrary markup text.

   Synopsis:

           <p>...</p>

   Example:

           <p>
           This is a paragraph of text.
           </p>

10.2.  The "table" Element and its Sub-Elements "tr" and "td"

   The "table" element is a modified form of the equally named element
   in HTML.  It comprises of an OPTIONAL "p" element (Section 10.1)
   providing a preamble for the table, any number of table rows "tr" and
   an OPTIONAL "p" element, allowing for postambling text.  Each "tr"
   element can contain any numbers of table data "td" elements defining
   the table cells.  The "td" element has the OPTIONAL attributes



Goebel                                                         [Page 56]

                               CAIF Format                 November 2005


   "align" defining the alignment of the content of the cell, and
   "colspan" defining the columns a cell shall span.  It is up to a
   rendering system to apply more formatting, like borders etc., to a
   table.

   Synopsis:

           <table>
            [<p>...</p>]
             <tr>
               <td [align=(right|left|top|bottom|center)]
                   [colspan="..."]
               </td>
               {<td>...</td>}
             </tr>
             {<tr>...</tr>}
            [<p>...</p>]
           </table>

   Example:

           <table>
            <p> A question and its possible answers:</p>
             <tr>
               <td align="center" colspan="3">
                 Want a beer?
               </td>
             <tr>
               <td>yes</td>
               <td>no</td>
               <td>perhaps</td>
              <p> Ask your tummy before you check off. </p>
             </tr>
           </table>

















Goebel                                                         [Page 57]

                               CAIF Format                 November 2005


   A rendering could look like:


            A question and its possible answers:

           +--------------------+
           |    Want a beer?    |
           +-----+----+---------+
           | yes | no | perhaps |
           +-----+----+---------+

            Ask your tummy before you check off.


   Of course, renderings can reflect extra design critera of an issuer.

10.3.  Lists: The "list" Element and its Sub-Element "li"

   The "list" defines a list of various styles.  It contains one or more
   list items "li" that contain the rows of a list. "list" has the
   OPTIONAL attribute "style".  It can have the values "symbols"
   indicating that the list items shall be preceeded by a bullet or
   similar symbol, "numbers" indicating that "list" contains a numbered
   list, and "empty" indicating that the list items do not have a symbol
   or number.  The "list" element has an OPTIONAL "p" element
   (Section 10.1) preceeding the list elements providing a preamble as
   well as an OPTIONAL "p" after the last "li" element for postambling
   text.

   Synopsis:

           <list [style="(symbols|numbers|empty)">
             [<p>...</p>]
             <li>... </li>
            {<li>...</li>}
             [<p>...</p>]
           </list>

   Example:

           <list style="numbers">
             <p>The following list is a "numbered" list:</p>
             <li>This is a list item </li>
             <li>This is another list item</li>
             <p>This was the "numbered" list.</p>
           </list>





Goebel                                                         [Page 58]

                               CAIF Format                 November 2005


   A rendering could look like:

           The following list is a "numbered" list:

            1. This is a list item

            2. This is another list item

           This was the "numbered" list.

10.4.  The "body" element

   The "body" element contains the markup text within a section element
   (Section 8).  Its OPTIONAL "tg-ref" attribute references one or more
   target groups (see Section 13.2.1) the text is written for.

   The OPTIONAL "headline" attribute can be used to provide a target
   group-specific headline to the containing section element.

   Synopsis:

           <body [tg-ref="ID{ ID}"]
                 [headline="..."]>
                ...
           </body>

   Whenever there is no "rlist" (Section 10.5) present within a sections
   element (Section 8) (which occurs, when the announcement describes
   only a single problem or the section's content does not idividually
   refer to one of the multiple problems described in the annoucement)
   the "body" element provides the link to a target group
   (Section 13.2.1) for the the text contained in the section.  If there
   are more target groups to be addressed (including the language, which
   is one of the aspects of a target group) there MAY be more than one
   "body" element present, each addessing one or more target groups.
















Goebel                                                         [Page 59]

                               CAIF Format                 November 2005


   Example:

         <context>
           <body tg-ref="admin-en"
                 headline="What is SNMP?">
                 <protocol>SNMP</protocol> is a protocol to
                 ....
           </body>
           <body tg-ref="admin-de"
                 headline="Was ist SNMP?">
                 <protocol>SNMP</protocol> ist ein Protokoll zur
                 ....
           </body>
         </context>

10.5.  The Refencing List "rlist"

   The "rlist" element describes a "referencing list".  It contains one
   or more "referencing list items" ("rlist" see Section 10.5.4).

   It has an OPTIONAL "headline" attribute that can be used to provide a
   headline string to the containing element (Section 13) defining a
   section of an announcement (Section 8) according to the target group
   (Section 13.2) (see the "tg-ref" attribute below) the content of the
   rlist is written for.  An "rlist" MAY reference more than one target
   group.

   "rlist" has the OPTIONAL attribute "style" (Section 10.5.3) which
   defines the look of the list items.  Like the equally named attribute
   of "list".

   The "rlist" element contains an OPTIONAL "p" element (Section 10.1)
   preceeding the list elements providing a preamble to the rlist items
   as well as an OPTIONAL "p" after the last "rli" element for
   postambling text.

   Synopsis:

           <rlist [tg-ref="ID{ ID}"]
                  [headline="..."]
                  [style="(numbers|symbols|ref-text|empty)"]>
               [<p>...</p>]
               <rli>...</rli>
               {<rli>...</rli>}
               [<p>...</p>]
           </rlist>





Goebel                                                         [Page 60]

                               CAIF Format                 November 2005


10.5.1.  The "tg-ref" Attribute of "rlist"

   Sometimes it is important to issue an announcement to more than one
   target group of readers.  For this purpose, "rlist" provides the
   OPTIONAL attribute "tg-ref" that references to one or more "target-
   group" elements (see Section 13.2.1) that define the language the
   text is written in, the technical background and the organizational
   overview the intended reader has, as well as the environment the
   described problem occurs in (see also Section 5.3).

10.5.2.  The "headline" Attribute of "rlist"

   If a section element (Section 13) contains more than one "rlist" to
   provide its content in several languages or target groups, an issuer
   might want to provide the section headline in several languages as
   well.  For this purpose, the "rlist" element has an OPTIONAL
   attribute "headline".

10.5.3.  The "style"  Attribute of "rlist"

   "rlist" has the OPTIONAL attribute "style" which defines the look of
   the list items.  Like the equally named attribute of "list" "style"
   MAY have the values "numbers", "symbols", and "empty" with the same
   meanings (see Section 10.3).  The default value, that applies if the
   attribute is not present, is "numbers".  There is an extra value
   "ref-text" that indicates that the value of the problem reference(s)
   (Section 13.8) the attribute "problem-ref" of the sub-element "rli"
   (Section 10.5.4) points to, shall be used as the bullet symbol of the
   list item in a rendering.

10.5.4.  The "rli" Element - Sub-Element to "rlist"

   The "rli" element defines a list item of a referencing list "rlist",
   similar to the list item "li" (Section 10.3).  By the value(s) of the
   OPTIONAL attribute "problem-ref" a rlist item can reference one or
   more problem elements (Section 13.8.1), that identify the problems
   described by the announcement uniquely.  This reference provides the
   tool to describe more than one issue within one announcement, e.g. a
   cumulative patch announcement.  Each of the elements defining one of
   the main sections (Section 8) of a CAIF announcement contains one or
   multiple "rlist" elements in which the "rlist items" ("rli") contain
   information on the section's aspects referring to one or more
   "problem" elements.  An announcement describing more than one
   problem, can be rendered into several announcement renderings each
   describing a single problem or a sub-set of the problems if the
   references are set properly.

   A rlist item MAY contain arbitrary markup text including all



Goebel                                                         [Page 61]

                               CAIF Format                 November 2005


   structuring markup elements, except the "rlist" element, i.e. rlists
   cannot be used recursively.

   Synopsis:

           <rli problem-ref="ID{,ID}">
             ...
           </rli>

   Example:

           <affected>
              <rlist style="ref-text"
                     tg-ref="admin-en"
                     headline="Affected Systems">
                 <rli problem-ref="CAN-2004-0847">
                   <list style="symbols">
                     <li>Windows 2000 Service Pack 3 and Service
                                                     Pack 4</li>
                     <li>Windows XP Service Pack 1 and Service
                                                     Pack 2</li>
                     <li>Windows Server 2003</li>
                     <li>Windows XP Tablet PC Edition</li>
                     <li>Windows XP Media Center Edition</li>
                   </list>
                 </rli>
                 <rli problem-ref="CAN-2005-0049">
                   <list style="symbols">
                     <li>Windows Server 2003 for Itanium</li>
                     <li>SharePoint Portal Server 2003</li>
                     <li>SharePoint Portal Server 2001</li>
                   </list>
                 </rli>
              </rlist>
           </affected>
















Goebel                                                         [Page 62]

                               CAIF Format                 November 2005


   A rendering could look like:

           Affected Systems
           ================
            CAN-2004-0847:
             o Windows 2000 Service Pack 3 and Service Pack 4
             o Windows XP Service Pack 1 and Service Pack 2
             o Windows Server 2003
             o Windows XP Tablet PC Edition
             o Windows XP Media Center Edition

            CAN-2005-0049:
             o Windows Server 2003 for Itanium
             o SharePoint Portal Server 2003
             o SharePoint Portal Server 2001


10.5.5.  An "rlist"-Example

   To illustrate the sophisticated structure of the referencing list the
   following example demonstrates its use within the "exploit" element
   (Section 13.8.1.6).

         <context>
           <rlist tg-ref="admin-employee-en"
                  headline="Technical Context"
                  style="ref-text">
             <p>
             This section provides information about the systems that
             are affected by the problems described as well as their
             purpose.
             </p>
             <rli problem-ref="CAN-2004-0597 CAN-2004-1244">
             The routines to process PNG image files are used by
             various applications that are displaying images.  Besides
             several image viewers the routines are used by the
             Internet Explorer too.
             </rli>
             <rli problem-ref="CAN-2005-0057">
             The <em>Hyperlink Object Library</em> is used by various
             applications to process hyperlinks.
             </rli>
           </rlist>
           <rlist tg-ref="admin-employee-de"
                  headline="Technischer Kontext"
                  style="ref-text">
             <p>
             Dieser Abschnitt ent&auml;lt Information zum technischen



Goebel                                                         [Page 63]

                               CAIF Format                 November 2005


             Kontext in denen die betroffenen Systeme eingesetzt
             werden.
             </p>
             <rli problem-ref="CAN-2004-0597 CAN-2004-1244">
             Die Routinen zur Verarbeitng von PNG-Dateien werden von
             verschiedenen Applikationen benutzt, die Bilder
             verarbeiten oder darstellen.  Dies ist neben verschiedenen
             Bildbetrachtungsprogrammen auch der Internet Explorer.
             </rli>
             <rli problem-ref="CAN-2005-0057">
             Die Routinen zur Verarbeitung von Hyperlinks werden von
             verschiedenen Applikationen verwendet, die Hyperlinks
             verarbeiten m&uuml;ssen.  Dies ist u.a. der Internet
             Exporer.
             </rli>
           </rlist>
           <rlist tg-ref="user-employee-en"
                  headline="Technical Kontext"
                  style="numbers">
             <p>
             This section provides information about the programs that
             contain the problem.  It is intended to help you
             understand, in which technical context these programs can
             be found, and decide whether you use them or not.
             </p>
             <rli problem-ref="CAN-2004-0597 CAN-2004-1244">
             The routines to process PNG image files are used by
             applications that are displaying and processing images.
             First of all this is the Internet Explorer, but also other
             programs like image viewers.  PNG is a special image file
             format, that is often used in web pages.
             </rli>
             <rli problem-ref="CAN-2005-0057">
             Hyperlinks are used to provide references in documents
             that interactively can be used to interlink documents.
             Several Programs in Microsoft Operating Systems provide
             the possibility to browse through documents using
             so-called <em>hyperlinks</em>.  The most popular
             application is the Internet Explorer processing html
             documents that interlink with hyperlinks.
             </rli>
           </rlist>
           <rlist tg-ref="user-employee-en"
                  headline="Technisches Umfeld"
                  style="numbers">
             <p>
             Dieser Abschnitt stellt Information &uuml;ber das
             technische Umfeld bereit, in dem die jeweiligen



Goebel                                                         [Page 64]

                               CAIF Format                 November 2005


             Schwachstellen auftreten.
             </p>
             <rli problem-ref="CAN-2004-0597 CAN-2004-1244">
             Verschiedene Programme, die Bilder darstellen oder
             verarbeiten, verwenden Funktionen, die zentral bereit
             gestellt werden.  Eine dieser zentral bereitgestellten
             Funktionen ist die Funktionsbibliothek zur verarbeitung
             sog. PNG-Bilder.  PNG ist ein besonderes Format, das
             h&auml;ufig auf Webseiten verwendet wird.
             </rli>
             <rli problem-ref="CAN-2005-0057">
             <p>
             Hyperlinks sind Querverweise, die in Dokumenten
             verschiedener Formate verwendet werden k&ouml;nnen, um
             Referenzen innerhalb oder au&szlig;erhalb des Dokumentes
             zu setzen.  Diverse Programme sind in der Lage, diese
             Referenzen zu verarbeiten.  Bekanntester Vertreter ist der
             Internet Explorer.
             </p>
             <p>
             Die Routinen zur Verarbeitung von Hyperlinks werden
             zentral bereitgestelly um von den verschiedenen
             Applikationen verwendet werden zu k&ouml;nnen.
             </p>
             </rli>
           </rlist>

























Goebel                                                         [Page 65]

                               CAIF Format                 November 2005


11.  The Announcement: The Top-Level-Element "caif"

   The "caif" element is the top-level element of an announcement,
   enclosing the complete CAIF document.  Its start tag immediately
   follows the XML declarations and its end tag is the final string in a
   document.  This element is REQUIRED in an announcement.

   Synopsis:

      XML-Declarations
      <caif>
        <identification>...</identification>
        {<target-groups>...</target-groups>}
        {<constituencies>...</constituencies>}
        <revisions>...</revisions>
        <category>...</category>
        <subject>...</subject>
        <summary>...</summary>
        [<problems>...</problems>]
        [<affected>...</affected>]
        [<not-affected>...</not-affected>]
        [<possibly-affected>...</possibly-affected>]
        [<determine-affectedness>...</determine-affectedness>]
        [<mitigation>...</mitigation>]
        [<context>...</context>]
        [<description>...</description>]
        [<workaround>...</workaround>]
        [<solution>...</solution>]
        {<arbitrary>...</arbitrary>}
        [<bibliography>...</bibliography>]
        [<credits>...</credits>]
        [<disclaimer>...</disclaimer>]
        [<other-documents>...</other-documents>]
        [<rendered-copies>...</rendered-copies>]
      </caif>

   Example:

        <?xml version="1.0" encoding="ISO-8859-1"?>
        <!DOCTYPE caif  SYSTEM "-//DTD Common Announcement
        Interchange Format//EN"
        "http://www.caif.info/dtd/caif.dtd">

        <caif>

          ...the document...

        </caif>



Goebel                                                         [Page 66]

                               CAIF Format                 November 2005


12.  REQUIRED Elements in a CAIF Announcement

   As one can see in the synopsis for the syntax of the "caif" element
   (Section 11), the following elements (Section 13) are REQUIRED in an
   announcements:

   o  "identification" (Section 13.1)

   o  "revisions" (Section 13.4)

   o  "category" (Section 13.5)

   o  "subject" (Section 13.6)

   o  "summary" (Section 13.7)

   including their sub-elements.

   This very small set of mandatory elements provides a maximum of
   flexibility when using CAIF as the format of choice for arbitrary
   announcements or as a structure for databases.






























Goebel                                                         [Page 67]

                               CAIF Format                 November 2005


13.  The Elements Defining the Main Sections

   This section describes all the elements the CAIF DTD provides; the
   syntax and the purpose are explained.  It is a preamble to the DTD in
   Appendix C.

13.1.  The "identification" Element and its Sub-Elements

   The "identification" element contains several other elements that
   provide information to uniquely identify the document.  It does not
   enclose any text.

   The REQUIRED "issuer" element (Section 13.1.1) contains information
   about the issuer of the announcement, the REQUIRED "announcement"
   element (Section 13.1.2) provides a unique id to identify the
   document, and the "type" element (Section 13.1.3) categorizes the
   various aspects of the type of the announcement.

   The OPTIONAL "author" element (Section 13.1.4) contains name,
   initials, and e-mail address of the author.  Since an announcement
   may have more than one author, this element MAY occur multiple times.

   The empty element "distribution-allowed" defines to which
   constituences (Section 13.3.1) the annoucement may be distributed.
   Its "const-ref" attribute contains the IDs that identify these
   cosntituencies.  The element "earliest-release" contains a string
   describing the date before an announcement should not be published.
   It can be used in different ways according a local policy.

   Overall Synopsis:

           <identification>
             <issuer>...</issuer>
             <announcement>...</announcement>
             <type>...</type>
             <author>...</author>
             {<author>...</author>}
             [<distribution-allowed/>]
             [<earliest-release>...</earliest-release>]
           </identification>

   The sub-elements to "identification"

   The element "identification" is REQUIRED in a CAIF announcement.

13.1.1.  The "issuer" Element

   The "issuer" element contains the name of the issuer of the



Goebel                                                         [Page 68]

                               CAIF Format                 November 2005


   announcement (Section 6.4).  The element has a REQUIRED attribute
   "id" which MUST have the unique id of the issuer as its value.  A
   good coice for such an id is the abbreviation of the issuing
   organization.  It is not in the scope of this document to provide a
   system or repository for unique issuer ids.  The Forum of Incident
   Response and Security Teams (FIRST [10]) provides a database
   containig their member organisations, thus would make a good source
   of such ids.  This element is REQUIRED in a CAIF announcement.

   Synopsis:

           <issuer id="ID">
             Name of the issuer
           </issuer>

   Example:

           <issuer id="RUS-CERT">
             Stuttgart University Computer Emergency Response Team
           </issuer>

   The "issuer" element is a sub-element to "identification".  It MUST
   NOT occur multiple times within its superior element.

13.1.2.  The "announcement" Element

   This is an empty element identifying the announcement by a number or
   string unique to the issuers own announcement identification system.
   Such could be a simple number or a complex id composed from varoious
   data important to the issuer.  This element is REQUIRED to a CAIF
   announcement.

   Synopsis:

           <announcement id="ID"/>

   Example:

           <announcement id="1155"/>

   Processing software MAY combine the "issuer" and the "announcement"
   to a string that identifies the announcement uniquely to the world,
   e.g.  "RUS-CERT-Announcement#1155".  The reason to provide two
   elements for this purpose is the fact that no uniform identification
   scheme for announcements has evolved yet.  Providing the mechanism
   described above, CAIF allows to flexibly achieve this necessary
   requirement without forcing an issuer to adapt to a specific scheme.




Goebel                                                         [Page 69]

                               CAIF Format                 November 2005


   The "announcement" element is a sub-element to "identification".  It
   MUST NOT occur multiple times within its superior element.

13.1.3.  The "type" Element

   This element classifies the announcement.  It has three pre-defined
   attributes to describe some main aspects of the document: "urgency",
   "level", and "flavor".

   Depending on the problem the announcement addresses, its "urgency"
   attribute describes the urgency to take action to solve the problem
   or mitigate it.

   "alert" -- The announcement provides information about an issue that
      imposes an immediate and severe threat upon affected
      infrastructure and requires immediate action by operators of such.
      It also provides information about the - possibly temporary -
      solution of the causing problem, i.e. at least a workaround
      (Section 13.16) SHOULD be supplied.

   "warning" -- The announcement provides information about an issue
      that imposes a potentially severe threat on affected
      infrastructure and requires early action by operators of such.  It
      also provides information about the - possibly temporary -
      solution of the causing problem.

   "advisory" -- The announcement provides information about an issue
      that imposes a potential threat upon affected infrastructure and
      advises action to operators of such.  Such could be a theoretical
      problem which is hard to exploit and therefore does not impose an
      acute threat.  Note that this state may change over time.  The
      announcement also provides information about the - possibly
      temporary - solution of the causing problem.

   "informational" -- The announcement provides background or general
      information about a security issue.  For example such could be a
      background article about a structural problem of a technical
      system or procedure or the effects of a specific policy.

   The attribute "level" describes the quality of the information
   provided by the announcement in terms of its particularity.  It has
   the following pre-defined values:

   "brief" -- The announcement provides brief information about a
      security issue.  Usually such a document is no fully qualified
      announcement but rather a short description of an issue
      accompanied by references to documents describing the issue in
      greater detail.  However, the required (Section 12) elements have



Goebel                                                         [Page 70]

                               CAIF Format                 November 2005


      to be present in such an document.  If an announcement is "brief"
      the "summary" (Section 13.7) SHOULD be more exhaustive than in an
      annoucement of the other levels, and then MAY replace the
      "description" element (Section 13.15).  This level also can be
      used, if CAIF is used as a datastructure in a "vulnerability
      database".  An entry of such a database at least has the minimum
      set of the REQUIRED elements (Section 13) and can be used as a
      basis for a fully featured announcement.  Note, that a database
      containing CAIF announcements describing vulnerabilities is a
      vulnerability database as a side effect.

   "full" -- The announcement is a fully qualified CAIF document,
      providing all or a substantial sub-set of the informative sections
      (Section 8).

   "digest" -- The announcement provides information about more than one
      issue.  Usually such documents are issued to announce cumulative
      patches or a patch cluster.

   "other" -- The announcement's quality does not fit into one of the
      above categories.  This is the default value if the attribute is
      not present.

   In a reissue (Section 13.4.2) of a document, an announcement can
   change its urgency as well as its level if appropriate. e.g. an
   "advisory" that has addressed a problem in "brief" can be converted
   into a fully featured announcement and be made an "alert" if
   necessary.

   The attribute "flavor" describes the quality of the announcement in
   terms of the solution available.  It has the following pre-defined
   values:

   "vulnerability-description" -- The announcement mainly provides
      information about a problem but no patch from the vendor of the
      affected product.  It rather provides information about one or
      more workarounds or temporary solutions.  Such announcements
      eventually can be followed by a patch announcement (see next
      bullet) which provides a final solution to the problem.

   "patch-notification" -- The announcement provides information about
      the problem and its final solution.  Such could be a patch or a
      new release of the affected product.  A special configuration or
      the termination of an affected service does not qualify as a
      "patch-notification".






Goebel                                                         [Page 71]

                               CAIF Format                 November 2005


   "heads-up" -- The announcement is neither describing a known
      vulnerability nor a patch but rather a an issue that requires the
      reader to raise attention on some special activity or
      circumstances.  Such an issue could be the suspicion that there is
      a yet unknown vulnerability raised for example by scans that
      cannot be attached to a known prablem that the scanner might want
      to exploit.  Hence, readers should put their "heads up" to watch
      out for these scans and try to find out what it is all about.

   "other" -- All announcements that do not match one of the flavors
      described above.  This is the default value if the attribute is
      not present.

   Besides the attributes, the element MAY contain a textual description
   of the type within one or more "body" elements (Section 10.4) that
   also provide a title string depending on the target group
   (Section 13.2.1) they refer to.

   Synopsis:

           <type
           [urgency="(alert|warning|advisory|informational")]
           [level="(brief|digest|other)"]
           [flavor="(vulnerability-description|
                            patch-notification|
                            other)"]>
             <body
               ...
             </body>
             {<body
               ...
             </body>}
           </type>

   Example:

           <type urgency="warning"
                 level="digest"
                 flavor="patch-notification">
             <body headline="Type of the Announcement"
                   tg-ref="en-admin">
               Cumulative Patch Announcement
             </body>
             <body headline="Typ der Meldung" tg-ref="de-admin">
               Sammelpatchmeldung
             </body>
           </type>




Goebel                                                         [Page 72]

                               CAIF Format                 November 2005


   The "type" element is a sub-element to "identification" and MAY
   contain markup text.  The element is REQUIRED in a CAIF announcement
   and MUST occur a single time within its superior element.  The
   attributes MAY be omitted in order to provide the pre-defined values
   "other" for "level" and "flavor".  Note, that there is no pre-defined
   value for the "urgency" attribute.  In case of this it is recommended
   to provide a textual description in the element.  This makes a basic
   classification of the document possible.

13.1.4.  The "author" Element

   The "author" element identifies an author of the announcement.  Since
   an announcement can have more than one author, the element MAY be
   present multiple times.  It has three OPTIONAL attributes:

   "initials" - This attribute contains the grammalogue of the fullname
      of the author.

   "name" - This attribute contains the full name of the author
      including all titles.

   "e-mail" - This attribute contains an e-mail URI or e-mail address.

   Synopsis:

           <author
             [initials="..."]
             [name="..."]
             [e-mail="..."]>
             ...
           </author>

   Example:

           <author initials="og"
                   name="Dipl.-Inform. Oliver Goebel"
                   e-mail="mailto:goebel@caif.info">
             Oliver Goebel
           </author>

   The "author" element is a sub-element to "identification".  It can
   only occur within its superior element.

13.1.5.  The "distribution-allowed" Element

   The OPTIONAL empty element "distribution-allowed" is intended to
   define to whom an annoucement may be distributed.  Some issuers may
   not want that renderings or the XML-source of an announcement is



Goebel                                                         [Page 73]

                               CAIF Format                 November 2005


   given to outsiders.  Hence the intention of the issuer MUST be
   declared to processing software and people handling the document.

   The REQUIRED attribute "const-ref" contains the IDs of the
   constituencies (Section 13.3.1) to which the distribution of the
   announcement is allowed.

   If "distribution-allowed" is not present in an announcement, no
   restrictions apply to its distribution.

   Synopsis:

           <distribution-allowed const-ref="IDREF {IDREF}"/>

   Example:

           <distribution-allowed
                    const-ref="StuttgartUniversity example.com"/>

   The "distribution-allowed" element is a sub-element to
   "identification".  It can only occur within its superior element.

13.1.6.  The "earliest-release" Element

   The element "earliest-release" contains a string describing the date
   before an announcement should not be published.  It can be used in
   different ways according a local policy.  For example, if the issuer
   is member of a community that is producing announcement co-
   operatively, the element can be used to keep the document from being
   released into the public early when it is shared within the
   community.  It SHOULD be interpreted by processing software.

   The element has an attribute "date" that contains the date in ISO
   format.  The element MAY contain non-markup text for additional
   explanation.

   Synopsis:

           <earliest-release date="YYYY-MM-DD [hh:mm:ss(+|-)hh]">
           ...
           </earliest-release>

   Example:

           <earliest-release date="2004-10-21">
           The vendor will release a patch on 2004-10-21.
           </earliest-release>




Goebel                                                         [Page 74]

                               CAIF Format                 November 2005


13.1.7.  The Overall Syntax and an Overall Example for the
         "identification" Element

   Containing all its sub-elements the element "identification" has the
   following syntax:

   Overall Synopsis:

           <identification>
             <issuer>...</issuer>
             <announcement>...</announcement>
             <type>...</type>
             <author>...</author>
             {<author>...</author>}
             [<distribution-allowd const-ref="IDREF {IDREF}">]
             [<earliest-release>...</earliest-release>]
           </identification>

   The following example illustrates the syntax of the "identification"
   element and its sub-elements.

   Overall example:

           <identification>
             <issuer id="RUS-CERT">
               Stuttgart University Computer Emergency Response Team
             </issuer>
             <announcement id=1155/>
             <type level="digest" flavor="patch-notification">
               Cumulative Patch Announcement
             </type>
             <author initials="og"
                     name="Oliver Goebel"
                     e-mail="mailto:Goebel@CERT.Uni-Stuttgart.DE">
               Oliver Goebel, RUS-CERT, Stuttgart University
             </author>
             <distribution-allowed
                     const-ref="StuttgartUniversity example.com"/>
           </identification>

13.2.  The "target-groups" Element

   The "target-groups" element contains one or more "target-group"
   elements each providing the reference data for a specific target
   group of readers.  The "target-groups" element does not contain any
   textual descriptions or attributes.

   This element is OPTIONAL in an announcement



Goebel                                                         [Page 75]

                               CAIF Format                 November 2005


   Synopsis:

           <target-groups>
             <target-group>
             ...
             </target-group>
            {<target-group>
             ...
             </target-group>}
           </target-groups>

13.2.1.  The "target-group" Element

   The "target-group" element contains information about the target
   group of readers the announcement addresses.

   It contains markup text and is intended to provide an answer to the
   question "Who should read this document?".  The answer SHOULD be
   verbose in order to give an explanation or extension to the value of
   the OPTIONAL "tech-background", "orga-overview", and "environment"
   attributes (see below).

   The "target-group" element is a sub-element to "target-groups" and
   MUST NOT occur outside its superior element.

13.2.1.1.  The Attributes of the element "target-group"

   The element "target-group" features the following attributes:

   "id" -- Each "target-group" element has a REQUIRED "id" attribute
      that provides a unique identifier for the target group.  It is
      recommended to use self-explanatory values for this attribute
      which reflect all the aspects (provided by the other attributes)
      like the language, the technical background, and the environment.
      Such a name could be a value like 'en-admin-mgmt-PMS' indicating
      that the referenced target group are members of the middle
      management having an system administrative technical background.
      It also indicates, that the textual descriptions given in the
      referencing "body" (Section 10.4) and "rlist" (Section 10.5)
      elements within the sections (Section 8) of the announcement
      provide information on the problems within the context of the
      'PMS' (Personnel Management System see example below) software
      suite.

   "lang" -- The REQUIRED attribute "lang" contains a two-letter
      language code to identify the language of the target group.





Goebel                                                         [Page 76]

                               CAIF Format                 November 2005


   "tech-background" -- The attribute "tech-background" categorizes the
      assumed technical abilities of the members of the target group.
      When writing contents in an announcement this is an important
      aspect.  For example, if it comes to applying a workaround
      (Section 8.13) it is essential to provide enough information to
      the reader so that she is able to execute the necessary steps.
      Usually a system administrator who is familiar with the affected
      system needs less or differently detailed information than an
      ordinary user.  The "tech-background" attribute may have the
      following values:

      *  "admin"

      *  "user"

      *  "developer"

      The value "admin" indicates that the reader has an average
      technical knowledge of a system administrator.  This is the
      default value if the attribute is omitted.  The value "user"
      indicates that the reader only has technical knowledge and
      abilities of a user of the affected system(s).  Finally the value
      "developer" indicates that the reader has the profund technical
      background knowledge of a system developer.

   "orga-overview" -- The "orga-overview" attribute provides information
      on the organizational overview a member of the intended target
      group has within the organization an affected system is used.  An
      normal employee usually has less organizational overview than a
      member of the management, thus the information given within
      sections to the latter probably differs from the bare technical
      facts.  For example: if a system is affected that is vital for
      web-based sales, a manager responsible for sales might want to
      know how the problem described in an announcement affects the web-
      services essential for his scope of responsibility.  The "orga-
      overview" attribute may have the following values:

      *  "employee"

      *  "middle-management"

      *  "senior-management"

   "environment" -- The value of the "environment" attribute indicates
      the context in which the affected system is used.  For example the
      context could be a software suite like a personnel management
      system (PMS) in which the affected ware is a component.  Such
      could be an application like a web-server or the underlying



Goebel                                                         [Page 77]

                               CAIF Format                 November 2005


      operating system that is certified for a special version and
      patch-level by the manufacturer of the suite.  In many cases it is
      a hard job for the administrator of the suite or the hosting
      computer system(s) to decide whether the countermeasures described
      in an announcement can be applied and which effects they may have
      on the suite.  Defining a target group having this aspect allows
      issuers to provide such information.  There are no pre-defined
      values for "environment".

   "headline" -- a headline string to the "target-group" can be defined
      in the OPTIONAL "headline" attribute.

   The "target-groups" element and its "target-group" sub-elements have
   a similar architecture like the "problems" element (Section 13.8) and
   its "problem" (Section 13.8.1) sub-elements.  Like "problem" the
   element "target-group" provides all necessary information about a
   target group as well as an ID that may be referenced from within the
   several sections (Section 8) of the announcement.  The information is
   being provided in a normalized way.

   Synopsis:

           <target-group id="ID"
                         lang="LANG_CODE"
                         [tech-background="(admin|user|developer)]"
                         [orga-overview="(employee|
                                         middle-management|
                                         senior-management)]
                         [environment="..."]
                         [headline="..."]>
           ...
           </target-group>

   Example:

           <target-group id="en-admin-mgmt-PMS"
                         lang="en"
                         tech-background="admin"
                         orga-overview="middle-management"
                         environment="PMS"
                         headline="Who should Read this Document">
              Members of the middle-management with system administrator
              background responsible for running the PMS Personnel
              Management System should read this document.
           </target-group>






Goebel                                                         [Page 78]

                               CAIF Format                 November 2005


13.3.  The "constituencies" Element

   The OPTIONAL "constituencies" element implements the "constituency"
   section (Section 8.3).  It contains one or more "constituency"
   elements (see below: Section 13.3.1) that actually describe the
   different constituencies (Section 6.8) to which the several
   constituency-specific elements refer (Section 9.3.4,
   Section 13.8.1.8, Section 13.8.1.9).  The "constituencies" element
   contains no text.

   Synopsis:

           <constituencies>
             <constituency>
               ...
             </constituency>
             {<constituency>
               ...
             </constituency>}
           </constituencies>

13.3.1.  The "constituency" element

   The "constituency" element is the only sub-element of
   "constituencies" (Section 13.3)

   The element is intended to contain the description of a specific
   constituency.  A constituency is a concrete IT infrastructure and its
   users.  If issuers produce announcements for more than one
   constituency or if their overall constituency MUST be split up into
   several parts these entities can be described in seperate
   "constituency" elements.  The element has the REQUIRED "id" attribute
   that uniquely identifies the constituency described to the document.
   This id can be used by the markup element "const" (Section 9.3.4) as
   well as the elements "probability-of-occurrence" (Section 13.8.1.8)
   and "threat" (Section 13.8.1.9) to refer to a specific constituency
   (Section 6.8), as their content is intentionally constituency-
   specific.  Since the "const" element MAY occur in every place that
   allows markup text, it is possible to add constituency-specific
   information to almost all sections that provide some content for
   readers.  The constituency specific contents may be removed before an
   announcement is interchanged if the issuer does not want them to be
   distributed.

   In some cases it may be useful to define abstract constituencies that
   have several technical characteristics like enabled features of
   affected systems (Section 8.8).  The "const" markup then can be used
   to enclose text passages that reference to the specific



Goebel                                                         [Page 79]

                               CAIF Format                 November 2005


   characteristics.

   The description of the IT infrastructure and its users is provided by
   one or more "body" elements (Section 10.4) specifically to the target
   group (Section 13.2.1) that is referenced by its "tg-ref" attribute.
   If the announcement is multi-lingual or addresses more than one
   target group, the "body" element MAY occur multiple times in
   "constituency" with different values for its "tg-ref" attribute.

   Synopsis:

           <constituency id="ID">
             <body>
               ...
             </body>
             {<body>
               ...
             </body>}
           </constituency>

   Example:

           <constituency id="StuttgartUniversity">
             <body tg-ref="en-admin en-user">
              The Constituency of Stuttgart University compriises all
              computer systems within the network segments
              129.69.0.0./24, 141.58.0.0./24, ...
             </body>
           </constituency>
           <constituency id="Windows Domain">
             <body tg-ref="en-admin en-user">
             This abstract constituency describes a standard
             installation of a Microsoft domain. The configuration
             has the following characteristics: ...
             </body>
           </constituency>

13.4.  The "revision" Element

   The "revisions" element too is a meta element that contains several
   sub-elements providing a history of the revisions and possible re-
   issues of the announcement.  CAIF distiguishes between two forms of
   version changes of an announcement, the revision and the re-issue.
   While a revision is a change that does not alter the main aspects of
   an announcement in terms of risk or threat that would require a
   renewed emission of the document to the constituency (Section 6.8)
   including the information on the changed quality of the problem
   described in it, a re-issue of the document is exactly such a change



Goebel                                                         [Page 80]

                               CAIF Format                 November 2005


   thus requiring the re-emission (re-issuing) of the document.

   This element has an OPTIONAL "body" element (Section 10.4) that
   provides a title string to the section definded by "revisions".  If
   the announcement is multi-lingual or addresses more than one target
   group, the "body" element MAY occur several times in "revisions" with
   different values for its "tg-ref" attribute.  The different instances
   of "body" contain the target group-specific title strings and textual
   descriptions for the whole section.

   Besides the OPTIONAL "body" elements "revisons" has three more sub-
   elements: the REQUIRED "issued" element providing the data of the
   initial issue of the document, one or more "re-issued" elements
   providing information on eventual re-issuings and "revision"
   providing the data of revisions of the announcement.

   Synopsis:

           <revisions>
             {<body>...</body>}
             <issued>...</issued>
             {<re-issued>...</re-issued>}
             {<revision>...</revision>}
           </revisions>

   The element "revisions" and its sub-elements

   The "update" markup element (Section 9.3.6 can be used to markup
   changes within the document.  Its "version" attribute references to
   the value of the "version" attribute of one of the element's "re-
   issued" or "revision" sub-elements.

13.4.1.  The "issued" Element

   The empty element "issued" identifies the date and version of the
   first issue of the announcement.  The element has two attributes
   "date" and "version" to provide this data:

   date -- The date SHALL have ISO format: YYYY-MM-DD {hh:mm:ss[+|-]hh}.

   version -- The version SHALL be noted in a two-part number separated
      by a dot.  Since the first part of the version number refers to
      the issue, this is usually a '1'.  The second figure refers to the
      "revision" (Section 13.4.3) of the announcement, usually a '0' in
      the initial issue.  Consequently the attribute "version" usually
      has the value "1.0".





Goebel                                                         [Page 81]

                               CAIF Format                 November 2005


   Synopsis:

           <issued version="1.0" date="YYYY-MM-DD [hh:mm:ss(+|-)hh]"/>

   Example:

           <issued version="1.0" date="2003-10-20"/>

   The "issued" element is a sub-element to "revisions".  It MUST NOT
   occur multiple times within its superior element.

13.4.2.  The "re-issued" Element

   The element "re-issued" is introduced into an announcement, if the
   document has to be re-issued because some important aspects of the
   problem described have been subject to major changes.  Such could be
   a re-estimation of the threat imposed by the problem or the
   publiation of exploit code.

   The element is very similar to the element "issued" (Section 13.4.1),
   it too has the attributes "version" and "date" as well as a third
   attribute "reason" with a set of pre-defined values:

   "exploit" -- This "reason" documents the publication of exploit code
      (Section 13.8.1.6).  If the problem described in the announcement
      has a more theoretical nature, the publication of working expoit
      code is a major change of the situation and indicates a re-issue
      of the announcement.

   "risk" -- This value is provided if the estimation of the risk
      potential of the problem described has changed.

   "patch" -- "reason" has the value "patch" if an announcement is re-
      issued because a patch for the - usually highly threatening -
      problem described has been published.

   "other" -- All other reasons.  Details SHOULD be given in the text
      part of the element.

   Each re-issuing of the announcement MUST result in an increment of
   the first figure of the version number of the attribute "version",
   e.g. the first re-issue has the version number "2.0" the second "3.0"
   and so on.  The second figure indicates the revision (Section 13.4.3)
   of the announcement.

   The element is not empty, it SHOULD contain information about the
   changes that have been made since the last issue as well as details
   about the reason for the re-issuing.  This content as well a title



Goebel                                                         [Page 82]

                               CAIF Format                 November 2005


   string to the sub-section defined by "re-issued" is provided target
   group-specificly by one or more "body" (Section 10.4) elements.

   Synopsis:

           <re-issued version="n.n"
                      date="YYYY-MM-DD [hh:mm:ss(+|-)hh]"
                      [reason="(exploit|risk|patch|other)"]>
             <body>
             ...
             </body>
           </re-issued>

   Example:

           <re-issued version="2.0"
                      date="2003-10-25 13:17:23+02"
                      reason="exploit">
             <body tg-ref="en-admin-employee">
             Exploit code has been published.
             </body>
           </re-issued>

   Note, that the "headline" attribute if the "body" element is
   OPTIONAL.

   The "re-issued" element is a sub-element to "revisions".  It can only
   occur within its superior element.  Each re-issuing of the
   announcement is documented in an own instance of this element.

13.4.3.  The "revision" Element

   The element "revision" documents the date and changes made in an
   announcement done in a revision.  A revision does not change the main
   qualities of the annoucement in a way that a reissue becomes
   necessary.

   The element has two attributes "date" and "version" to provide this
   data:

   date -- The date SHALL have ISO format: YYYY-MM-DD {hh:mm:ss[+|-]hh}.

   version -- The version SHALL be noted in a two-part number separated
      by a dot.  The first figure of the version number refers to the
      "issue" (Section 13.4.1) of the announcement.  A revision changes
      the second figure of the version number, subsequent to the first
      figure which is changed whenever the announcement is re-issued
      (Section 13.4.2).  In this event the second figure is reset to



Goebel                                                         [Page 83]

                               CAIF Format                 November 2005


      zero.

   The changes that have been made since the last revision or issue as
   well as details about the reason for the revision as well as an
   OPTIONAL title string to the sub-section is given within one or more
   "body" elements (Section 10.4).  Each of these "body" elements refer
   to a specific target group and its aspects.

   Synopsis:

           <revision version="n.n"
                     date="YYYY-MM-DD [hh:mm:ss(+|-)hh]">
             <body>
              ...
             </body>
           </revision>

   Example:

           <revision version="1.1" date="2003-10-22">
             <body>
             Reference to background article added
             </body>
           </revision>

   Note that the "tg-ref" attribute of the "body" element is OPTIONAL.

   The "revision" element is a sub-element to "revisions".  It can only
   occur within its superior element.  Each revision of the announcement
   is documented in an own instance of this element.

13.5.  The "category" Element

   The empty element "category" provides data to categorize an
   announcement in coarse way.  Of course all meta data can be used to
   categorize an announcement if processed by software.  However
   according to our experience a general categorization done by the
   issuer that is constant to the document (i.e. the categorization is
   the same for each language and target group) and easy to read (few
   but prominent aspects) increases the usability of an announcement
   vastly.

   The element "category" has three attributes "platform", "product",
   and "protocol" for three main aspects of the announcement.  The
   attribute "platform" is REQUIRED and therefore MUST be present,
   whereas the other attributes are OPTIONAL.





Goebel                                                         [Page 84]

                               CAIF Format                 November 2005


   Synopsis:

           <category platform="..." [product="..."] [protocol="..."]/>

   The attributes have the following meanings:

   platform -- This attibute is used to describe the platform affected
      by the problem treated by the announcement.  This could be an
      operating system or an operating system family (e.g.  Microsoft
      Windows) or a more general issue like "cryptography" or "Software
      Patents".  A special value is "Generic" that can be used as a
      bridge over more than one platforms in combination with one or
      both of the other attributes (see the following two sections),
      e.g.

      Example:

           <category platform="Generic"
                     product="sendmail"
                     protocol="SMTP"/>

      More than one value per attribute can be provided separated by
      space characters.

   product -- This attibute is used to describe the product affected by
      the problem addressed by the announcement.  This could be a single
      program, a program family or a product that can be used on many
      platforms.  In the latter case, it may be useful to combine it
      with a 'platform="Generic"'.

      Example:

          <category platform="Generic" product="Mozilla">

   protocol -- This attribute describes a protocol that is either
      involved in the problem, e.g. provides the attack vector
      (Section 13.8.1.2), is implemented incorrectly, or has a design
      flaw itself.

      Example:

          <category platform="Generic" protocol="H.323">

   There are several activities to produce categorization-trees for
   products, version numbers and other data to uniquely identify
   systems.  Since a unique categorization-scheme is extremely dependent
   to the various vendors, CAIF does not provide a standardized product-
   tree, although such trees and categorizing taxonomies from other



Goebel                                                         [Page 85]

                               CAIF Format                 November 2005


   sources may be used.

13.6.  The "subject" Element

   The "subject" element implements the subject line (Section 8.5) (i.e.
   the overall title) of an announcement.  It contains at least one
   "body" element (Section 10.4) hat MAY provide a title string to the
   section definded by "subject".  If the announcement is multi-lingual
   or addresses more than one target group, the "body" element MAY occur
   multiple times in "subject" with different values for its "tg-ref"
   attribute.  The different instances of body contain the target group-
   specific title strings and subject strings.  It is recommended, that
   this string does not contain any markup but a plain text string with
   a preferred length of no more than 72 characters (according to
   RFC2822, see [4]) to avaoid information loss or reader inconvenience
   when used as a subject line of an e-mail message.

   This element is REQUIRED in an announcement.

   Synopsis:

           <subject>
             <body>
             ...
             </body>
           </subject>

   Example:

           <subject>
             <body tg-ref="en-admin">
             Several Flaws in different H.323 Implementations
             </body>
           </subject>

13.7.  The "summary" Element

   This element contains an abstract of the announcement in markup text.
   A summary SHOULD address the issue described briefly but
   comprehensively.  If an announcement has the level "brief"
   (Section 13.1.3) the summary SHOULD be more exhaustive since it then
   MAY replace the "description" element (Section 13.15).

   The content of the "summary" element is provided target group-
   secificly by one or more "body" elements (Section 10.4) that also MAY
   provide a title string to the section definded by "subject".  If the
   announcement is multi-lingual or addresses more than one target
   group, the "body" element MAY occur multiple times in "subject" with



Goebel                                                         [Page 86]

                               CAIF Format                 November 2005


   different values for its "tg-ref" attribute.

   This element is REQUIRED in an announcement.

   Since the "summary" element does not contain an "rlist" element it
   has the OPTIONAL attribute "who", similar to "rlist" (Section 10.5)
   to allow for the provison of different subject lines to different
   target groups of readers.

   Synopsis:

           <summary>
             <body>
              ...
             </body>
             {<body>
              ...
             </body>}
           </summary>

   Example:

           <summary>
             <body tg-ref="en-admin-mgmt"
                   headline="In Short">
             A buffer overflow bug in many implementations of the
             <protocol>H.323</protocol> protocol allows an attacker
             to execute arbitray code on affected systems. The
             <protocol>H.323</protocol> protocol is used by
             multimedia products like video-conferencing software
             or IP-telephony implementations.
             </body>
             <body tg-ref="de-admin-mgmt"
                   headline="Zusammenfassung">
             Eine Pufferueberlaufschwachstelle in vielen
             Implementierungen des
             <protocol>H.323</protocol>-Protokolls erlaubt
             Angreifern beliebigen Programmcode auf gegen diese
             Schwachstelle verwundbare Systemen auszufuehren. Das
             <protocol>H.323</protocol>-Protokoll wird von
             Multimediaanwendungen wie Videokonferenz- oder
             IP-Telefonie-Software verwendet.
             </body>
           </summary>







Goebel                                                         [Page 87]

                               CAIF Format                 November 2005


13.8.  The "problems" Element

   This element groups references to the described problems, like CVE
   and CAN Numbers [12], or bug IDs of the various product vendors and
   vulnerability IDs.  It has one or more "problem" sub-elements
   (Section 13.8.1) each grouping the IDs referring to and the several
   aspects of a single problem. exposure, or vulnerability.

   This element is OPTIONAL in an announcement.

   Synopsis:

           <problems>
             {<body>...</body>}
             <problem>
               ...
             </problem>
             {<problem>
               ...
             </problem>}
           <problems>

13.8.1.  The "problem" Element

   The "problem" element is the only sub-element of "problems"
   (Section 13.8).

   This element MAY appear multiple times within its superior element
   "problems".  Each instance contains one or more references
   identifying *one* vulnerability, exposure, or problem.  The OPTIONAL
   attribute "id" contains an internal-to-document ID, that is
   referenced by the "problem-ref" attribute of the "rlist items"
   (Section 10.5.4) in the section elements (Section 13).  This is
   especially useful if multiple problems are adressed by the
   announcement.

   Rendering the XML announcement can produce one document addressing
   all problems described or several documents each addressing one
   problem, e.g. if information regarding a specific problem is
   requested via a web portal such could be rendered on the fly.

   The "problem" element contains at least one "body" element
   (Section 10.4).  This element contains markup text describing the
   problem, vulnerability, or exposure as verbose as the issuer and the
   the specific target group require.  If the announcement addresses
   more than one target group, the "body" element MAY occur several
   times in "problem" with different values for its "tg-ref" attribute
   each referring to a specific target group (Section 13.2.1).  The



Goebel                                                         [Page 88]

                               CAIF Format                 November 2005


   different instances of body then contain the target group-specific
   textual descriptions, e.g. different language versions or several
   versions for readers with a different technical background or
   organizational overview.

   Since all problem-specific elements within a CAIF-document may
   contain references to problems it is possible to produce renderings
   that provide a view that is triggered from a non problem-specific
   aspect.  For example: it is possible to render a document that
   answers the question "Which problems apply to operating system XY".
   When parsing the document the parser would use all the "problem-ref"
   attributes of the "rli" elements (Section 10.5.4) that describe
   operating system XY, to collect all the other "rli" elements that
   refer to the same "problem" elements.

   The "problem" element has several sub elements containing information
   about aspects of the problem.

13.8.1.1.  The sub-element "class" of "problem"

   For characterization and statistical reasons this element contains
   information to classify the problem in terms of its cause.  The
   knowledge of the principle of a problem usually is valuable
   information, when taking countermeasures.

   It MAY contain one or more body elements (Section 10.4) that contain
   a target group specific (Section 13.2.1) textual description.

   The "class" element has the OPTIONAL attribute "key" that may contain
   a standard value to easen the classification and its use in
   statistics.  CAIF provides the following standard classifications:

   o  "buffer-overflow-bug"

   o  "format-string-bug"

   o  "insecure-configuration"

   o  "insecure-defaults"

   o  "design-flaw"

   o  "implementation-flaw"

   o  "malware"

   o  "other"




Goebel                                                         [Page 89]

                               CAIF Format                 November 2005


   The value "other" is the default, if the attribute is omitted.  The
   meaning of the values are described in Detail in Appendix B.2.1.

   Synopsis:

           <class [key="(
                         buffer-overflow-bug   |
                         format-string-bug     |
                         insecure-configuration|
                         insecure-defaults     |
                         design-flaw           |
                         implementation-flaw   |
                         malware               |
                         other
                         )"]>
             {<body>
               ...
             </body>}
           </class>

   Example:

           <class key="malware">
             <body tg-ref="en-admin">
             irc-bot
             </body>
           </class>

13.8.1.2.  The sub-element "attack-vector" of "problem"

   This element is intended to provide information about the path that
   can be used to exploit the problem and successfully attack an
   affected system (Section 13.10).  Such could be a specially crafted
   tcp packet to a port if the problem is in software that provides a
   network service or an email message containing the exploiting malware
   if it is a worm.

   Such information is valuable for network administrators and security
   teams if they want to take emergency measures to protect their
   constituency (Section 6.8) from a severe threat, e.g. the blocking of
   port 22, if there was a severe flaw in ssh.

   It contains one or more body elements (Section 10.4) that each
   contain the information within a target group specific
   (Section 13.2.1) textual description.

   The element MUST NOT contain any text nor any other elements outside
   its "body" subelements.



Goebel                                                         [Page 90]

                               CAIF Format                 November 2005


   Synopsis:

           <attack-vector>
             <body>
               ...
             </body>
             {<body>
               ...
             </body>}
           </attack-vector>

   Example:

           <attack-vector>
             <body tg-ref="en-admin">
             ssh-packet to port 22/tcp, or any other port on which sshd
             awaits connection attempts, depending on
             the configuration of sshd.
             </body>
           </attack-vector>

13.8.1.3.  The sub-element "attack-requirements" of "problem"

   This element provides information about the pre-requisites an
   attacker would need to successfully exploit the problem that is
   referenced by the containing problem element (Section 13.8.1).

   The "attack-requirements" element contains one or multiple body
   elements (Section 10.4) that each contain the information within a
   target group specific (Section 13.2.1) textual description.

   The element MUST NOT contain any text nor any other elements outside
   its "body" subelements.

   The element's OPTIONAL attribute "key" provides some standard
   requirements an attacker needs to successfully attack an affected
   system (Section 13.10) by exploiting the referenced problem,
   vulnerability, or exposure, and achieve the impact described within
   the "impact" element (Section 13.8.1.5) which is also a sub-element
   of "problem".  The "attack-requirements" element has the OPTIONAL
   attribute "key" that may contain a standard value describing attack
   requirements.  CAIF provides the following standard types of attack
   requirements:

   o  "local"

   o  "network-group"




Goebel                                                         [Page 91]

                               CAIF Format                 November 2005


   o  "null-session"

   o  "broadcast-domain"

   o  "application-user"

   o  "remote"

   If none of these values apply, the "key" attribute MAY be omitted or
   the value "other" can be provided.  Both possibilities have the same
   effect since "other" is the default value.  The set of values is
   described in Detail in Appendix B.2.2.

   Synopsis:

           <attack-requirements [key="(
                         local           |
                         network-group   |
                         null-session    |
                         broadcast-domain|
                         application-user|
                         remote          |
                         other
                         )"]>
             <body>
               ...
             </body>
             {<body>
               ...
             </body>}
           </attack-requirements>

   Example:

           <attack-requirements key="remote" >
             <body tg-ref="en-admin">
             The attacker MUST have  access a network that is routing
             packets to the affected system.
             </body>
           </subject>

13.8.1.4.  The sub-element "attack-signature" of "problem"

   The "attack-signature" element is intended to provide information
   about the traces a try to exploit the problem or a successful attack
   leave.  Such could be a log file entry, special network traffic or
   strange behavior.  The element can also be used to provide fully
   featured attack signatures that can be fed into intrusion detection



Goebel                                                         [Page 92]

                               CAIF Format                 November 2005


   systems (IDS).

   The OPTIONAL attribute "type" allows to provide some additional
   information to the parser.  This is useful, if the issuer includes
   signatures for an IDS -- e.g. snort -- and wants the parser to
   extract and automatically feed them in the IDS.  In this case, the
   attribute could have the value "snort" to indicate that the data
   included in the element is ready to be fed into the system.

   It contains one or multiple body elements (Section 10.4) that each
   contain the information within a target group specific
   (Section 13.2.1) textual description.

   The element MUST NOT contain any text nor any other elements outside
   its "body" subelements.

   The element "attack-signature" is OPTIONAL within its containing
   element problem (Section 13.8.1).

13.8.1.5.  The sub-element "impact" of "problem"

   This element is intended to provide information about the effects a
   sucessful exploit of the problem has on the vulnerable system,
   commonly known as the "impact".  Besides others, such could be a
   denial of service condition, a privilige escalation or the compromise
   of a system.  The element implements the "impact" section
   (Section 8.7).  The information given in this element SHALL express a
   constituency-independent worst-case view.  It MUST NOT contain
   information about traces an attack - successful or not - leaves on an
   attacked system or its environment.  Such information is to be
   included in the "attack-signature" element (Section 13.8.1.4).

   The element contains one or more body elements (Section 10.4) that
   contain the information within the several target group specific
   (Section 13.2.1) versions.

   The element MUST NOT contain any text nor any other elements outside
   its "body" subelements.

   The element's OPTIONAL attribute "key" provides some standard impacts
   a successful attack could have on an affected system (Section 13.10)
   by exploiting the referenced problem, vulnerability, or exposure.
   They are:

   o  "denial-of-service"

   o  "information-leak"




Goebel                                                         [Page 93]

                               CAIF Format                 November 2005


   o  "data-manipulation"

   o  "user-compromise"

   o  "system-compromise"

   If none of these values apply, the "key" attribute MAY be omitted or
   the value "other" can be provided.  Both possibilities have the same
   effect since "other" is the default value.  The set of values is
   described in Detail in Appendix B.2.3.

   The element "impact" is OPTIONAL but MUST NOT occur multiple times
   within its containing element problem (Section 13.8.1).

   Synopsis:

           <impact [key="(
                           denial-of-service|
                           information-leak |
                           data-manipulation|
                           user-compromise  |
                           system-compromise|
                           other
                         )"]>
             <body>
               ...
             </body>
             {<body>
               ...
             </body>}
           </impact>

   Example:

           <impact key="denial-of-service" >
             <body tg-ref="en-admin">
             A sucessful exploit results in the consumptopn of all
             system ressources, thus makes the hosting system
             unusable and any of its services unavailable.
             </body>
           </impact>

13.8.1.6.  The sub-element "exploit-status" of "problem"

   This element describes the status of knowledge about actual
   exploitations of the problem, vulnerability, or exposure and the
   availability of automated attack programs, so-called "exploit code".
   It is a valuable piece of information for operators of an affected



Goebel                                                         [Page 94]

                               CAIF Format                 November 2005


   system, to know if there are observed exploitations of a given
   problem or if there is code available that can be used to exploit the
   problem.

   Exploit code is program code designed to exploit the problem in order
   to produce not only immediate effects like overflowing a buffer and
   thus crashing an affected system, but also mediate effects like
   inject and execute arbitrary program code.  There are several types
   of exploit code: the so called "proof of concept" demonstrating that
   the problem can be exploited to sucessfully attack affected systems
   but not doing evil things, and its further development, the automated
   attack program that exploits the problem and does evil things on
   affected systems.  The latter sometimes are called "malware"
   (malicious software).

   Note, that not only so-called "root-kits" or scan programs having
   exploit functionality qualify as malware but worms, viruses, and bots
   too.

   A change of the content of the "exploit-status" element may change
   the contents of the "threat" (Section 13.8.1.9), and "probability-of-
   occurrence" (Section 13.8.1.8) elements, if present, and may cause
   the re-issuing of the announcement according to the policies of an
   issuer.

   The element contains one or more body elements (Section 10.4) that
   contain the text describing the knowledge the author or the issuere
   respectively about the exploit status.  Depending on the target
   groups (Section 13.2.1) defined in the overall document the several
   "body" elements contain a target group specific version of the text.

   The element MUST NOT contain any text nor any other elements outside
   its "body" subelements.

   Since it is obviously impossible to determine whether exploits do
   *not* occur it is unknown at best if they occur or not.  Besides
   rumors about exploits it is a common practice, that exploits and
   exploit codes are advertised or announced.  It can be regarded as a
   seperate quality of knowledge if the issuer herself has observed
   attempts to exploit the problem because she does not have to rely on
   third party information.  Thus, this fact SHOULD be communicated in
   the announcement.

   Sometimes a so-called "proof-of-concept" is published that
   demonstrates the principle of an exploit without providing the
   capability to successfully attack vulnerable systems.  However, it is
   usually only a short way to use such a demonstration for producing
   working exploit code.



Goebel                                                         [Page 95]

                               CAIF Format                 November 2005


   The final state of this development of the "exploit status" is the
   availability of automated attack programs that are capable to
   successfully exploit the problem.  Such "malware" could be a worm for
   example.

   The element's OPTIONAL attribute "key" provides some standard values
   that describe these states of knowledge.  The attribute allows to
   categorize this piece of information.

   CAIF provides the following standard classifications:

   o  "unknown"

   o  "rumored"

   o  "advertised"

   o  "observed"

   o  "proof-of-concept"

   o  "malware"

   Note, that a virus, worm, or bot is "malware".  The "key" attribute
   defaults to "unknown" if it is omitted.  The meanings of the values
   are described in Detail in Appendix B.2.4.

   Note, that the knowledge about the exploit status may be changing
   over time.  While the knowledge may be poor when the annoucement is
   initially issued it may grow over time or the situation may change.
   In most cases a change of this knowledge would vindicate a re-issue
   of the announcement, especially if the situation changes and has an
   effect on the risk (Section 13.8.1.7) the problem imposes on affected
   system (Section 13.10) or threat (Section 13.8.1.9) it imploses on a
   given constituency (Section 13.3.1).  This is subject to the policy
   of the issuer.

   The element "exploit-status" is OPTIONAL and MUST NOT occur multiple
   times within its containing element problem (Section 13.8.1).












Goebel                                                         [Page 96]

                               CAIF Format                 November 2005


   Synopsis:

           <exploit-status [key="(
                           unknown         |
                           rumored         |
                           advertised      |
                           observed        |
                           proof-of-concept|
                           malware
                         )"]>
             {<body>
               ...
             </body>}
           </exploit-status>

   Example:

           <exploit-status key="advertised" >
             <body tg-ref="en-admin">
             RUS-CERT have announced to have verified the
             exploitability of the problem.
             </body>
           </exploit-status>

13.8.1.7.  The sub-element "risk" of "problem"

   This element describes the "technical" risk the problem,
   vulnerability, or exposure represents in a worst-case view.  It MUST
   NOT reference to a specific constituency (Section 13.3.1).  It rather
   references to an affected system (Section 13.10) and the most severe
   impact (Section 13.8.1.5) the successful exploitation of the problem
   could have on this system.  This sort of "academic" view is the basis
   for further assessments and a constituency-specific evaluation of the
   problem (see Section 13.8.1.8 and Section 13.8.1.9).

   The element contains one or more body elements (Section 10.4) that
   MAY contain markup text to describe the risk in greater detail.
   Depending on the target groups (Section 13.2.1) defined in the
   overall document the several "body" elements contain a target group
   specific version of the text.

   The element MUST NOT contain any text nor any other elements outside
   its "body" subelements.

   The element's OPTIONAL attribute "key" provides some standard values
   that allow a standardized risk classification.





Goebel                                                         [Page 97]

                               CAIF Format                 November 2005


   o  "low"

   o  "medium"

   o  "high"

   o  "very high"

   The meaning of the values are described in Detail in Appendix B.2.5.

   The OPTIONAL attribute "policy" identifies the procedure that has
   been applied to achieve the assessment that is described in the
   "body" element.  If this assessment conflicts with the set of values
   of the optional "key" attribute then this attribute can be ommitted.
   The attribute may contain an abbreviation describing the name of the
   policy (like "CVSS" for the "Common Vulnerability Scoring System"
   [15]) or an URL pointing to an external resource or ant other
   reference.

   The element "risk" is OPTIONAL and MUST NOT occur multiple times
   within its containing element problem (Section 13.8.1).

   Synopsis:

           <risk [key="(
                          low      |
                          medium   |
                          high     |
                          very-high
                         )"]
                 [policy="..."]>
             {<body>
               ...
             </body>}
           </risk>

   Examples

           <risk key="very-high">
             <body tg-ref="en-admin" headline="Technical Risk">
               The potential technical risk is very high.
             </body>
             <body tg-ref="de-admin" headline="Gefahrenpotential">
               <em>sehr hoch</em>
             </body>
           </risk>





Goebel                                                         [Page 98]

                               CAIF Format                 November 2005


   Synopsis:

           <risk key="very-high" policy="CVSS">
             <body tg-ref="en-admin" headline="Technical Risk">
               9.2
             </body>
             <body tg-ref="de-admin" headline="Technisches Risiko">
               9.2
             </body>
           </risk>

13.8.1.8.  The sub-element "probability-of-occurrence" of "problem"

   This element is intended to allow issuers to provide their
   constituency (Section 13.3.1) with an estimation on the probability
   the referenced problem, vulnerability, or exposure is exploited
   within the constituency's IT-infrastructure and the impacts described
   in the announcement (see Section 13.8.1.5) take effect.

   If an abstract constituency has been defined, this element can be
   used to refer to this abstract constituency.  The OPTIONAL "const-
   ref" attribute contains an unique id within the document that refers
   to the constituency the estimation is made for.

   For example: if the problem described is a buffer overflow bug in a
   vital service of an operating system that is deployed in great
   numbers within constituency "A" the "probability-of-occurrence" would
   be much greater than in constituency "B" that is mostly relying on a
   different operating system.

   However, "probability-of-occurrence" does not take into account the
   severety of the impact, the successful exploitation of the described
   problem would have on affected systems.  This aspect is covered by
   the element "risk" (Section 13.8.1.7).  A combined estimation taking
   into account the technical risk and the probability of occurrence is
   provided by the element "threat" (Section 13.8.1.9, see below).

   The element contains one or more body elements (Section 10.4) that
   MAY contain markup text to describe the estimation in greater detail
   and provide additional information.  Depending on the target groups
   (Section 13.2.1) defined in the overall document the several "body"
   elements each contain a target group specific version of the text.

   The element MUST NOT contain any text nor any other elements outside
   its "body" subelements.

   The element's OPTIONAL attribute "key" provides some standard values
   that allow a standardized classification of the probability of



Goebel                                                         [Page 99]

                               CAIF Format                 November 2005


   occurrence of an exploit of the problem.

   o  "low"

   o  "medium"

   o  "high"

   o  "very high"

   The set of values is described in Detail in Appendix B.2.6.

   The OPTIONAL attribute "policy" identifies the procedure that has
   been applied to achieve the assessment that is described in the
   "body" element.  If this assessment conflicts with the set of values
   of the optional "key" attribute then this attribute can be ommitted.
   The attribute may contain an abbreviation describing the name of the
   policy (like "CVSS" for the "Common Vulnerability Scoring System"
   [15]) or an URL pointing to an external resource or ant other
   reference.

   Since there MAY be none or more than one constituencies defined, the
   element "probability-of-occurrence" MAY be omitted or MAY occur more
   that one time within its containing element problem (Section 13.8.1).

   Synopsis:

           <probability-of-occurrence
                   [const-ref="ID{ ID}"]
                   [key="(
                          low      |
                          medium   |
                          high     |
                          very-high
                         )"]
                   [policy="..."]>
             {<body>
               ...
             </body>}
           </probability-of-occurrence>











Goebel                                                        [Page 100]

                               CAIF Format                 November 2005


   Example:

           <probability-of-occurrence
               const-ref="StuttgartUniversity"
               key="medium" policy="RUS-CERT">
             <body tg-ref="en-admin"
                   headline="Probability of Occurrence">
               The probability of exploits within Stuttgart
               University's IT infrastrucrure is rather
               <em>medium</em>, since there are only few
               affected systems deployed.
             </body>
             <body tg-ref="de-admin"
                   headline="Eintrittswahrscheinlichkeit">
               Die Wahrscheinlichleit, dass die Schwachstelle
               innerhalb der Netze der Universtaet Stuttgart
               ausgenutzt wird, ist eher als <em>mittel</em>
               einzuschaetzen, da nur wenige verwundbare
               Systeme in Betrieb sind.
             </body>
           </probability-of-occurrence>
           <probability-of-occurrence
               const-ref="Example.com-Internal"
               key="high" policy="RUS-CERT">
             <body tg-ref="en-admin"
                   headline="Probability of Occurrence">
               The probability of exploits within Example.com's
               internal IT infrastructure is to be
               considered <b>high</b> since there are many
               systems in service that are vulnerable to the
               problem described.
             </body>
             <body tg-ref="de-admin"
                   headline="Eintrittswahrscheinlichkeit">
               Die Wahrscheinlichleit, dass die Schwachstelle
               innerhalb der internen IT-Infrastruktur von Example.com
               ausgenutzt wird, ist  als <b>hoch</b> einzuschaetzen,
               da zahlreiche verwundbare Systeme in Betrieb sind.
             </body>
           </probability-of-occurrence>

   This element is OPTIONAL in "problem".

13.8.1.9.  The sub-element "threat" of "problem"

   This element is intended to allow issuers to provide an estimation of
   the threat the referenced problem, vulnerability, or exposure imposes
   upon a given constituency (Section 13.3.1).  The "threat" basically



Goebel                                                        [Page 101]

                               CAIF Format                 November 2005


   is a value that results from a calculus that takes the technical risk
   (Section 13.8.1.7) and the probability the given problem is being
   exploited within a given constituency (Section 13.8.1.8).  Of course
   it is possible to make an estimation that refers to an abstract
   constituency.  The OPTIONAL "const-ref" attribute contains an id
   unique within the document that refers to the constituency
   (Section 13.3.1) the estimation is made for.

   The element contains one or more body elements (Section 10.4) that
   MAY contain markup text to describe the estimation in greater detail
   and provide additional information.  Depending on the target groups
   (Section 13.2.1) defined in the overall document the several "body"
   elements contain a target group specific version of the text.

   The element MUST NOT contain any text nor any other elements outside
   its "body" subelements.

   The element's OPTIONAL attribute "key" provides some standard values
   that allow a standardized classification of the threat the problem
   imposes on a given constituency.

   o  "low"

   o  "medium"

   o  "high"

   o  "very high"

   The values and their meaning are described in Detail in
   Appendix B.2.7.

   The OPTIONAL attribute "policy" identifies the procedure that has
   been applied to achieve the assessment that is described in the
   "body" element.  If this assessment conflicts with the set of values
   of the optional "key" attribute then this attribute can be ommitted.
   The attribute may contain an abbreviation describing the name of the
   policy (like "CVSS" for the "Common Vulnerability Scoring System"
   [15]) or an URL pointing to an external resource or ant other
   reference.

   Since there MAY be none or more than one constituencies defined, the
   element "threat" MAY be omitted or MAY occur more that one time
   within its containing element problem (Section 13.8.1).







Goebel                                                        [Page 102]

                               CAIF Format                 November 2005


   Synopsis:

           <threat
                   [const-ref="ID{ ID}"]
                   [key="(
                          low      |
                          medium   |
                          high     |
                          very-high
                         )"]
                   [policy="..."]>
             {<body>
               ...
             </body>}
           </threat>




































Goebel                                                        [Page 103]

                               CAIF Format                 November 2005


   Example:

           <threat const-ref="StuttgartUniversity"
               key="high">
             <body tg-ref="en-admin"
                   headline="Potential Threat">
               The threat the problem described imposes on Stuttgart
               University's IT infrastrucrure is <b>high</b>, since
               the technical risk is <b>very high</b> and the impact on
               affected systems is a system compromise. Even few
               compromised systems can be used as bridge-head to attack
               other systems.
             </body>
             <body tg-ref="de-admin"
                   headline="Bedrohungspotential">
               Die Bedrohung, die die beschriebene Schwachstelle
               fuer die IT-Infrastruktur der Universtaet Stuttgart
               darstellt, ist als <em>hoch</em> einzuschaetzen, da
               eine erfolgreiche Ausnutzung zur Kompromittierung
               des angegriffenen Systems fuehrt. Diese Systeme
               koennen als Brueckenkopf fuer weitere Angriffe verwendet
               werden.
             </body>
           </threat>
           <threat const-ref="Example.com-Internal"
               key="very-high">
             <body tg-ref="en-admin"
                   headline="Potential Threat">
               The threat the problem described imposes on Example.com's
               internal IT-infrastructure is <vb>very high</vb>
               since there are are many systems in service that
               are vulnerable against the problem described and
               a successful exploitation results in a system compromise.
             </body>
             <body tg-ref="de-admin"
                   headline="Bedrohungspotential">
               Die Bedrohung, die die beschriebene Schwachstelle
               fuer die internen IT-Infrastruktur von Example.com
               darstellt, ist als <vb>sehr hoch</vb> einzuschaetzen,
               da zahlreiche verwundbare Systeme in Betrieb sind und
               eine Ausnutzung zur kopromittierung des angeriffenen
               Systems fuehrt.
             </body>
           </threat>

   This element is OPTIONAL within "problem".





Goebel                                                        [Page 104]

                               CAIF Format                 November 2005


13.8.1.10.  The Overall Syntax of the  "problem" Element

   The "key" attributes of the sub-elements of "problem" that are
   described above allow to categorize the several aspects of the
   problems

   One might think that these attributes better should be included in
   the "rli" elements (Section 10.5.4) of the rlists (Section 10.5) that
   are contained by the corresponding elements.  Indeed this was the
   case in an earlier version of CAIF but when multi-linguality and
   multiple target groups were introduced to the format, a normalization
   step was necessary.  The information provided by these elements
   belong to a problem and therefore MUST be attached to the element
   that identifies the problem, independently from other aspects like
   information about the language or the target group (Section 13.2.1).
   If the attributes were attached to the "rlists" that may occur
   multiple times in a top-level element, their improper assignment of
   values could lead to inconsistencies that cannot be detected when
   validating an announcement against CAIF's DTD (Appendix C).  Hence,
   the attributes are attached to the "problem" element's sub-elements.

   The rather complex element "problem" has the following syntax:





























Goebel                                                        [Page 105]

                               CAIF Format                 November 2005


   Overall Synopsis:

           <problem {id="ID"}>
             <body>
             ...
             </body>
             {<body>
             ...
             </body>}
             [<class>
             ...
             </class>]
             [<attack-vector>
             ...
             </attack-vector>]
             [<attack-requirements>
             ...
             </attack-requirements>]
             [<attack-signature>
             ...
             </attack-signature>]
             [<impact>
             ...
             </impact>]
             [<exploit-status>
             ...
             </exploit-status>]
             [<risk>
             ...
             </risk>]
             [<probability-of-occurrence>
             ...
             </probability-of-occurrence>]
             [<threat>
             ...
             </threat>]
           </problem>

13.9.  The "mitigation" Element

   The "mitigation" element contains information about factors that
   mitigate the risk potential or "technical risk" (Section 13.8.1.7) of
   a problem.  Such could be the fact, that the special configurations,
   that cause a system's affectedness, are not activated by default.
   Note, that a workaround (Section 13.16) or solution (Section 13.17)
   does not mitigate a problem in the sense the term "mitigation" is
   used here.




Goebel                                                        [Page 106]

                               CAIF Format                 November 2005


   The element SHOULD contain a basic description that is constituency-
   independent.

   If the issuer wants to include constituency-specific information it
   MUST be enclosed in "const" (Section 9.3.4) tags.  Such information
   could be the fact that the default configuration of the systems of a
   given constituency is mitigating the threat because the systems
   configured like this are not affected.  If such information is
   provided the assessments given in the "threat" (Section 13.8.1.9) and
   "probability-of-occurrence" (Section 13.8.1.8) elements that refer to
   the same constituency SHOULD reflect this information.

   Note, that the presence of mitigatig information MUST NOT have an
   effect on the risk assessment given in the "risk" element
   (Section 13.8.1.7), since that describes the risk potential in a
   worst-case view.

   The element either comprises of one or multiple "body" (Section 10.4)
   or "rlist" (Section 10.5) elements.  A mixed use of these elements is
   neither allowed nor sensible.

   If the announcement describes a single problem, the element contains
   "body" elements each providing textual descriptions specific to the
   target group (Section 13.2.1) referred by the body's "tg-ref"
   attribute and an OPTIONAL title string to the section definded by
   "affected".

   If the announcement addresses more than one problem (Section 13.8),
   the element contains "rlist" elements each providing target group-
   specific textual descriptions within its "rli" (Section 10.5.4)
   elements.  Each "rlist" is specific to the target group referenced by
   its "tg-ref" attribute.  The "rli" elements within a single rlist
   address the different problems, referenced by the "problem-ref"
   attribute of "rli".

   This element is OPTIONAL in an announcement.

   Synopsis:

           <mitigation>
             (<body>...</body>
              {<body>...</body>}|
              <rlist>...</rlist>
              {<rlist>...</rlist>})
           </mitigation>






Goebel                                                        [Page 107]

                               CAIF Format                 November 2005


   Example:

           <mitigation>
             <body>
               <p>
               The affected feature is not activated by default.
               </p>
               <p>
               Please go to the <iref
               target="determine-affectedness">"Am I Affected?"</iref>
               section to determine, if the feature is activated on
               your system.
               </p>
             </body>
           </mitigation>

   This element is OPTIONAL in an announcement.

13.10.  The "affected" Element

   This element contains information about the systems affected by the
   problems addressed by the announcement.  It is recommended to
   structure the content in a list and be as verbose and exact as
   possible when describing versions etc.

   It is strongly recommended, to use the system vendor's nomenclature
   when using product names, versions and patch-levels.

   The markup element "aff" (Section 9.3.5) can be used to provide the
   descriptions of the affected systems with an internal id that acts as
   a reference target within the document.  This is useful e.g. if the
   issuer wants to provide data for scanners that are capable
   automatically determine whether systems in a given it infrastructure
   are vulnerable to the problem(s) described (see also Section 13.13).

   The element either comprises of one or multiple "body" (Section 10.4)
   or "rlist" (Section 10.5) elements.  A mixed use of these elements is
   neither allowed nor sensible.

   If the announcement describes a single problem, the element contains
   "body" elements each providing textual descriptions specific to the
   target group (Section 13.2.1) referred by the body's "tg-ref"
   attribute and an OPTIONAL title string to the section definded by
   "affected".

   If the announcement addresses more than one problem (Section 13.8),
   the element contains "rlist" elements each providing target group-
   specific textual descriptions within its "rli" (Section 10.5.4)



Goebel                                                        [Page 108]

                               CAIF Format                 November 2005


   elements.  Each "rlist" is specific to the target group referenced by
   its "tg-ref" attribute.  The "rli" elements within a single rlist
   address the different problems, referenced by the "problem-ref"
   attribute of "rli".

   This element is OPTIONAL in an announcement.

   Synopsis:

           <affected>
             (<body>...</body>
              {<body>...</body>}|
              <rlist>...</rlist>
              {<rlist>...</rlist>})
           </affected>

   If provided consistently within announcements over time, the contents
   of this element as well as the contents of the elements "not-
   affected" (Section 13.11), "possibly-affected" (Section 13.12), and
   "category" (Section 13.5) can be used to produce a taxonomy-tree for
   the systems, platforms, and protocols addressed by announcements.  If
   announcements are stored within a database, such could be used as
   keys for a query system.

13.11.  The "not-affected" Element

   This element contains information about the systems that are
   definitively not affected by the problem(s) addressed in the
   announcement.  It is recommended to structure the content in a list
   and be as verbose and exact as possible when describing versions etc.

   It is strongly recommended to use the system vendor's nomenclature
   for products and versions.

   The markup element "aff" (Section 9.3.5) can be used to provide the
   descriptions of the affected systems with an internal id that acts as
   a reference target within the document.  This is useful if the issuer
   wants to provide data for scanners that are capable automatically
   determine whether systems in a given it infrastructure are vulnerable
   to the problem(s) described (see also Section 13.13).

   The element either comprises of one or multiple "body" (Section 10.4)
   or "rlist" (Section 10.5) elements.  A mixed use of these elements is
   neither allowed nor sensible.

   If the announcement describes a single problem, the element contains
   "body" elements each providing textual descriptions specific to the
   target group (Section 13.2.1) referred by the "tg-ref" attribute and



Goebel                                                        [Page 109]

                               CAIF Format                 November 2005


   an OPTIONAL title string to the section that is definded by the "not-
   affected" element.

   If the announcement addresses more than one problem (Section 13.8),
   the element contains "rlist" elements each providing target group-
   specific textual descriptions within its "rli" (Section 10.5.4)
   elements.  Each "rlist" is specific to the target group referenced by
   its "tg-ref" attribute.  The "rli" elements within a single rlist
   address the different problems, referenced by the "problem-ref"
   attribute of "rli".

   This element is OPTIONAL in an announcement.

   Synopsis:

           <not-affected>
             (<body>...</body>
              {<body>...</body>}|
              <rlist>...</rlist>
              {<rlist>...</rlist>})
           </not-affected>

13.12.  The "possibly-affected" Element

   This element contains information about the systems of which the
   issuer has no evidence on the affectedness by the problems addressed
   by the announcement.  It is recommended to structure the content in a
   list and be as verbose and exact as possible when describing versions
   etc.

   It is strongly recommended to use the system vendor's nomenclature
   for products and versions.

   Note, that the content of this element usually requires maintenance,
   since it should be the intention of issuers and authors to determine
   whether a system is affected or not.  Hence, this element SHOULD only
   be provided in an announcement, if it has to be issued urgently but
   time or ressources are insufficient to gain evidence about the
   affectedness of some systems.  Thus, it is sensible for issuers to
   implement a policy on how to use this element.

   The markup element "aff" (Section 9.3.5) can be used to provide the
   descriptions of the affected systems with an internal id that acts as
   a reference target within the document.  This is useful if the issuer
   wants to provide data for scanners that are capable automatically
   determine whether systems in a given it infrastructure are vulnerable
   to the problem(s) described (see also Section 13.13).




Goebel                                                        [Page 110]

                               CAIF Format                 November 2005


   The element contains either one or multiple "body" (Section 10.4) or
   "rlist" (Section 10.5) elements.  A mixed use of these elements is
   neither allowed nor sensible.

   If the announcement describes a single problem, the element contains
   "body" elements each providing textual descriptions specific to the
   target group (Section 13.2.1) referred by the "tg-ref" attribute and
   an OPTIONAL title string to the section that is definded by the
   "possibly-affected" element.

   If the announcement addresses more than one problem (Section 13.8),
   the element contains "rlist" elements each providing target group-
   specific textual descriptions within its "rli" (Section 10.5.4)
   elements.  Each "rlist" is specific to the target group referenced by
   its "tg-ref" attribute.  The "rli" elements within a single rlist
   address the different problems, referenced by the "problem-ref"
   attribute of "rli".

   This element is OPTIONAL in an announcement.

   Synopsis:

           <possibly-affected>
             (<body>...</body>
              {<body>...</body>}|
              <rlist>...</rlist>
              {<rlist>...</rlist>})
           </possibly-affected>

13.13.  The "determine-affectedness" Element

   The "determine-affectedness" element contains one or more "detitem"
   elements, each providing information on how the affectedness of a
   given system to the problem(s) described can be determined.  Besides
   its sub-elements the "determine-affectedness" element does not
   contain any textual descriptions or attributes.

   This element is OPTIONAL in an announcement













Goebel                                                        [Page 111]

                               CAIF Format                 November 2005


   Synopsis:

           <determine-affectedness>
             <detitem>
             ...
             </detitem>
            {<detitem>
             ...
             </detitem>}
           </determine-affectedness>

13.13.1.  The "detitem" Element

   This element's purpose is to contain data, that helps to determine
   whether a given system or IT infrastructure is affected by the
   problem(s) described.  Such data could be a description of steps that
   shall be performed manually by the reader, a script, some
   configuration data for an automated program (like a vulnerability
   scanner), or a combination of such.

   The element contains either one or multiple "body" (Section 10.4)
   elements that contain the information.

   The OPTIONAL attribute "content-type" describes the type of data that
   is contained by the "body" elements.  It has the following predefined
   values:

   "base64" -- the content is in a non-7-bit ascii format and has been
      base 64 encoded to be included within the document.  The rendering
      policy defines how the content shall be treated.

   "parsed" -- the data is part of the CAIF document and SHALL be parsed
      by the CAIF parser.  This is the default value and applies to all
      textual descriptions.

   If the content is in another XML-based language like OVAL [14] or
   AVDL [16] the parser MUST be told, that it SHALL NOT process this
   part of the document but rather pass it to the respective parsers
   that will process the data.  This is necessary because these
   languages do have their own document type definitions (DTD, see
   Section 7.2) or schemata which are not part of CAIF's DTD
   (Appendix C).  If the CAIF parser tried to process these contents it
   would probably encounter errors.  Thus, the contents MUST be marked
   as not to be parsed.  This is done by providing the leading string
   "<![CDATA[" right at the beginning of the content that shall not be
   parsed.  The string "]]>" marks the end of this data and tells the
   parser to continue processing the following content.  Consequently,
   the string "]]" MUST NOT appear within the enclosed document.



Goebel                                                        [Page 112]

                               CAIF Format                 November 2005


   The same applies to base64-encoded data.

   The OPTIONAL attribute "method" indicates which method is to be used
   to determine the affectedness is described by the content.  It has no
   pre-defined values but the following are considered to be useful:

   "manual" -- the information provided describes a manual method that
      is to be performed by the reader to determine whether a given
      system is affected by the problem(s) described, e.g. a list of
      steps or commands to be entered.

   "shell" -- the data is a shell code snippet or script that can be
      used to determine whether a system is affected or not.

   a tool or format name -- the data is to be fed into a software tool
      that is able to (semi-)automatically determine if a system or a
      the systems within a given IT-infrastructrure are affected.  For
      example: if the data is provided in some other XML language like
      OVAL or AVDL, the names of the respective format SHOULD be
      provided.  It is highly recommended that standardized names are
      used, so that CAIF-processing software knows which third-party
      software is to be fed with the data contained by the "detitem"
      element.

   CAIF-interpreting software SHOULD assume "manual" as the default
   value if the attribute is omitted.

   The REQUIRED attribute "aff-ref" provides a reference to the id that
   is defined by the "aff" markup element (Section 9.3.5).  It is
   intended to allow an exact determination within the document for
   which affected system the information is provided in the "detitem"
   element.

   The OPTIONAL attribute "problem-ref" allows to refer to one or more
   of the problems (Section 13.8.1) that are described in the
   announcement.  The mechanism is similar to the reference that is
   implemented by the "rli" element (Section 10.5.4).

   Synopsis:

           <detitem [method="manual|shell|tool|...]"
                    aff-ref="IDREF {IDREF}"
                    [problem-ref="IDREF {IDREF}]"
                    content-type="base64|parsed">
              <body>...</body>
              {<body>...</body>}
           </detitem>




Goebel                                                        [Page 113]

                               CAIF Format                 November 2005


   Example:

           <affected>
             <rlist>
               <rli problem-ref="LSASS">
                 <list style="symbols">
                   <li>
                   <aff id=W2000>Windows 2000</aff>
                   </li>
                   <li>
                   <aff id=W2000SP1>Windows 2000 Service Pack 1</aff>
                   </li>
               </rli>
             </rlist>
           </affected>
           ...
           <determine-affectedness>
             <detitem method="OVAL"
                      aff-ref="W2000"
                      problem-ref="LSASS">
                      content-type="base64"
               <body>
               OVAL-Data
               </body>
            </detitem>
            <detitem method="AVDL"
                     aff-ref="W2000SP1
                     problem-ref="LSASS">
                     content-type="base64"
               <body>
               AVDL-Data
               </body>
            </detitem>
          </determine-affectedness>

13.14.  The "context" Element

   This element implements the context section (Section 8.12) containing
   impartial information about the technical background of an/the
   system(s) affected (see Section 13.10)by the problem addressed by the
   announcement that is independent to a special constituency.

   The element contains either one or multiple "body" (Section 10.4) or
   "rlist" (Section 10.5) elements.  A mixed use of these elements is
   neither allowed nor sensible.

   If the announcement describes a single problem, the element contains
   "body" elements each providing textual descriptions specific to the



Goebel                                                        [Page 114]

                               CAIF Format                 November 2005


   target group (Section 13.2.1) referred by the "tg-ref" attribute and
   an OPTIONAL title string to the section that is definded by the
   "context" element.

   If the announcement addresses more than one problem (Section 13.8),
   the element contains "rlist" elements each providing target group-
   specific textual descriptions within its "rli" (Section 10.5.4)
   elements.  Each "rlist" is specific to the target group referenced by
   its "tg-ref" attribute.  The "rli" elements within a single rlist
   address the different problems, referenced by the "problem-ref"
   attribute of "rli".

   This element is OPTIONAL in an announcement.

   Synopsis:

           <context>
             (<body>...</body>
              {<body>...</body>}|
              <rlist>...</rlist>
              {<rlist>...</rlist>})
           </context>

13.15.  The "description" Element

   This element contains a detailed description of the problem(s)
   addressed.  It implements the "description" section (Section 8.11).
   Authors SHOULD describe the problem(s) comprehensively, including the
   attack, its requirements, and vector, the impact, and possibly
   subsequent impacts, if applicable.  The information provided SHOULD
   be sufficient for a reader to decide whether the issue is a threat to
   her IT infrastructure.

   The element contains either one or multiple "body" (Section 10.4) or
   "rlist" (Section 10.5) elements.  A mixed use of these elements is
   neither allowed nor sensible.

   If the announcement describes a single problem, the element contains
   "body" elements each providing textual descriptions specific to the
   target group (Section 13.2.1) referred by the "tg-ref" attribute and
   an OPTIONAL title string to the section that is definded by the
   "description" element.

   If the announcement addresses more than one problem (Section 13.8),
   the element contains "rlist" elements each providing target group-
   specific textual descriptions within its "rli" (Section 10.5.4)
   elements.  Each "rlist" is specific to the target group referenced by
   its "tg-ref" attribute.  The "rli" elements within a single rlist



Goebel                                                        [Page 115]

                               CAIF Format                 November 2005


   address the different problems, referenced by the "problem-ref"
   attribute of "rli".

   This element is REQUIRED in an announcement.

   Synopsis:

           <description>
             (<body>...</body>
              {<body>...</body>}|
              <rlist>...</rlist>
              {<rlist>...</rlist>})
           </description>

13.16.  The "workaround" Element

   The "workaround" element contains information about one or more
   temporary solutions to the problem(s) addressed by the announcement.
   Such could be the termination or re-configuration of an affected
   service, or the restriction of access to an affected system.  Authors
   SHOULD describe the necessary actions and steps comprehensively and
   detailed, in order to enable readers to easily apply the workaround.

   The element contains either one or multiple "body" (Section 10.4) or
   "rlist" (Section 10.5) elements.  A mixed use of these elements is
   neither allowed nor sensible.

   If the announcement describes a single problem, the element contains
   "body" elements each providing textual descriptions specific to the
   target group (Section 13.2.1) referred by the "tg-ref" attribute and
   an OPTIONAL title string to the section that is definded by the
   "workaround" element.

   If the announcement addresses more than one problem (Section 13.8),
   the element contains "rlist" elements each providing target group-
   specific textual descriptions within its "rli" (Section 10.5.4)
   elements.  Each "rlist" is specific to the target group referenced by
   its "tg-ref" attribute.  The "rli" elements within a single rlist
   address the different problems, referenced by the "problem-ref"
   attribute of "rli".

   This element is OPTIONAL in an announcement.









Goebel                                                        [Page 116]

                               CAIF Format                 November 2005


   Synopsis:

           <workaround>
             (<body>...</body>
              {<body>...</body>}|
              <rlist>...</rlist>
              {<rlist>...</rlist>})
           </workaround>

13.17.  The "solution" Element

   This element contains information about a more or less final
   solution, i.e. a patch or a new version of an affected system.

   The element contains either one or multiple "body" (Section 10.4) or
   "rlist" (Section 10.5) elements.  A mixed use of these elements is
   neither allowed nor sensible.

   If the announcement describes a single problem, the element contains
   "body" elements each providing textual descriptions of the solution
   specific to the target group (Section 13.2.1) referred by the "tg-
   ref" attribute and an OPTIONAL title string to the section that is
   definded by the "solution" element.

   If the announcement addresses more than one problem (Section 13.8),
   the element contains "rlist" elements each providing target group-
   specific textual descriptions within its "rli" (Section 10.5.4)
   elements.  Each "rlist" is specific to the target group referenced by
   its "tg-ref" attribute.  The "rli" elements within a single rlist
   address the different problems, referenced by the "problem-ref"
   attribute of "rli".

   This element is OPTIONAL in an announcement.

   Synopsis:

           <solution>
             (<body>...</body>
              {<body>...</body>}|
              <rlist>...</rlist>
              {<rlist>...</rlist>})
           </solution>

13.18.  The "arbitrary" Element

   This element provides CAIF's mechanism to extend the format on a per-
   document basis.  It has the attribute "name" that defines the name
   under which the element can be identified within the document.  The



Goebel                                                        [Page 117]

                               CAIF Format                 November 2005


   OPTIONAL attribute "extends" contains the name of an existing CAIF
   element (Section 13), or the "name" of another "arbitrary" element,
   thus indicating a relationship to this element.

   So, if the set of elements in CAIF is not sufficient, issuers can use
   this mechanism to either extend existing elements with new
   (sub-)elements or create completely new element groups.  Of course,
   processing software is limited in its capabilities of parsing such
   elements: it is not possible to tell the parser the sematics of the
   new elements.  Therefore it is very important to choose self-
   explanatory names for "arbitrary" elements.

   The element contains either one or multiple "body" (Section 10.4) or
   "rlist" (Section 10.5) elements.  A mixed use of these elements is
   neither allowed nor sensible.

   If the announcement describes a single problem, the element contains
   "body" elements each providing textual descriptions specific to the
   target group (Section 13.2.1) referred by the "tg-ref" attribute and
   an OPTIONAL title string to the section that is definded by the
   "arbitrary" element.

   If the announcement addresses more than one problem (Section 13.8),
   the element contains "rlist" elements each providing target group-
   specific textual descriptions within its "rli" (Section 10.5.4)
   elements.  Each "rlist" is specific to the target group referenced by
   its "tg-ref" attribute.  The "rli" elements within a single rlist
   address the different problems, referenced by the "problem-ref"
   attribute of "rli".

   This element is OPTIONAL in an announcement and may occur multiple
   times in a CAIF document.

   Synopsis:

           <arbitrary name="..."
                      [extends="..."]>
             (<body>...</body>
              {<body>...</body>}|
              <rlist>...</rlist>
              {<rlist>...</rlist>})
           </arbitrary>









Goebel                                                        [Page 118]

                               CAIF Format                 November 2005


   Example:

           <arbitrary name="vendor-status"
                      extends="workaround">
             <body tg-ref="en-admin en-user">
               The vendor has received a detailed description of the
               vulnerability as well as proof-of-concept code for its
               exploitation on 2004-01-15.
             </body>
           </arbitrary>

   This "arbitrary" element is called "vendor-status" and belongs to the
   element "workaround".

   Note, that the definition of this element allows to extend every pre-
   definded element (i.e. elements that are defined in CAIF's DTD
   Appendix C) within a document, since there is no restriction on the
   value of its "extends" attribute.  Consequently it is also possible
   to extend structuring elements (Section 10) like "body"
   (Section 10.4) or "rlist" (Section 10.5) or other elements that may
   occur more than one time within a document.  If such elements are
   extended by the "arbitrary" element, a problem may arise when
   rendering the announcement: if there is only one "arbitrary" element
   extending an element that has many instances within the document,
   does it apply to all these instances, or only to one?  If the latter
   is assumed, to which instance does it apply?

   The intention of the "arbitrary" element is to allow authors to add
   extra sections (Section 8) to a document if the set of predefined
   elements defining the sections (Section 13) is not sufficient.
   Consequently only such elements SHOULD be extended to create a sort
   of sub- to super-element relationship.  As mentionned above, it is
   also in focus to allow the creation of hierarchies with more than one
   level or completely detached hierarchies of new elements, i.e. it is
   possible to extend other "arbitrary" elements.

   Therefore it is not possible to restrict the value space of the
   "extends" attribute to the existing section elements (Section 13)
   without loosing the ability to extend other "arbitrary" elements that
   can have freely chosen names.  Thus, the definition of "arbitrary"
   cannot inhibit the extension of a structuring or even a markup
   element.

   To avoid this problem, authors MUST NOT extend elements that occur
   more than one time within a document, i.e. only section elements
   (Section 13) and other "arbitrary" elements are allowed to be
   extended in order to restore interoperability of the documents.




Goebel                                                        [Page 119]

                               CAIF Format                 November 2005


   The following elements MAY be extended by the "arbitrary" element:

   o  identification

   o  target-groups

   o  constituencies

   o  revisions

   o  category

   o  subject

   o  summary

   o  problems

   o  affected

   o  not-affected

   o  possibly-affected

   o  determine-affectedness

   o  mitigation

   o  context

   o  description

   o  workaround

   o  solution

   o  arbitrary

   o  bibliography

   o  credits

   o  disclaimer

   o  other-documents

   o  rendered-copy




Goebel                                                        [Page 120]

                               CAIF Format                 November 2005


13.19.  The "bibliography" Element

   This element contains a list of references to related documents
   within its "bibitem" sub-elements.

   The element MAY contain multiple "body" (Section 10.4) elements that
   contain some target group specific information (especially a headline
   string) about the section, followed by at least one "bibitem"
   (Section 13.19.1) element that contains the references.

   Synopsis:

           <bibliography>
             {<body>...</body>}
             <bibitem>...</bibitem>
             {<bibitem>...</bibitem>}
           </bibliography>

13.19.1.  The "bibitem" Element

   The "bibitem" elements contain the data that refer to a -- usually
   external -- source of information, like a document or any other
   resource that the author wants to mention or cite within the
   document.

   The element MAY contain arbitrary markup text including the "elink"
   element (Section 9.3.3) that contains URIs as references to external
   resources, URIs are extremely useful for this purpose but since no
   restrictions apply to the format of the references, book titles and
   ISBN numbers MAY be used as well.

   One might think that the "bibitem" element should have the option to
   provide multi-lingual and information for multiple target groups of
   readers, thus should have the respective attributes or contain "body"
   or "rlist" items.  It does not in the same way like the other
   sections (Section 8) because the reference to an external resource
   does not have these aspects, the resource itself rather has a similar
   quality, the language it is written in as well as the target group of
   readers it is written for.  Thus, the "bibitem" element has attibutes
   to let authors provide these aspects in an announcement an make it
   possible to produce target group specific renderings with selected
   bibliographic renderings.

   Note, that besides others a target group (Section 13.2.1) may have a
   language aspect.  It is not a contradiction if a "bibitem" references
   a document that is written in a different language than the language
   of the intended target group of readers.  Since a lot of
   documentation in the IT-world is written in english it is a common



Goebel                                                        [Page 121]

                               CAIF Format                 November 2005


   practice to reference documents in english even if the announcement
   is written in another language (i.e. does not have english "target-
   groups").  It is up to the author to decide to which target group a
   given bibliographic reference shall be assigned.  Nevertheless, the
   element MUST be provided with values carefully to avoid
   inconsistencies.

   The element has the OPTIONAL attribute "name" that contains an ID
   that acts as a target for references from within the document, thus
   allows to make citations.  The "ilink" element (Section 9.3.1) is
   intended to internally cross-reference to the ID provided by the
   "name" attribute.

   The REQUIRED attribute "type" defines whether the "bibitem" element
   contains a reference to an external resource that is considered a
   "primary" source of information contributing to the document or an
   "further-reading" reference providing a link to further reading.

   If the announcement addresses more than one problem, the OPTIONAL
   "problem-ref" attribute allows to devote the reference given in the
   "bibitem" to one or more of the problems (Section 13.8) that are
   described by the overall document.

   The OPTIONAL "date" attribute contains a time-stamp according to ISO
   standards (YYYY-MM-DD {hh:mm:ss[+|-]hh}).  If the reference is an
   internet resource the time-stamp documents the moment in which the
   contents of the referred resource have been looked at by the author.
   The version of the contents in this very moment is intended to be
   referenced.  If the contents change over time, "date" tells the
   reader that a erlier version is referenced.  If an author wants to
   circumvent the problem of changing references, she can use the
   "other-document" element (Section 13.22.1) to include a copy of the
   document that shall be referenced.  Of course, copyright issues MUST
   be considered when doing so.  If the "bibitem" references a resource
   not subject to fluctuation or constant change -- like a book -- the
   date MAY contain the date if the issuing of the resource.

   The OPTIONAL attribute "tg-ref" provides one or more internal-to-
   document references to one or multiple target groups
   (Section 13.2.1).  It allows the author to include bibliographic
   references appropriate to a specific readership defined by the target
   group.

   The "const-ref" attribute allows to link the bibliographic reference
   to one or multiple specific constituencies, which is useful, when
   documents like an internal policy shall be referenced.  Like all
   constituency specific information, a bibitem having a "const-ref" can
   be stripped off the document when it is distributed outside the



Goebel                                                        [Page 122]

                               CAIF Format                 November 2005


   referenced constituency.

   The OPTIONAL "content-lang" attribute provides a language code that
   defines the language, the referenced resource is written in.

   Synopsis:

            <bibitem [name="ID"]
                     type="[primary|further-reading]"
                     [problem-ref="IDREF {IDREF}"]
                     [date="YYYY-MM-DD [hh:mm:ss(+|-)hh]"]
                     [content-lang="LANG_CODE"]
                     [tg-ref="IDREF {IDREF}"]
                     [const-ref="IDREF {IDREF}"]>
                ...
            </bibitem>

   Overall Example:

           <bibliography>
           <body headline="References"/>
            <bibitem name="MS03-041-en"
                     type="primary"
                     content-lang="en"
                     tg-ref="en-admin en-user">
                <elink
                target="http://www.microsoft.com/technet/treeview/
                ?url=/technet/security/bulletin/MS03-041.asp">
                Microsoft Security Bulletin MS03-041: Vulnerability in
                Authenticode Verification Could Allow Remote Code
                Execution (823182)
                </elink>
            </bibitem>
            <bibitem name="MS03-041-de"
                     type="primary"
                     content-lang="de">
                     tg-ref="de-admin de-user">
                <elink
                target="http://http://technet.microsoft.at/
                News_Showpage.asp?newsid=10701&secid=1502"> Microsoft
                Security Bulletin MS03-041: Sicherheitsanfaelligkeit in
                Authenticode-Ueberpruefung kann Remotecodeausfuehrung
                ermoeglichen (823182)
                </elink>
            </bibitem>
           </bibliography>





Goebel                                                        [Page 123]

                               CAIF Format                 November 2005


13.20.  The "credits" Element

   The "credits" element contains information about and references to
   individuals or organizations who have contributed to the
   announcement, e.g. who have initially discovered the problem
   described.

   The "credits" element either contains one or multiple "body"
   (Section 10.4) or "rlist" (Section 10.5) elements.  A mixed use of
   these elements is neither allowed nor sensible.

   If the announcement describes a single problem, the element contains
   "body" elements each providing textual descriptions specific to the
   target group (Section 13.2.1) referred by the "tg-ref" attribute and
   an OPTIONAL title string to the section the "credits" element
   defines.

   If the announcement addresses more than one problem (Section 13.8),
   the element contains "rlist" elements each providing target group-
   specific textual descriptions within its "rli" (Section 10.5.4)
   elements.  Each "rlist" is specific to the target group referenced by
   its "tg-ref" attribute.  The "rli" elements within a single rlist
   address the different problems, referenced by the "problem-ref"
   attribute of "rli".

   This element is OPTIONAL in an announcement.

   Synopsis:

           <credits>
             (<body>...</body>
              {<body>...</body>}|
              <rlist>...</rlist>
              {<rlist>...</rlist>})
           </credits>
















Goebel                                                        [Page 124]

                               CAIF Format                 November 2005


   Example:

           <credits>
            <rlist style="ref-text">
             <rli problem-ref="RUS-CERTAdvisory2000-04:01">
              This problem was discovered by <eref
              target="mailto:Weimer@CERT.Uni-Stuttgart.DE"> Florian
              Weimer</eref>, <eref
              target="http://CERT.Uni-Stuttgart.DE">RUS-CERT</eref>
              <rli>
              <rli problem-ref="VU#749342">
              This Problem was discovered by the University of Oulu
              Security Programming Group <elink
              target="http://www.ee.oulu.fi/research/ouspg/">
                OUSPG
              </elink>
              </rli>
            </rlist>
           </credits>

13.21.  The "disclaimer" Element

   This element is intended to contain a standard disclaimer of the
   issuer.  Since this disclaimer usually covers a whole document, it
   does not contain an "rlist" element (Section 10.5).  Nevertheless,
   since the document may be multi-lingual, the "disclaimer" element
   contains one or multiple "body" elements (Section 10.4) each
   referring to the set of target groups that are covering the same
   language.  If there are target groups that use the same language but
   different law that requires different disclaimers, the issuer can
   provide different "target-group" elements (see Section 13.2.1) which
   reflect this fact.  Then different "body" elements each providing the
   proper wording for the different target groups can be included into
   "disclaimer".

   This element is OPTIONAL in an announcement.

   Synopsis:

           <disclaimer>
             <body>...</body>
             {<body>...</body>}
           </disclaimer>








Goebel                                                        [Page 125]

                               CAIF Format                 November 2005


   Example:

           <disclaimer>
             <body tg-ref="en-admin-emp en-user-mgm"
                   headline="Disclaimer">
               This document is provided "as is".
               No Warranty applies.
             </body>
             <body tg-ref="de-admin-emp de-user-mgm"
                   headline="Haftungsausschluss">
               Die in diesem Text enthaltene Information wurde fuer
               die Mitglieder der Universitaet Stuttgart recherchiert
               und zusammengestellt.  Die Universitaet Stuttgart
               uebernimmt keinerlei Haftung fuer die Inhalte.
             </body>
           </disclaimer>

13.22.  The "other-documents" Element

   This element is a container for rendered copies of other documents
   within its "other-document" sub-elements.

   The element MAY contain multiple "body" (Section 10.4) elements that
   contain some target group specific information about the section,
   followed by at least one "other-document" (Section 13.22.1) element
   that contains the copies.

   Synopsis:

           <other-documents>
             {<body>...</body>}
             <other-document>...</other-document>
             {<other-document>...</other-document>}
           </other-documents>

13.22.1.  The "other-document" Element

   This element provides a container to include rendered copies of other
   documents related to the issue of the announcement and/or CAIF
   announcements related to the topic.  For authenticity as well as to
   circumvent the problems arising from the availability of network-
   based documents, a copy of such can be attached to an announcement
   within this element.  The element MAY occur multiple times and the
   set of these elements implements the "Other Documents" section
   (Section 8.17).

   For maximum compatibility and due to the limitation of XML documents
   to contain character data only, renderings in other formats than



Goebel                                                        [Page 126]

                               CAIF Format                 November 2005


   7-bit-ascii MUST be base64-encoded before they can be included into
   the "other-document" element.  The OPTIONAL attribute "content-type"
   can be used to define and give the parser some information about the
   format of the document included.  It SHOULD be provided in the MIME
   [5] format.  Right after the element name in the start-tag the string
   "<![CDATA[" MUST follow.  This string tells parsers to ignore the
   following content up to the string "]]>" which in turn tells the
   parser that it shall continue processing the data.  Consequently, the
   string "]]" MUST NOT appear within the enclosed document.

   The OPTIONAL attribute "description" can be used to provide the
   reader with some onformation about the content of the document
   included.

   Synopsis:

           <other-document>
             <![CDATA[
               The base64-encoded rendering of an extra document
               In this document the string "]]" MUST NOT appear.
             ]]>
           </other-document>

   This element is OPTIONAL in an announcement and MAY appear multiple
   times within its superior element each containing a rendered
   document.

13.23.  The "rendered-copies" Element

   This element pools target group specific rendered copies of the
   document.  It MUST contain at least one "rendered-copy"
   (Section 13.23.1) element that contains a rendering of the document.

   Since XML itself is not a presentation format for a document, some
   implementations of processing- and rendering-software make minor
   changes like reformatting white-space that do not alter the meaning
   of the document but destroy a cryptographic signature.  Therefore it
   is important to provide a mechanism that makes it possible to check
   the authenticity of the provided contents by (re-)distributors
   (Section 6.7), and, if applicable, to readers (Section 6.10).  By
   including one or multiple signed copies of renderings reflecting the
   different target group (Section 13.2) specific aspects -- like the
   different languages -- in an element that contains data not to be
   parsed and processed by software, this goal can be achieved.

   Of course, this form of authenticity cannot be tested mechanically
   since the reader has to compare the contents of the rendered and
   signed copy with the content of the redistributed XML document or the



Goebel                                                        [Page 127]

                               CAIF Format                 November 2005


   rendering of the redistributor, which possibly has a completely
   different look.

   Synopsis:

           <rendered-copies>
             <rendered-copy>...</rendered-copy>
             {<rendered-copy>...</rendered-copy>}
           </rendered-copies>

   The element is OPTIONAL in an announcement

13.23.1.  The "rendered-copy" Element

   This element is a container for a rendered and possibly signed copy
   of the original announcement, distributed by the issuer
   (Section 6.4).

   The element "rendered-copy" has the OPTIONAL attribute "tg-ref" that
   contains one or multiple IDs referencing to one or multiple target
   groups (Section 13.2.1), thus allowing for the provision of target
   group specific renderings (e.g. different language versions).  The
   OPTIONAL "headline" attribute can be used to provide the section with
   a headline string.

   For maximum compatibility and due to the limitation of XML documents
   to contain character data only, renderings in other formats than
   7-bit-ascii MUST be base64-encoded before they can be included into
   the "rendered-copy" element.  The OPTIONAL attribute "content-type"
   can be used to define and give the parser some information about the
   format of the document included.  It SHOULD be provided in the MIME
   [5] format.  Right after the element name in the start-tag the string
   "<![CDATA[" MUST follow.  This string tells parsers to ignore the
   following content up to the string "]]>" which in turn tells the
   parser that it shall continue processing the data.  Consequently, the
   string "]]" MUST NOT appear within the enclosed document.

   Synopsis:

           <rendered-copy [content-type="..."]
                             [tg-ref="IDREF {IDREF}"]
                             [headline="..."]>
             <![CDATA[
               The base64-encoded rendered and signed copy of the
               original announcement. In this document the string
               "]]" MUST NOT appear.
             ]]>
           </rendered-copy>



Goebel                                                        [Page 128]

                               CAIF Format                 November 2005


14.  Security Considerations

   An announcement might contain confidental material.  The secure
   transmission and storage of CAIF documents is outside the scope of
   the CAIF format specification.

   Readers want to know if announcements come from a known and
   trustworthy issuer or distributor and if they have not been altered
   by a third party.  However, to meet distributor requirements, CAIF
   documents are distributed in a presentation-independent format, and
   if the document in this format is signed, the signature does not
   verify against a rendered copy of this document.

   Therefore, the issuer MAY include a rendered and signed copy
   (Section 13.23.1) of it, preferably both in text and MIME [5] format
   (conforming to [7] or to S/MIME, to enable distribution by email).

   When creating CAIF documents distributedly (more than one
   organization is taking part in the creation process) or when
   interchanging the XML source of documents between issuers and
   redistributors, mechanisms have to be implemented, that assure the
   integrity and authenticity of the documents.  Such could be digitally
   signed canonical XML [3].  These mechanisms are not in the scope of
   CAIF.

   All parties exchanging CAIF documents who want their authenticity to
   be verifyable need to be part of the same PKI.
























Goebel                                                        [Page 129]

                               CAIF Format                 November 2005


15.  References

15.1.  Normative References

   [1]  Bray, T., Paoli, J., Sperberg-McQueen, C., and E. Maler,
        "Extensible Markup Language (XML) 1.0 (Second Edition)", W3C
        REC REC-xml-20001006, October 2000.

   [2]  World Wide Web Consortium, "Extensible Markup Language (XML)
        1.0", W3C XML, February 1998,
        <http://www.w3.org/TR/1998/REC-xml-19980210>.

   [3]  Boyer, J., "Canonical XML Version 1.0", W3C Canonical XML,
        March 2001, <http://www.w3.org/TR/2001/REC-xml-c14n-20010315>.

   [4]  "Internet Message Format", RFC 2822, 04 2001.

   [5]  Moore, K., "MIME (Multipurpose Internet Mail Extensions) Part
        Three: Message Header Extensions for Non-ASCII Text", RFC 2047,
        11 1996.

   [6]  Weimer, F. and O. Goebel, "Common Advisory Interchange Format -
        Requirements V 1.0", January 2003, <http://
        CERT.Uni-Stuttgart.DE/projects/caif/
        draft-weimer-goebel-caif-requirements.txt>.

15.2.  Informal References

   [7]   Elkins, M., Del Torto, D., Levien, R., and T. Roessler, "MIME
         Security with OpenPGP", RFC 3156, August 2001.

   [8]   Christey, S. and C. Wysopal, "Responsible Vulnerability
         Disclosure Process", draft-christey-wysopal-vuln-disclosure- 00
         (work in progress), February 2002.

   [9]   Debeaupuis, T., "Security Advisory Format",
         draft-debeaupuis-saf-00.txt (work in progress), May 1999.

   [10]  FIRST, "The Forum of Incident Response and Security Teams,
         http://www.first.org/", 1995.

   [11]  CERT/CC, "The CERT (R) Co-ordination Center,
         http://www.cert.org/", 1988.

   [12]  The MITRE Cooperation, "The Common Vulnerabilities and
         Exposures Project (CVE),  http://www.mitre.org/cve/".

   [13]  National Institute of Standards and Technology (NIST), "The



Goebel                                                        [Page 130]

                               CAIF Format                 November 2005


         iCAT Metabase,  http://icat.nist.gov/icat.cfm".

   [14]  The MITRE Cooperation, "Open Vulnerability Assessment
         Language", <http://oval.mitre.org/>.

   [15]  The Forum of Incident Response and Security Teams (FIRST), "The
         Common Vulnerability Scoring System (CVSS)",
         <http://www.first.org/cvss/>.

   [16]  Organization for the Advancement of Structured Information
         Standards, AVDL Technical Committee, "OASIS Application
         Vulnerability Description Language (AVDL)",
         <http://www.avdl.org/>.

   [17]  Cormack, A., "Writing Advisories", JANET Guidance Note JANET/
         GD/NOTE/0007, March 2002.

   [18]  Kossakowski, K., "Incident Response Capabilities",
          Dissertation am Fachbereich Informatik der Universitaet
         Hamburg, January 2000.

   [19]  The European Information Promotion Programme (EISPP), Project
         co-funded by the European Community, 5th Framework, "The EISPP
         Common Format", <http://www.eispp.org/>.



























Goebel                                                        [Page 131]

                               CAIF Format                 November 2005


Appendix A.  Glossary

A.1.  Well-Formedness

   An XML document is "well-formed" if it meets the basic rules
   (Section 7.1.2):

   o  Elements MUST be nested correctly

   o  Metacharacters MUST NOT be used in the document except in the
      appropriate places

   o  case-sensitivity is considered

   o  the document starts with the XML declaration

   o  the document contains at least the top-level element that contains
      all other elements

   o  within the top-level element appears at least one element

   o  all elements have a start tag and an end tag or are empty elements

A.2.  Validity

   An XML document is "valid" if it is well-formed (Appendix A.1) and
   matches against a Document Type Definition (Section 7.2), i.e.:

   o  the document contains the DTD or a reference to the DTD used

   o  the documents contains *only* elements defined by the DTD

   o  all elements used match the syntax defined by the DTD

   o  all elements are nested as defined by the DTD, e.g. if element "b"
      is defined as a sub-element to "a", then "b" may only appear
      within "a"

   o  the top-level element has the same name like the document type












Goebel                                                        [Page 132]

                               CAIF Format                 November 2005


Appendix B.  Keys and Standard Values

   A number of the elements in CAIF that describe a section in an
   announcement (see Section 13) and some of their sub-elements contain
   an attribute that allows the author to provide a standardized, pre-
   defined value that can be processed mechanically.  The information
   this attribute provides is additional to the textual description of
   the respective element.

   The sets of pre-definde values are intended to be a basis for
   categorization without claiming completeness or enforcing authors to
   use them.  The sets have evolved and express the experience gathered
   over time while writing announcements and classify them as well as
   looking at classifications of announcements from other issuers.

   The predefined values are chosen as generic als possible.
   Vulnerabilities, problems, or exposures have several aspects that can
   be used to categorize the information.  To minimize ambiguities and
   uncertainities it is important to be precise in describing as well as
   in dissociating the aspects.  Consequently the various keysets have
   been chosen to represent the various aspects as generic and as
   dissociated as possible.

   Common classifications like "remote code execution" that intermingle
   several aspects can be represented by the combination of the
   appropriate values of the various keysets representing the various
   aspects.

B.1.  Pre-Defined Values for the "target-group" element

   The element "target-group" (Section 13.2.1) that is intended to
   define the several aspects of a target group of readers (like the
   language and others) has the following attributes (Section 13.2.1.1)
   that may have a predefined value:

B.1.1.  The Set of Pre-Defined Values for the "tech-background"
        Attribute of the "target-group" Element

   The attribute "tech-background" categorizes the assumed technical
   abilities of the members of the target group.  When writing contents
   in an announcement this is an important aspect to achieve a maximum
   understanding of the text privided.  The "tech-background" attribute
   may have the following values:

   "admin" -- This value indicates that the reader has an average
      technical knowledge of a system administrator. "admin" is the
      default value if the attribute is omitted.




Goebel                                                        [Page 133]

                               CAIF Format                 November 2005


   "user" -- This value indicates that the reader only has technical
      knowledge and abilities of a user of the affected system(s).

   "developer" -- This value indicates that the reader has the profund
      technical background knowledge of a system developer.  This value
      is useful, e.g. if the issuer wants to provide a workaround
      (Section 13.16) to solve a problem that requires profund knowledge
      in programming or reading, changing and successfully compile buggy
      source code into a patched executable.

B.1.2.  The Set of Pre-Defined Values for the "orga-overview" Attribute
        of the "target-group" Element

   The "orga-overview" attribute provides information on the
   organizational overview a member of the intended target group has.
   within the organization an affected system is used.  The "orga-
   overview" attribute may have the following values:

   "employee" -- This value indicates that the reader has the sight of
      an average employee.  This means that the information given SHOULD
      enable the reader to evaluate the impacts of the problem for their
      area of responsibility like the systems an administrator is
      running.

   "middle-management" -- This value indicates that the reader has the
      sight of a member of the middle management.  This means that the
      information given SHOULD enable the reader to evaluate the impacts
      of the problem for their area of responsibility like a department
      or branch.

   "senior-management" -- This value indicates that the reader has the
      sight of a member of the senior management.  This means that the
      information given SHOULD enable the reader to evaluate the
      strategic impacts of the problem for their area of responsibility
      and the company or institution in toto.

B.2.  The Key Values for the "problem" element

   The "problem" element (Section 13.8.1) has the OPTIONAL sub-elements

   o  class (Section 13.8.1.1)

   o  attack-requirements (Section 13.8.1.3)

   o  impact (Section 13.8.1.5)

   o  exploit (Section 13.8.1.6)




Goebel                                                        [Page 134]

                               CAIF Format                 November 2005


   o  risk (Section 13.8.1.7)

   o  probability-of-occurrence (Section 13.8.1.8)

   o  threat (Section 13.8.1.9)

   that all have an OPTIONAL "key" attribute.  If present, each of these
   attributes contain a pre-defined value that provides a categorized
   meaning to the containing element.

   They are described in detail in the following sections.

B.2.1.  The Keyset for the "key" Attribute of the "class" Element

   For statistical reasons this set provides standard classifications of
   the issues that are described by the announcement.  The key provides
   pre-defined values to the "key" attribute of the "class" element
   (Section 13.8.1.1):

   "buffer-overflow-bug" -- the problem is an unchecked buffer that can
      be overflowed, e.g. to inject false jump-addresses into the memory
      of an affected system (Section 13.10).  This class includes "heap
      overflow bugs" and "stack overflow bugs".

   "format-string-bug" -- The problem is a format string bug.

   "insecure-configuration" -- Affected systems (Section 13.10) can be
      configured in a way that causes a security problem.

   "insecure-defaults" -- The default configuration of a system causes a
      security problem.

   "design-flaw" -- The design of a system causes a security problem.

   "implementation-flaw" -- The problem results of a simple
      implementation flaw.

   "malware" -- The problem is a piece of malware, like a bot, worm or
      virus that spreads autonomously or a root-kit that helps to
      compromise a system or any other tool to attack, compromise or
      disturb systems.

   "other" -- any other problem, that does not fit into one of the other
      categories.  This value is the default, if the attribute is
      omitted.






Goebel                                                        [Page 135]

                               CAIF Format                 November 2005


B.2.2.  The Set of Pre-Defined Values for the  "key" Attribute of the
        "attack-requirements" element

   This set provides some standard values for the "key" attribute of the
   "attack-requirements" (Section 13.8.1.3) element that describes the
   requirements an attacker would need to successfully attack an
   affected system (Section 13.10).  The set contains the following
   standard types of attack requirements:

   "local" -- the attacker MUST have interactive ("local") access to an
      affected system to perform a successful attack

   "network-group" -- the attacker MUST have authenticated access to a
      network group like an CIFS/SMB or NIS/NFS domain to successfully
      attack an affected system

   "null-session" -- it MUST be possible for an attacker to establish a
      null-session to an affected system to perform a sucessful attack

   "broadcast-domain" -- an attacker MUST have access to the network
      broadcast domain an affected system is connected to, to perform a
      successful attack

   "application-user" -- the attacker MUST be an authenticated user of
      an application an affected system runs and that is accessible via
      a network, e.g. a web application.  No other restrictions apply.

   "remote" -- the affected sytem MUST be connected to a network that is
      accessible by the attacker, no other restrictions apply, i.e. it
      is sufficient if the system is connected to the internet.

   "other" -- none of the key value applies.  If this value is chosen,
      authors SHOULD provide some text within the "attack-requirements"
      element that describes the special requirements an attacker would
      need to successfully affected system.  This value is assumed as
      default if the "key" attribute is omitted.

B.2.3.  The Set of Pre-Defined Values for the the  "key" Attribute of
        the "impact" element

   This provides standard values for the "key" of the "impact" element
   (Section 13.8.1.5).  The values describe some common impacts a
   successful attack has on an affected system.  CAIF provides the
   following types of standard impacts:







Goebel                                                        [Page 136]

                               CAIF Format                 November 2005


   "denial-of-service" -- a successful exploit of the problem results in
      a state of un-availability of a special service or the hosting IT-
      infrastructure, a so-called "Denial of Service" ("DoS") condition.

   "information-leak" -- by exploiting the problem an attacker may be
      able to access information that is protected

   "user-compromise" -- an attcker may gain the privileges of an
      unprivileged user by exploiting the problem

   "system-compromise" -- exploiting the problem an attacker may gain
      administrative privileges

   "other" -- none of the above apply.  If this value is chosen, issuers
      SHOULD provide some text within the "impact" element that
      describes the effect a successful attack has on an affected
      system.  This value is assumed as default if the "key" attribute
      is omitted.

   Note, that common terms like "remote root compromise" are not
   included within the set since such would mix up aspects that ought to
   be described by "impact" and "requirements".

B.2.4.  The Set of Pre-Defined values for the  "key" Attribute of the
        "exploit-status" Element

   These standard values for the "key" attribute of the "exploit-status"
   element (Section 13.8.1.6) describe the knowledge about the status of
   exploitation of the problem(s) described by the announcement and the
   availability of automated attack programs.  CAIF provides the
   following standard classifications:

   "unknown" -- It is not known, whether exploit code is available.
      This value is the default, if the attribute is omitted.

   "rumored" -- It is rumored that exploit code is available but the
      issuer has no evidence about its existence

   "advertised" -- the existence of exploit code has been advertised

   "observed" -- Exploits have been observed by the issuer or trusted
      parties

   "proof-of-concept" -- Code for a proof of concept has been published.
      A proof of concept is a demonstration of the successful
      exploitation of the vulnerability without providing a semi or
      fully automated attack program (i.e. malware).  Usually there is
      only very few time left before malware appears in the wild.



Goebel                                                        [Page 137]

                               CAIF Format                 November 2005


   "malware" -- An attack program is available.  Note, that worms,
      viruses and bots (e.g. actively exploiting vulnerabilities) fall
      into this category too.

B.2.5.  The Pre-Defined Values for the "key" Attribute of the "risk"
        Element

   These standard values for the "key" attribute of the "risk" element
   (Section 13.8.1.7) describe the level of the "techical risk" the
   problem described in the announcement imposes on affected systems
   (Section 13.10).  Experience shows, that few values, that are clear
   in their meaning, make an announcement more easy to understand than a
   sophisticated set of many only slightly different values that
   document the quality of the potential risk in great detail.
   Therefore, CAIF provides a list of four values that are closely
   attached to the "impact" (Section 13.8.1.5) and partly the "attack-
   requirements" (Section 13.8.1.3) necessary for a successful
   exploitation of the problem described by the announcement.  The
   following values are provided:

   "low" -- the risk imposed is low, an attack and the exploitation
      respectively of the problem causes an affected system to function
      improperly in a way that the regular operation is temporarily
      disturbed.

   "medium" -- an attack or the exploitation of the problem causes an
      affected system to function improperly in a way that the regular
      oparation is disturbed severely or terminated, e.g. the system
      changes to a denial of service status (Appendix B.2.3).

   "high" -- an attack or the exploitation of the problem may result in
      the mediate compromise via a network connection or the immediate
      local compromise of an affected system

   "very high" -- an attack or the exploitation of the problem may
      result in the immediate compromise of an affected system via a
      network connection.

B.2.6.  The Set of Pre-Defined Values for the "key" Attribute of the
        "probability-of-occurrence" Element

   This set ptovides standard values for the "key" attribute of the
   "probability-of-occurrence" element (Section 13.8.1.8).  The
   determination of the probability of the occurrence of an impact
   (Section 13.8.1.5) as the result of an attack within a specific
   constituency (Section 13.3.1) as well as the interpretation of the
   result are not trivial.  Experience shows that it is useful to
   provide only a few values that give a good clue of such a probability



Goebel                                                        [Page 138]

                               CAIF Format                 November 2005


   to the reader and make the classification a job not too hard for an
   author.  The following set of values - already known from the key set
   for the "technical risk" (Appendix B.2.5) thus not introducing a new
   system of value graduation, although the values have different
   meanings - is provided by CAIF.

   "low" -- The probability of the occurrence of a successful attack is
      low according the distributor's policy, e.g. around 0 to 0.1.

   "medium" -- The probability of the occurrence of a successful attack
      is medium according the distributor's policy, e.g. around 0.1 to
      0.25.

   "high" -- The probability of the occurrence of a successful attack is
      high according the distributor's policy, e.g. around 0.25 to 0.5.

   "very high" -- The probability of the occurrence of a successful
      attack is very high according the distributor's policy, e.g.
      higher than 0.5.

   Note, that the assessment provided by the "probability-of-occurrence"
   (Section 13.8.1.8) is specific to a constituency.

   Issuers SHOULD provide a document that describes the policy of how
   classification is done and how the meaning of these values is to be
   interpretetd.  The community of announcement issuers shoud adopt
   standards as they evolve.

B.2.7.  The Set of Pre-Defined Values for the  "key" Attribute of the
        "threat" Element

   The set of four pre-defined values for the "key" attribute is
   intended to help estimate the "threat" (Section 13.8.1.9) a problem
   imposes on a given constituency (Section 13.3.1).  In CAIF's
   terminology the "threat" is a compilation of "risk"
   (Section 13.8.1.7) and "probability-of-occurrence" (Section 13.8.1.8)
   to express the actual situation within the constituency to which it
   refers in terms of the urgency to act upon it.  In order to keep the
   system of value graduation intoduced by the key set for the technical
   risk (Appendix B.2.5) the following pre-defined values are
   maintained:

   "low" -- The regular operation of the constituency's IT
      infrastructure is threatened slightly.  The solution of the
      problem (Section 8.13) is recommended.






Goebel                                                        [Page 139]

                               CAIF Format                 November 2005


   "medium" -- The regular operation of the constituency's IT
      infrastructure is moderately thratened.  The solution to the
      problem should be applied urgently.

   "high" -- The regular operation of the constituency's IT
      infrastructure is highly threatened.  The solution to the problem
      MUST be applied urgently, intermediate countermeasures or
      workarounds like the temporary suspension of the operation of
      affected systems or the deployment of restricting firewall rules
      are recommended.

   "very high" -- The bare operation of the constituency's IT
      infrastructure is threatened.  The solution to the problem MUST be
      applied immediately, intermediate countermeasures or workarounds
      like the temporary suspension of the operation of affected systems
      are required to provide protection until the problem is solved.



































Goebel                                                        [Page 140]

                               CAIF Format                 November 2005


Appendix C.  The Document Type Definition (DTD) of CAIF

   <!--
      ================================================================

                Common Announcement Interchange Format (CAIF)
                         Document Type Definition

                               Version  1.2
                               (Revision 2)

                                2005-11-06

                              Oliver  Goebel

                                 RUS-CERT
                           Stuttgart University

                           Breitscheidstrasse 2
                            D-70174 Stuttgart
                                 Germany

                         Phone: +49-711-121-3678
                         Fax:   +49-711-121-3688
                         Email: goebel@caif.info

                      Copyright (C) Oliver Goebel,
                      The CAIF Project  2002-2005.
       All Rights Reserved. Distribution of this DTD is unlimited.

     This DTD specifies the Syntax of a standardized format for
     security announcements aka advisories. It shall enable
     announcement issuers to easily exchange and automatically process
     such in order to render and specially taylor such for a given
     constituency. It is designed to provide multi-lingual information
     for more than one target group of readers in a single document,
     e.g to allow for rendering several mono-lingual presentations
     containing the information for one target group.

     The format is extensible to flexibly reflect different
     announcement formats. It can be used to store different formats
     and normalize them to allow comparability and distill normalized
     information.

     =================================================================
    -->





Goebel                                                        [Page 141]

                               CAIF Format                 November 2005


   <!-- ************* Data types used in this DTD *******************

        LANG-CODE  the lang_code definition according to RFC1766

        UTEXT      text without markup in elements (character data)

        ATEXT      attribute text (character data)

        MTEXT      markup text

        NUMBER     [0-9]+

        DATE       a timestamp, format: YYYY-MM-DD {hh:mm:ss[+|-]hh}

        URI        Uniform Ressource Identifier, e.g. an URL like
                   "https://CERT.Uni-Stuttgart.DE/projects/caif/"

        VERSIONNUMBER      has the format nn.nn

        ALIGNTYPES         for tables

        TECH-BACKGROUND    the technical background of readers

        ORGA-OVERVIEW      the organizational overview of readers

        REQUIREMENT-KEYS   predefined values to express
                           attack requirements

        IMPACT-KEYS        predefined values for some standard
                           impacts

        CLASS-KEYS         predefined values for some standard
                           problem classes

        EXPLOIT-KEYS       predefined values for the exploit
                           status

        ASSESSMENT-KEYS    predefined standard values for the
                           various assessments

        LIST-STYLE-KEYS    styles for lists

        RLIST-STYLE-KEYS   styles for refefenced lists

        MENUSTYLE-KEYS     types for menus

        FILETYPE-KEYS      types of files




Goebel                                                        [Page 142]

                               CAIF Format                 November 2005


        URGENCY-KEYS       predefined urgency values for the 'type'
                           element

        LEVEL-KEYS         predefined level values for the 'type'
                           element

        FLAVOR-KEYS        predefined flavor levels for the 'type'
                           element

        RESTRICTION-KEYS   predefinded values describing the
                           restrictions for publishing the announcement

        CONTENT-KEYS       predefined values for the content of several
                           elements indicating wether it should be
                           parsed or not

        REASON-KEYS        predefined values indivcating the reason of
                           a re-issueing of an announcement

        BIBTYPE-KEYS       types of references to external documents for
                           further reading

       *************************************************************
    -->


   <!ENTITY % LANG-CODE    "NMTOKEN">

   <!ENTITY % UTEXT        "#PCDATA">

   <!ENTITY % ATEXT        "CDATA">

   <!ENTITY % DATE         "CDATA">

   <!ENTITY % NUMBER       "CDATA">

   <!ENTITY % PERCENT      "CDATA">

   <!ENTITY % URI          "CDATA">

   <!ENTITY % MTEXT        "(
                           %UTEXT;               |
                           p                     |
                           b                     |
                           vb                    |
                           em                    |
                           pre                   |
                           vendor                |



Goebel                                                        [Page 143]

                               CAIF Format                 November 2005


                           code                  |
                           program               |
                           service               |
                           protocol              |
                           sys-feat              |
                           file                  |
                           terminal              |
                           user                  |
                           output                |
                           menu                  |
                           list                  |
                           table                 |
                           ilink                 |
                           elink                 |
                           const                 |
                           aff                   |
                           update
                           )*"
   >

   <!-- Note that the entity MTEXT does not contain rlists (see below)
     -->

   <!ENTITY % VERSIONNUMBER        "CDATA">

   <!ENTITY % ALIGNTYPES   "(
                           right                 |
                           left                  |
                           top                   |
                           bottom                |
                           center
                           )"
   >

   <!ENTITY % TECH-BACKGROUND
                           "(
                           admin                 |
                           user                  |
                           developer
                           )"
   >

   <!ENTITY % ORGA-OVERVIEW
                           "(
                           employee              |
                           middle-management     |
                           senior-management
                           )"



Goebel                                                        [Page 144]

                               CAIF Format                 November 2005


   >

   <!ENTITY % REQUIREMENTS-KEYS
                          "(
                          local                  |
                          network-group          |
                          null-session           |
                          broadcast-domain       |
                          application-user       |
                          remote                 |
                          other
                          )"
   >

   <!ENTITY % IMPACT-KEYS "(
                          denial-of-service      |
                          information-leak       |
                          data-manipulation      |
                          user-compromise        |
                          system-compromise      |
                          other
                          )"
   >

   <!ENTITY % CLASS-KEYS  "(
                          buffer-overflow-bug    |
                          format-string-bug      |
                          insecure-configuration |
                          insecure-defaults      |
                          design-flaw            |
                          implementation-flaw    |
                          malware                |
                          other
                          )"
   >

   <!ENTITY % EXPLOIT-KEYS
                          "(
                          unknown                |
                          rumored                |
                          advertised             |
                          observed               |
                          proof-of-concept       |
                          malware
                          )"
   >

   <!ENTITY % ASSESSMENT-KEYS



Goebel                                                        [Page 145]

                               CAIF Format                 November 2005


                          "(
                          low                    |
                          medium                 |
                          high                   |
                          very-high
                          )"
   >

   <!ENTITY % LIST-STYLE-KEYS
                          "(
                          numbers                |
                          symbols                |
                          empty
                          )"
   >

   <!ENTITY % RLIST-STYLE-KEYS
                          "(
                          numbers                |
                          symbols                |
                          ref-text               |
                          empty
                          )"
   >


   <!ENTITY % MENUSTYLE-KEYS
                          "(
                          pull-down             |
                          pull-up               |
                          pop-up                |
                          window                |
                          tab                   |
                          tree                  |
                          input                 |
                          button
                          )"
   >


   <!ENTITY % FILETYPE-KEYS
                         "(
                         text                  |
                         log                   |
                         config                |
                         source                |
                         binary
                         )"



Goebel                                                        [Page 146]

                               CAIF Format                 November 2005


   >


   <!ENTITY % URGENCY-KEYS
                         "(
                         alert                 |
                         warning               |
                         advisory              |
                         informational
                         )"
   >


   <!ENTITY % LEVEL-KEYS
                        "(
                        brief                  |
                        full                   |
                        digest                 |
                        other
                        )"
   >


   <!ENTITY % FLAVOR-KEYS
                        "(
                        vulnerability-description |
                        patch-notification        |
                        heads-up                  |
                        other
                        )"
   >



   <!ENTITY % CONTENT-KEYS
                        "(
                        base64                   |
                        parsed
                        )"

   >

   <!ENTITY % REASON-KEYS
                        "(
                        exploit                  |
                        risk                     |
                        patch                    |
                        other



Goebel                                                        [Page 147]

                               CAIF Format                 November 2005


                        )"
   >

   <!ENTITY % BIBTYPE-KEYS
                        "(
                        primary                  |
                        further-reading
                        )"
   >


   <!-- *****************  Mark-up elements ********************** -->


   <!ELEMENT em            %MTEXT;>

   <!ELEMENT b             %MTEXT;>

   <!ELEMENT vb            %MTEXT;>

   <!ELEMENT pre           (%UTEXT;)>

   <!ELEMENT vendor        %MTEXT;>

   <!ELEMENT code          (%UTEXT;)>

   <!ELEMENT program       (%UTEXT;)>

   <!ELEMENT service       (%UTEXT;)>

   <!ELEMENT protocol      (%UTEXT;)>

   <!ELEMENT sys-feat      (%UTEXT;)>

   <!ELEMENT file          (%UTEXT;)>
   <!ATTLIST file
           path            %ATEXT;             #IMPLIED
           type            %FILETYPE-KEYS;     #IMPLIED
   >

   <!ELEMENT output        (%UTEXT;)>

   <!ELEMENT user          (%UTEXT;)>
   <!ATTLIST user
           prompt           %ATEXT;            #IMPLIED
           >

   <!ELEMENT terminal      %MTEXT;>



Goebel                                                        [Page 148]

                               CAIF Format                 November 2005


   <!ELEMENT menu          %MTEXT;>
   <!ATTLIST menu
           style           %MENUSTYLE-KEYS;    #REQUIRED
           title           %ATEXT;             #IMPLIED
           >

   <!ELEMENT const         %MTEXT;>
   <!ATTLIST const
           ref             IDREFS              #REQUIRED
           >

   <!ELEMENT aff           %MTEXT;>
   <!ATTLIST aff
           id              ID                  #REQUIRED
           >

   <!-- ....................... update .......................... -->

   <!ELEMENT update        (
                           invalid?
                           )
   >
   <!ATTLIST update
             version       %VERSIONNUMBER;     #REQUIRED
   >
   <!ELEMENT invalid       %MTEXT;>

   <!-- ....................  paragraph .......................... -->

   <!ELEMENT p             %MTEXT;>


   <!-- ..................... table .............................. -->

   <!ELEMENT table         (
                           p?,
                           tr+,
                           p?
                           )
   >


           <!-- ..... sub-elements to table ..... -->

           <!ELEMENT tr    (
                   td+
                   )
           >



Goebel                                                        [Page 149]

                               CAIF Format                 November 2005


           <!-- ..... sub-elements to tr ..... -->

                   <!ELEMENT td
                                           %MTEXT;
                   >
                   <!ATTLIST td
                           align           %ALIGNTYPES;    #IMPLIED
                           colspan         %NUMBER;        #IMPLIED
                   >


   <!-- ........................ list ........................... -->

   <!ELEMENT list          (
                           p?,
                           li+,
                           p?
                           )
   >
   <!ATTLIST list
           style           %LIST-STYLE-KEYS;      "symbols"
   >

   <!-- .................. list item ........................... -->

   <!ELEMENT li            %MTEXT;>



   <!-- *** Elements for structured and referenced formatting ***  -->

   <!-- ...................... body .......................... -->

   <!ELEMENT body  %MTEXT;>
   <!ATTLIST body
             tg-ref        IDREFS                  #IMPLIED
             headline      %ATEXT;                 #IMPLIED
   >


   <!-- ...................... rlist ......................... -->

   <!ELEMENT rlist         (
                           p?,
                           rli+,
                           p?
                           )
   >



Goebel                                                        [Page 150]

                               CAIF Format                 November 2005


   <!ATTLIST rlist
             tg-ref        IDREFS                  #IMPLIED
             headline      %ATEXT;                 #IMPLIED
             style         %RLIST-STYLE-KEYS;      "numbers"
   >


   <!-- .................. rlist item ........................ -->


   <!ELEMENT rli           %MTEXT;
             >
   <!ATTLIST rli
             problem-ref   IDREFS                  #IMPLIED
             >

   <!-- ............ document internal reference ............ -->

   <!ELEMENT ilink         (%UTEXT;)>
   <!ATTLIST ilink
             target        IDREF                   #REQUIRED
             >


   <!-- ........the target to which the ilink points ........ -->

   <!ELEMENT itarget       EMPTY
             >
   <!ATTLIST itarget
             name          ID                      #REQUIRED
             >

   <!-- ............ External reference ..................... -->

   <!ELEMENT elink         (%UTEXT;)>
   <!ATTLIST elink
             target        %URI;                   #REQUIRED
             >

   <!-- +++++++++++++++++++++++++++++++++++++++++++++++++++++++++ -->
   <!--               the over all format                         -->
   <!-- +++++++++++++++++++++++++++++++++++++++++++++++++++++++++ -->


   <!ELEMENT caif (

           identification,
           target-groups?,



Goebel                                                        [Page 151]

                               CAIF Format                 November 2005


           constituencies?,
           revisions,
           category,
           subject,
           summary,
           problems?,
           affected?,
           not-affected?,
           possibly-affected?,
           determine-affectedness?,
           mitigation?,
           context?,
           description?,
           workaround?,
           solution?,
           arbitrary*,
           bibliography?,
           credits?,
           disclaimer*,
           other-documents?,
           rendered-copies?
           )
   >

   <!-- +++++++++++++++++++++++++++++++++++++++++++++++++++++++++ -->
   <!--                     the elements                          -->
   <!-- +++++++++++++++++++++++++++++++++++++++++++++++++++++++++ -->

   <!-- ................... identification ...................... -->


   <!ELEMENT identification (
           issuer,
           announcement,
           type,
           author*,
           distribution-allowed?,
           earliest-release?
           )

   >

       <!-- - - - - subelements to identification - - - - -->

           <!ELEMENT issuer        (%UTEXT;)>
           <!ATTLIST issuer
                          id       %ATEXT;         #REQUIRED
           >



Goebel                                                        [Page 152]

                               CAIF Format                 November 2005


           <!-- a unique format could be: number = $issuer_id#number,
           e.g.  RUS-CERT#1220 -->

           <!ELEMENT announcement                  EMPTY>
           <!ATTLIST announcement
                   id     %NUMBER;                 #REQUIRED
           >

           <!ELEMENT type          (body+)>
           <!ATTLIST type
                   urgency         %URGENCY-KEYS;  #IMPLIED
                   level           %LEVEL-KEYS;    "other"
                   flavor          %FLAVOR-KEYS;   "other"
           >

           <!ELEMENT author        (%UTEXT;)>
           <!ATTLIST author
                   initials        %ATEXT;         #IMPLIED
                   surname         %ATEXT;         #IMPLIED
                   e-mail          %URI;           #IMPLIED
           >


           <!ELEMENT distribution-allowed  EMPTY>
           <!ATTLIST distribution-allowed
                   const-ref       IDREFS          #REQUIRED
           >

           <!ELEMENT earliest-release   (%UTEXT;)>
           <!ATTLIST earliest-release
                   date            %DATE;          #REQUIRED
           >

   <!-- ................... target-groups ....................... -->

   <!ELEMENT target-groups (target-group+)
   >

   <!-- ................... target-group ........................ -->
   <!ELEMENT target-group          %MTEXT;>
   <!ATTLIST target-group
           id                      ID                   #REQUIRED
           lang                    %LANG-CODE;          #REQUIRED
           tech-background         %TECH-BACKGROUND;    "admin"
           orga-overview           %ORGA-OVERVIEW;      #IMPLIED
           environment             %ATEXT;              #IMPLIED
           headline                %ATEXT;              #IMPLIED
   >



Goebel                                                        [Page 153]

                               CAIF Format                 November 2005


   <!-- .................. constituencies ....................... -->

   <!ELEMENT constituencies (constituency+)
   >

           <!ELEMENT constituency  (
                   body+
                   )
           >
           <!ATTLIST constituency
                   id              ID              #REQUIRED
           >

   <!-- ..................... revisions ......................... -->

   <!ELEMENT revisions     (

           body*,
           issued,
           re-issued*,
           revision*
           )
   >

       <!-- - - - -  Subelements to revisions  - - - -  -->

           <!ELEMENT issued        EMPTY>
           <!ATTLIST issued
                   version         %VERSIONNUMBER; #REQUIRED
                   date            %DATE;          #REQUIRED
           >
           <!ELEMENT re-issued     (body+)>
           <!ATTLIST re-issued
                   version         %VERSIONNUMBER; #REQUIRED
                   date            %DATE;          #REQUIRED
                   reason          %REASON-KEYS;   "other"
           >

           <!ELEMENT revision      (body+)>
           <!ATTLIST revision
                   version         %VERSIONNUMBER; #REQUIRED
                   date            %DATE;          #REQUIRED
           >


   <!-- ..................  category ........................... -->

   <!ELEMENT category       EMPTY>



Goebel                                                        [Page 154]

                               CAIF Format                 November 2005


   <!ATTLIST category
           platform         %ATEXT;                #REQUIRED
           product          %ATEXT;                #IMPLIED
           protocol         %ATEXT;                #IMPLIED
   >



   <!-- ................... subject ............................ -->


   <!ELEMENT subject        (body+)>


   <!-- .................... summary ........................... -->


   <!ELEMENT summary        (body+)>


   <!-- ................... problems ........................... -->


   <!ELEMENT problems      (
                           body*,
                           problem+
                           )
   >

           <!-- - - - - Subelements to problems - - - - -->

           <!ELEMENT problem   (
                               body+,
                               class?,
                               attack-vector?,
                               attack-requirements?,
                               attack-signature?,
                               impact?,
                               exploit-status?,
                               risk?,
                               probability-of-occurrence*,
                               threat*
                               )
           >
           <!ATTLIST problem
                   id          ID                  #IMPLIED
           >




Goebel                                                        [Page 155]

                               CAIF Format                 November 2005


           <!-- sub-elements to problem -->

           <!ELEMENT class (
                           body*
                           )
           >

           <!ATTLIST class
                   key     %CLASS-KEYS;         "other"
           >



           <!ELEMENT attack-vector
                           (
                           body+
                           )
           >

           <!ELEMENT attack-requirements
                           (
                           body*
                           )
           >
           <!ATTLIST attack-requirements
                   key     %REQUIREMENTS-KEYS;  "other"
           >

           <!ELEMENT attack-signature
                           (
                           body+
                           )
           >
           <!ATTLIST attack-signature
                   type     %ATEXT;            #IMPLIED
           >


           <!ELEMENT impact
                           (
                           body*
                           )
           >
           <!ATTLIST impact
                   key     %IMPACT-KEYS;       "other"
           >





Goebel                                                        [Page 156]

                               CAIF Format                 November 2005


           <!ELEMENT exploit-status
                           (
                           body*
                           )
           >
           <!ATTLIST exploit-status
                   key     %EXPLOIT-KEYS;      "unknown"
           >



           <!ELEMENT risk
                           (
                           body*
                           )
           >
           <!ATTLIST risk
                   key     %ASSESSMENT-KEYS;       #IMPLIED
                   policy  %ATEXT;                 #IMPLIED
           >




           <!ELEMENT probability-of-occurrence
                           (
                           body*
                           )
           >
           <!ATTLIST probability-of-occurrence
                   const-ref
                           IDREFS                  #IMPLIED
                   key     %ASSESSMENT-KEYS;       #IMPLIED
                   policy  %ATEXT;                 #IMPLIED
           >



           <!ELEMENT threat
                           (
                           body*
                           )
           >
           <!ATTLIST threat
                   const-ref
                           IDREFS                  #IMPLIED
                   key     %ASSESSMENT-KEYS;       #IMPLIED
                   policy  %ATEXT;                 #IMPLIED



Goebel                                                        [Page 157]

                               CAIF Format                 November 2005


           >


   <!-- .....................mitigation......................... -->


   <!ELEMENT mitigation    (
                           body+   |
                           rlist+
                           )
   >

   <!-- ...................  affected  ......................... -->


   <!ELEMENT affected      (
                           body+   |
                           rlist+
                           )
   >

   <!-- ...................  not-affected  ..................... -->



   <!ELEMENT not-affected  (
                           body+   |
                           rlist+
                           )
   >

   <!-- .................  possibly-affected ................... -->



   <!ELEMENT possibly-affected (
                           body+   |
                           rlist+
                           )
   >


   <!-- ................determine-affectedness.................. -->

   <!ELEMENT determine-affectedness (
                           detitem+
                           )
   >



Goebel                                                        [Page 158]

                               CAIF Format                 November 2005


   <!ELEMENT detitem       (
                           body+
                           )
   >

   <!ATTLIST detitem
           method          %ATEXT;                #IMPLIED
           aff-ref         IDREFS                 #REQUIRED
           problem-ref     IDREFS                 #IMPLIED
           content-type    %CONTENT-KEYS;         #IMPLIED
   >

   <!-- ..................... context .......................... -->

   <!ELEMENT context       (
                           body+   |
                           rlist+
                           )
   >

   <!-- .................. description ......................... -->

   <!ELEMENT description   (
                           body+   |
                           rlist+
                           )
   >

   <!-- .................. workaround .......................... -->

   <!ELEMENT workaround    (
                           body+   |
                           rlist+
                           )
   >

   <!-- ................... solution ........................... -->

   <!ELEMENT solution      (
                           body+   |
                           rlist+
                           )
   >

   <!-- .................. arbitrary ........................... -->

   <!ELEMENT arbitrary     (
                           body+   |



Goebel                                                        [Page 159]

                               CAIF Format                 November 2005


                           rlist+
                           )
   >
   <!ATTLIST arbitrary
           name            ID                      #REQUIRED
           extends         %ATEXT;                 #IMPLIED
   >

   <!-- ................... bibliography ....................... -->

   <!ELEMENT bibliography  (
                           body*,
                           bibitem+
                           )
   >


   <!ELEMENT bibitem       %MTEXT;>
   <!ATTLIST bibitem
           name            ID                      #IMPLIED
           type            %BIBTYPE-KEYS;          #REQUIRED
           problem-ref     IDREFS                  #IMPLIED
           date            %DATE;                  #IMPLIED
           content-lang    %LANG-CODE;             #IMPLIED
           tg-ref          IDREFS                  #IMPLIED
           const-ref       IDREFS                  #IMPLIED
   >
   <!--
     bibtem's attribute "content-lang" describes the language of the
     referenced resource
     -->

   <!-- .................... credits ........................... -->

   <!ELEMENT credits     (
                         body+     |
                         rlist+
                         )
   >

   <!-- .................. disclaimer .......................... -->

   <!ELEMENT disclaimer (
                        body+
                        )
   >

   <!-- .................. other-documents ....................  -->



Goebel                                                        [Page 160]

                               CAIF Format                 November 2005


   <!ELEMENT other-documents (
                        body*,
                        other-document+
                        )
   >

   <!ELEMENT other-document (%UTEXT;)>
   <!ATTLIST other-document
           content-type    %ATEXT;                 #IMPLIED
           description     %ATEXT;                 #IMPLIED
   >

   <!-- .................. rendered copy ....................  -->

   <!ELEMENT rendered-copies (
                        rendered-copy+
                        )
   >

   <!ELEMENT rendered-copy (%UTEXT;)>
   <!ATTLIST rendered-copy
           content-type    %ATEXT;                 #IMPLIED
           tg-ref          IDREFS                  #IMPLIED
           headline        %ATEXT;                 #IMPLIED
   >

   <!-- ......................... END ....................... -->
























Goebel                                                        [Page 161]

                               CAIF Format                 November 2005


Appendix D.  Acknowledgements

   The author gratefully acknowledges the contributions of:

   o  Friedemann Bauer (RUS-CERT),

   o  Andrew Cormack (UKERNA),

   o  Hans de Vries (TU Delft),

   o  Tom Fischer (RUS-CERT),

   o  Anselm Garbe (RUS-CERT),

   o  Igor Gilitschenski (RUS-CERT),

   o  Detlef Guenther (CERT-VW),

   o  Michael Hartmann (SAP),

   o  Tim Heinken (CERT-VW),

   o  Damir Rajnovic (CISCO-PSIRT),

   o  Joachim Ring (ComCERT),

   o  Rolf Schulz (GNSec),

   o  Kurt Seifried,

   o  Helmut Springer,

   o  Florian Weimer (RUS-CERT),

   o  and Hans Ulmer (SAP-CERT)
















Goebel                                                        [Page 162]

                               CAIF Format                 November 2005


Author's Address

   Oliver Goebel
   The CAIF Project
   RUS-CERT, Stuttgart University
   Breitscheidstrasse 2
   70174 Stuttgart
   DE

   Phone: +49 711 121 3678
   Fax:   +49 711 121 3688
   Email: goebel@caif.info







































Goebel                                                        [Page 163]