<?xml version="1.0" encoding="iso-8859-1"?>

<!--=====================================================================-->
<!--=====DAF Advisory Format DTD, version 1.1                          ==-->
<!--=====                                                              ==-->
<!--===== XML-files compliant to this DTD should be marked as          ==-->
<!--===== 'daf-1.1' within the version attribute of the                ==-->
<!--===== top-level element 'EISPPAdvisory'.                           ==-->
<!--=====                                                              ==-->
<!--===== DAF v1.1 is based on EISPP advisory format v2.0 with slight  ==-->
<!--===== extension in 'Description' element.                          ==-->
<!--=====                                                              ==-->
<!--===== DAF v1.1 is backward compatible to EISPP2.0 in the sense     ==-->
<!--===== that a XML-file that conforms to the EISPP2.0-DTD also       ==-->
<!--===== conforms to the DAF1.1-DTD.                                  ==-->
<!--=====                                                              ==-->
<!--=====                                                              ==-->
<!--=====See http://www.cert-verbund.de/daf/daf_description.html       ==-->
<!--=====for details.                                                  ==-->
<!--=====================================================================-->


<!--===================Change History ===================================-->

<!-- Changes:

     v1.1: A few small errors had crept into DAF1.0 which have been
           corrected in DAF1.1:

           - missing definition of element 'Description'
           - double definition of element 'attack_requirements'
           - missing attribute 'ref_subtype' in element 'ref_type'

-->
<!--===================Change History ===================================-->


<!--================== Type Definitions =================================-->

<!-- Here, we specify data types used within attribute values.
     
     Possible values of an attribute can be constrained in three ways:

     - by specifying a 'list of values' (LOV):
    
       Using the means of XML-DTDs, we can specify a list of possible values
       such that a validating XML parser can check within the document, whether
       the given value is contained in the LOV. Such definitions are provided
       below.

     - by specifing an 'open lists of values' (oLOV):
 
       In cases, where a list of values is likely to be extended, 
       we speak of an open list of values. There is little sense
       in constraining such a list within the DTD, because a validating
       XML parser would not be able to deal with extensions. Therefore,
       we 
         - declare the attribute value to be of type 'oLOV' (which is
           equivalent to NMTOKEN, the definition is provided below)
      
         - and specify the currently supported/recognized values in
           some extra documentation

    - By specifying some other rules values must comply with:

      In many cases, also open lists of values will not be flexible enough.
      As an example, consider a date string of form 'yyyy-mm-dd', which could,
      for example, be specified using regular expressions. Since DTDs do not
      give us the means to make such specifications, we give the rules/grammars
      in comments within the DTD. Writers of applications that process
      advisories should then take care that these rules are enforced when 
      writing advisories.

-->

<!-- ======== First, the type definition for open lists of values =============-->
<!-- Please refer to the comment at the end of this DTD for information 
     regarding the currently supported open lists of values -->

<!ENTITY % oLOV "NMTOKEN">


<!-- ======== Next, we specify rules for types not expressible with LOVs ======-->

<!-- The generic type for attributes that are defined using DTD-external rules
     is called 'token' -->

<!ENTITY % token "CDATA">
      

<!-- A language code, as per [RFC1766] -->

<!ENTITY % LanguageCode "CDATA">


<!-- Date information, with format yyyy-mm-dd -->

<!ENTITY % Date "CDATA">


<!--=========Finally, definitions of lists of values ==========================-->


<!--Values for generic ratings from 'very low' to 'very high'  -->
<!ENTITY % attvals.rating_attr "
   (not_rated | very_low | low | medium | high | very_high) 
 ">


<!--Values for confidence level rating  -->
<!ENTITY % attvals.confidence_rating_attr "
   (not_rated | not_qualified | probable | tested | official | official_and_tested) 
 ">

<!--Values for requirements type  -->
<!ENTITY % attvals.requirements_type_attr "
   (not_rated | remote_no_account | remote_account | victim_interaction | local | packet_access | other)
 ">

<!--Values for requirements subtype  -->
<!ENTITY % attvals.requirements_subtype_attr "
   (user | service | content | contact | interactive | physical | sniff | manipulate )
 ">


<!--Values for vuln status   -->
<!ENTITY % attvals.vuln_status_attr "
   (not_rated | theoretical | exploitable | currently_exploited | exploit_published) 
 ">

<!--Values for propagation method   -->
<!ENTITY % attvals.vuln_status_propagation_attr "
   (not_rated | manual | automated | replicating) 
 ">


<!--Values for effect   -->
<!ENTITY % attvals.loss_attr "
   (not_rated | take_control | take_partial_control | modification | disclosure | availability | circumvention) 
 ">


<!--Values for effect scope   -->
<!ENTITY % attvals.scope_attr "
   (not_rated | person | service | system | network)">


<!--Values for the relate attribute within the relation information    -->
<!ENTITY % attvals.relation_attr "
   ( complements | complemented_by | supersedes | superseded_by) 
 ">

<!--Values for the sol_type attribute within the sol_sec    -->
<!ENTITY % attvals.sol_type_attr "
   (code_fix | workaround | other)
 ">

<!--Values for the sol_subtype attribute within the sol_sec    -->
<!ENTITY % attvals.sol_subtype_attr "
   (patch | software_upgrade | other)
 ">


<!--Values for the ref_type attribute within the reference information    -->
<!ENTITY % attvals.ref_type_attr "
   (  code_fix  | advisory | technical_information | vuln_id | other )
 ">

<!--Values for the ref_subtype attribute within the reference information    -->
<!ENTITY % attvals.ref_subtype_attr "
   (  patch | software_upgrade | vendor )
 ">

<!--Values for the type attribute within the <a>-element     -->
<!ENTITY % attvals.a_type__attr "
   ( vulnerability | reference )
 ">



<!--=====================================================================-->
<!--==================Free text and formatted text=======================-->
<!--=====================================================================-->
<!--
We define two kinds of elements for storing language-dependent content:
"FreeText" for text without markup, and "FormattedText" for text with markup.

Language-dependent fields such as "Title" can have several FreeText or
FormattedText-entities as content, one for each language.

-->

<!ELEMENT FreeText (#PCDATA)>
<!ATTLIST FreeText
        xml:lang            %LanguageCode;          #IMPLIED  
>


<!-- 
Before defining what is formatted text, we need to make some
definitions: We want to be able to use a few very basic html-elements
in formatted text, namely:

 - font changes (emphasis, strong emphasis, code font)

 - linebreaks

 - paragraphs

 - lists (unnumbered, numbered, and definition lists)

 - tables (very simple ones)

 - anchors and links

--> 


<!--
 First we define some categories of markup:
 -->


<!ENTITY % heading "h1 | h2 | h3 | h4 | h5 | h6">

<!ENTITY % phrase "em | strong | code"> <!-- Font changes -->

<!ENTITY % inline "%phrase; | br | a"> <!-- Stuff within text: font change, line break and links -->

<!ENTITY % Inline "(#PCDATA | %inline;)*"> <!-- normal text -->

<!ENTITY % lists "ul | ol | dl"> <!-- unnumbered, numbered, and definition lists --> 

<!ENTITY % block "p | %heading; | %lists; | table | pre"> <!-- text blocks: paragraphs, 
                                          preformatted text, lists, and tables -->




<!ENTITY % ListBody "(#PCDATA | %lists; | %inline; | p | table | pre)*">

<!-- Now we are in a position to define formatted text: -->

<!ELEMENT FormattedText (#PCDATA | %inline; | %block;)*>
<!ATTLIST FormattedText
        xml:lang            %LanguageCode;          #IMPLIED  
>

<!-- What follows are the definitions for lists, tables, etc. -->

<!ELEMENT table (tbody)>
<!ELEMENT tbody (tr)+>
<!ELEMENT tr (th|td)+>
<!ELEMENT th %Inline;>
<!ELEMENT td %Inline;>


<!-- horizontal alignment attributes for cell contents -->
<!ENTITY % cellhalign
  "align      (left|center|right) #IMPLIED"
  >

<!-- vertical alignment attributes for cell contents -->
<!ENTITY % cellvalign
  "valign     (top|middle|bottom|baseline) #IMPLIED"
  >

<!ATTLIST tbody
  %cellhalign;
  %cellvalign;
  >

<!ATTLIST tr
  %cellhalign;
  %cellvalign;
  >


<!-- th is for headers, td for data and for cells acting as both -->

<!ATTLIST th
  rowspan     CDATA       "1"
  colspan     CDATA       "1"
  %cellhalign;
  %cellvalign;
  >

<!ATTLIST td
  rowspan     CDATA       "1"
  colspan     CDATA       "1"
  %cellhalign;
  %cellvalign;
  >




<!ELEMENT em %Inline;> <!-- emphasis -->

<!ELEMENT strong %Inline;> <!-- strong emphasis -->

<!ELEMENT code %Inline;> <!-- program code -->

<!ELEMENT br EMPTY>


<!-- Preformatted text is always understood as code, ie., it
     should be typeset with a fixed-width font. We allow no
     markup whatsoever within "pre" -->
     
<!ELEMENT pre (#PCDATA)>

<!-- In a heading we allow only font changes -->

<!ELEMENT h1  (#PCDATA | %phrase;)*>

<!ELEMENT h2  (#PCDATA | %phrase;)*>

<!ELEMENT h3  (#PCDATA | %phrase;)*>

<!ELEMENT h4  (#PCDATA | %phrase;)*>

<!ELEMENT h5  (#PCDATA | %phrase;)*>

<!ELEMENT h6  (#PCDATA | %phrase;)*>


<!-- EISPP v2.0 now also allows anchors and links within FormattedText. 
     Additionally, vulnerabilities and references can be linked to:

     The a-element has two non-standard attributes 'type' and 'iref'
     'type' can be set to 'vulnerability' or 'reference'. 

     * By setting 'type' to 'vulnerability' and 'iref' to the value given in
       a vulnerability's name-attribute (see below), a specific vulnerability
       can be referenced.

     * By setting 'type' to 'reference' and 'iref' to the value given in
       a reference's name-attribute (see below), a specific reference
       can be referred to.
 -->

<!ENTITY % URI "CDATA">

<!ELEMENT a (#PCDATA | %phrase;)*>
<!ATTLIST a
  name        NMTOKEN        #IMPLIED
  href        %URI;          #IMPLIED
  type       NMTOKEN          #IMPLIED
  iref       NMTOKEN          #IMPLIED
  >



<!-- In a paragraph we allow normal text, no lists, tables, etc. -->

<!ELEMENT p %Inline;>

<!-- Unordered list -->

<!ELEMENT ul (li)+>

<!-- Ordered (numbered) list -->

<!ELEMENT ol (li)+>

<!-- list item -->

<!ELEMENT li %ListBody;>

<!-- definition lists - dt for term, dd for its definition -->

<!ELEMENT dl (dt|dd)+>

<!ELEMENT dt %Inline;>

<!ELEMENT dd %ListBody;>








<!--=====================================================================-->
<!--================== EISPP advisory format ============================-->
<!--=====================================================================-->
<!--
Here we define the EISPP advisory format.

In its attributes we find some fields that the informal description
lists as identification data:
 - language :
   Making the language-information an attribute is standard for XML;
   putting it into the top element makes most sense. Because the
   format supports multiple-language content, the top-level language
   attribute defines the default language.

 - (EISPP-)issuer:
   Will not be displayed by most presentation-engines (which are for
   readers) and applies to the whole advisory 
    ===> attribute in top-element.

-->

<!ELEMENT EISPP-Advisory (Id_Data, 
                          History_Data?,
                          Vulnerability_Class,
                          System_Information?,
                          Description?,
                          Solution?,
                          Additional_Resources?)>

<!ATTLIST EISPP-Advisory
	version             CDATA                   #REQUIRED	
        issuer CDATA #REQUIRED
        xml:lang            %LanguageCode;          #REQUIRED
        date %Date; #IMPLIED

>


<!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
<!-- - - - - - - - -  Identification Data - - - - - - - - - - - - - - - -->
<!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->


<!ELEMENT Id_Data (ref_num, title, abstract?)>


<!-- - - - - - - - - Ref_num- - - - - - - - - - - - - - - - - - - - - - - -->
<!ELEMENT ref_num (#PCDATA)>

<!-- - - - - - - - - Title- - - - - - - - - - - - - - - - - - - - - - - -->
<!-- Here is the first occurrence of using FreeText to implement a multi-language
     feature.  -->

<!ELEMENT title (FreeText+)>

<!ELEMENT abstract (FreeText+)>

<!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
<!-- - - - - - - - -  History Data - - - - - - - - - - - - - - - - - - -->
<!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->

<!ELEMENT History_Data (version_history?, update_information?)>

<!-- - - - - - - - - version_history- - - - - - - - - - - - - - - - - - - -->
<!-- Several fields identified in the informal description make excellent
     attributes, namely:
      - version
      - date

  If we want to have multi-language features, one question is whether
  those should be used for the change_descr. Probably yes, because I might
  want to display this info also to my readers, in which case I have
  to give it in all languages that I support in my CERT. The internal
  comments, on the other hand, will be in the working language of the
  issuing CERT.
  -->

<!ELEMENT version_history (change_descr+)>

<!ELEMENT change_descr (FreeText+, internal_comment?)>
<!ATTLIST change_descr        version  CDATA  #REQUIRED
        date            %Date;        #REQUIRED  
>        

<!ELEMENT internal_comment (#PCDATA)>

<!-- - - - - - - - - update_information- - - - - - - - - - - - - - - - - - -->
<!-- Here is the first occurrence, where an element occurs that is not
     explicit in the informal description. There we find

    <update information> :== (<relation_tag> <ref_num>)* 

     What "update_pointer" does is to give a name to the group
             (<relation_tag> <ref_num>)

     We have turned the relation_tag into an attribute; it fits its
     role, and this way we can contrain it with the DTD.
 -->

<!ELEMENT update_information (update_pointer*)>

<!ELEMENT update_pointer (#PCDATA)>
<!ATTLIST update_pointer
        relation %attvals.relation_attr; "complements"
>        



<!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
<!-- - - - - - - - -  Vulnerability Classification- - - - - - - - - - - -->
<!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->


<!ELEMENT Vulnerability_Class (vulnerabilities?,current_impact?,risk_ratings?)>

<!ELEMENT vulnerabilities (vulnerability+)>


<!ELEMENT vulnerability (vuln_ids?,confidence_level?,vuln_cat?,requirements?,immediacy?,impact?,current_impact?,risk_ratings?)>
<!ATTLIST vulnerability
        name NMTOKEN  #IMPLIED
>        

<!ELEMENT vuln_ids (vuln_id+)>

<!ELEMENT vuln_id EMPTY>
<!ATTLIST vuln_id
        issuer %oLOV; #REQUIRED
	ref_num %token; #REQUIRED
>        


<!ELEMENT confidence_level (explanation?)>
<!ATTLIST confidence_level
        type %attvals.confidence_rating_attr; #IMPLIED
>        



<!ELEMENT requirements (explanation?)>
<!ATTLIST requirements
        type %attvals.requirements_type_attr; #IMPLIED
        subtype %attvals.requirements_subtype_attr; #IMPLIED
>        


<!ELEMENT vuln_cat (explanation?)>



<!ELEMENT immediacy (explanation?)>
<!ATTLIST immediacy 
        vuln_status %attvals.vuln_status_attr; #IMPLIED
        prop_method %attvals.vuln_status_propagation_attr; #IMPLIED
        rating %attvals.rating_attr; #IMPLIED
>        


<!ELEMENT impact (effects?, explanation?)>
<!ATTLIST impact
        rating %attvals.rating_attr; #IMPLIED
>        


<!ELEMENT effects (effect+)>

<!ELEMENT effect EMPTY>
<!ATTLIST effect
        loss %attvals.loss_attr; #REQUIRED
        scope %attvals.scope_attr; #IMPLIED
>        



<!ELEMENT current_impact (explanation?)>
<!ATTLIST current_impact
        rating %attvals.rating_attr; #REQUIRED
>        


<!ELEMENT risk_ratings (risk+)>

<!ELEMENT risk (explanation?)>
<!ATTLIST risk
        schema %oLOV; #IMPLIED
        group %oLOV; #IMPLIED
        rating %attvals.rating_attr; #REQUIRED
>        



<!ELEMENT explanation (FreeText*)>




<!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
<!-- - - - - - - - -  System Info - - - - - - - - - - - - - - - - - - - -->
<!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->

<!ELEMENT System_Information (information+, system_list?)>

<!ELEMENT information (FormattedText+)>
<!ATTLIST information
        type %oLOV; #IMPLIED
>        


<!-- - - - - - - - - -system_list- - - - - - - - - - -->
<!-- For  machine-readable system information, a model
     of system information is necessary, which standardizes
     identifiers for platforms, software, version information, etc.

     A model of system information is orthogonal to
     an advisory format: various system models could be
     used together with the EISPP advisory format. The following
     definition for specifying a list of affected systems should
     be general enough to use with any model ofs system information.
     Which model is used must be communicated using the attribute
     'cat_model' in the top-level element 'system_list'
  --> 

<!-- A system list contains one or more affected systems -->

<!ELEMENT system_list
    (system+)>
<!ATTLIST system_list
    cat_model CDATA #IMPLIED
>


<!-- A system may be specified by one or more system parts of
     different types; which types such as 'platform' and
     'software' must be defined in the model of system information.
-->


<!ELEMENT  system
    (system_part+)>


<!ELEMENT system_part 
    (instance+)>

<!ATTLIST system_part
    type CDATA #REQUIRED
>

<!-- An instance of a system part is best understood by example. 
     Consider a system part of type 'platform'. Instances could
     be 'Windows 2000', 'Windows XP', and 'RedHat Linux'. 
     A standardized tag to identify such an instance must be
     defined by a model of system information 
-->



<!ELEMENT instance
    (attribute_value*)>

<!ATTLIST instance
    tag CDATA #REQUIRED
>
   
<!-- Some models of system information may want to associate additional
     information such as version information with single instances. This
     can be done using the attribute_value element. The tag of the
     attribute_value element is used to communicate the kind of information
     (e.g., 'version', 'patchlevel', etc.) and must be standardized by
     the model of system information that is used. One or more values
    can be provided.
    
     Consider the following example, in which an instance 'w2k' (Windows 2000)
     is associated with patchlevel information:

          <instance tag = "w2k">
            <attribute_value tag = "patchlevel">
             <value>SP1</value>
             <value>SP2</value>
            </attribute_value>
          </instance>
  
-->

<!ELEMENT attribute_value
    (value+)
>
<!ATTLIST attribute_value
    tag CDATA #REQUIRED
>

<!ELEMENT value 
    (#PCDATA)>


<!-- Here is a complete example of how machine-readable system information
  could be used to communicate that Apache 1.3.x and 2.0 is vulnerable
  on Windows 2000 and Windows XP, while on unix machines only 
  Apache 2.x is vulnerable. 


   <system_list cat_model="german_cert_wg">
       <system>
         <system_part type="platform">
   	<instance tag="w2k"/>
   	<instance tag="wxp"/>
         </system_part>
         <system_part type="software">
   	<instance tag="apache">
   	  <attribute_value tag="version">
   	    <value>1.3.x</value>
   	    <value>2.x</value>
   	  </attribute_value>
   	</instance>
         </system_part>
       </system>
       <system>
         <system_part type="os">
   	<instance tag="unix"/>
         </system_part>
         <system_part type="software">
   	<instance tag="apache">
   	  <attribute_value tag="version">
   	    <value>2.x</value>
   	  </attribute_value>
   	</instance>
         </system_part>
       </system>
   </system_list>

-->




<!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
<!-- - - - - - - - -  Description - - - - - - - - - - - - - - - - - - - -->
<!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->

<!-- A description contains

  -  an optional title (defined exactly the same as the
     advisory title as freetext field) (NEWLY INTRODUCED IN DAF)

  - an optional list of vulnerability ids (NEWLY INTRODUCED IN DAF) 
    in case several vulnerabilities are described and the 
    author wants to indicate to which vulnerability this particular 
    element refers to, 

  - and the content. 
 -->

<!ELEMENT Description (description+)>

<!ELEMENT description (title?, vuln_ids?, content)>

<!-- In addition to the 'content type' mentioned in the informal description, 
     an attribute for specifying a content 'subtype' has been added. Co-operating
     CERTs can define a proprietary use for this attribute.
--> 

<!ATTLIST description
        type %oLOV; #IMPLIED
        subtype %oLOV; #IMPLIED
>        

<!-- 'title' and 'vuln_ids' are already defined; 'content' is 
     defined as FormattedText field 
-->

<!ELEMENT content (FormattedText+)>

<!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
<!-- - - - - - - - -  Solution - - - - - - - - - - - - - - - - - - - - -->
<!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->


<!ELEMENT Solution (sol_intro?, sol_section*)>

<!-- - - - - - - - - -sol_intro- - - - - - - - - - - - - - - -->
<!ELEMENT sol_intro (FormattedText+)>

<!-- - - - - - - - - -sol_section  - - - - - - - - -->
<!-- sol_type makes a good attribute -->

<!ELEMENT sol_section (sol_title, sol_descr?, reference*)>
<!ATTLIST sol_section
        type  %attvals.sol_type_attr; #IMPLIED 
        subtype  %attvals.sol_subtype_attr; #IMPLIED 
>

<!-- - - - - - - - - -sol_title - - - - - - - - -->
<!ELEMENT sol_title (FreeText+)>

<!-- - - - - - - - - -sol_descr - - - - - - - - -->
<!ELEMENT sol_descr (FormattedText+)>


<!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
<!-- - - - - - - - -  Additional resources- - - - - - - - - - - - - - - -->
<!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->

<!ELEMENT Additional_Resources (reference+)>


<!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
<!-- - - - - - - - -  reference- - - - - - - - - - - - - - - - - - - - -->
<!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->

<!-- Many of the fields for "reference" identified in the informal
     description make good attributes -->

<!ELEMENT reference (ref_title?, uri*)>

<!ATTLIST reference
        name NMTOKEN #IMPLIED
        ref_type %attvals.ref_type_attr; #REQUIRED
        ref_subtype %oLOV; #IMPLIED
        issuer   %oLOV; #IMPLIED
        ref_num  %token; #IMPLIED
>

<!-- - - - - - - - - -ref_title - - - - - - - - - - - - - -->
<!ELEMENT ref_title  (FreeText+)>

<!-- - - - - - - - - -uri - - - - - - - - - - - - - -->
<!ELEMENT uri  (#PCDATA)>


<!ATTLIST uri
        xml:lang      %LanguageCode; #IMPLIED
        size          %token; #IMPLIED
        checksum      %token; #IMPLIED
        checksum_alg  %oLOV; #IMPLIED
>



<!-- =================================================================

At last, some information regarding open Lists of Values.

- recognized values for the information type within the system information are

 platform_info
 software_info
 system_info
 remark 


- recognized values for the information type within the system information are

  publication_context
  technical_context
  description
  technical_information
  diagnostic 
  complete_advisory


For other oLOVs (issuers, etc.) see the EISPP documentation.

====================================================================== -->