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]