<?xml version="1.0" encoding="UTF-8"?>
<?xml-stylesheet type='text/xsl'
  href='http://xml.resource.org/authoring/rfc2629.xslt' ?>

<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<?rfc toc="yes"?>
<?rfc symrefs="yes"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
  <!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
  <!ENTITY RFC2585 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2585.xml">
  <!ENTITY RFC3275 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3275.xml">
  <!ENTITY RFC3339 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3339.xml">
  <!ENTITY RFC3492 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3492.xml">
  <!ENTITY RFC3647 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3647.xml">
  <!ENTITY RFC3688 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3688.xml">
  <!ENTITY RFC3986 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3986.xml">
  <!ENTITY RFC4051 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4051.xml">
  <!ENTITY RFC4180 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4180.xml">
  <!ENTITY RFC4279 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4279.xml">
  <!ENTITY RFC4519 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4519.xml">
  <!ENTITY RFC4765 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4765.xml">
  <!ENTITY RFC5070 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5070.xml">
  <!ENTITY RFC5226 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5226.xml">
  <!ENTITY RFC5280 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5280.xml">
  <!ENTITY RFC5322 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5322.xml">
  <!ENTITY RFC5646 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5646.xml">
  <!ENTITY RFC5755 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5755.xml">
  <!ENTITY RFC5890 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5890.xml">
  <!ENTITY RFC5891 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5891.xml">
  <!ENTITY RFC6194 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6194.xml">
  <!ENTITY XML1.0 SYSTEM "http://xml.resource.org/public/rfc/bibxml4/reference.W3C.REC-xml-20081126.xml">
  <!ENTITY XMLNames SYSTEM "http://xml.resource.org/public/rfc/bibxml4/reference.W3C.REC-xml-names-20091208.xml">
  <!ENTITY XMLencrypt SYSTEM "http://xml.resource.org/public/rfc/bibxml4/reference.W3C.REC-xmlenc-core-20021210.xml">
  <!ENTITY XMLschema SYSTEM "http://xml.resource.org/public/rfc/bibxml4/reference.W3C.REC-xmlschema-1-20041028.xml">
  <!ENTITY XMLdsig SYSTEM "http://xml.resource.org/public/rfc/bibxml4/reference.W3C.REC-xmldsig-core-20080610.xml">
  <!ENTITY XMLdsig1.1 SYSTEM "http://xml.resource.org/public/rfc/bibxml4/reference.W3C.CR-xmldsig-core1-20110303.xml">
  <!ENTITY XMLSigBP SYSTEM "http://xml.resource.org/public/rfc/bibxml4/reference.W3C.WD-xmldsig-bestpractices-20110809.xml">
  <!ENTITY XMLPath20 SYSTEM "http://xml.resource.org/public/rfc/bibxml4/reference.W3C.REC-xpath20-20101214.xml">
]>
<rfc
 ipr="trust200902"
 category="std"
 docName="draft-ietf-mile-grc-exchange-01.txt">
  <!-- TODO: P1: review all references to make sure they are up-to-date. -->
  
<front>
  <title abbrev="grc-exchange">GRC Report Exchange</title>
  <author initials="K." surname="Moriarty" fullname="Kathleen M. Moriarty">
    <organization abbrev="EMC">
    EMC Corporation 
    </organization>
    <address>
      <postal>
        <street>176 South Street</street>
        <city>Hopkinton, MA</city>
        <country>United States</country>
      </postal>
      <phone></phone>
      <email>Kathleen.Moriarty@emc.com</email>
    </address>
  </author>
  <author initials="S." surname="Tabet" fullname="Said Tabet">
    <organization abbrev="EMC">
    EMC Corporation 
    </organization>
    <address>
      <postal>
        <street>176 South Street</street>
        <city>Hopkinton, MA</city>
        <country>United States</country>
      </postal>
      <phone></phone>
      <email>Said.Tabet@emc.com</email>
    </address>
  </author>
  <author initials="D." surname="Waltermire" fullname="David Waltermire">
    <organization abbrev="NIST">
    National Institute of Standards and Technology
    </organization>
    <address>
      <postal>
        <street>100 Bureau Drive</street>
        <city>Gaithersburg, MD</city>
        <country>United States</country>
      </postal>
      <phone></phone>
      <!-- TODO: investigate using an NIST alias, look at what Tim P. did. -->
      <email>david.waltermire@nist.gov</email>
    </address>
  </author>
  <!-- TODO: update to latest posting date -->
  <date year='2012' />
  <area>Security</area>
  <workgroup>MILE Working Group</workgroup>
  <abstract> 
    <t>Governance, risk, and compliance (GRC) programs provide oversight (governance) of risks and compliance initiatives within an organization.  GRC reports are increasingly provided in an XML format.  This specification defines a common method to securely transport GRC and other XML reports.  The defined messaging capability provides policy options and markings in an XML schema, options for confidentiality at the document/report level, and security for the end-to-end communication.  XML reports may be shared between service providers and clients, enterprises, or within enterprises.  Reports may also be exchanged for official purposes such as business report filings, compliance report filings, and the handling of legal incidents (eWarrant, eDiscovery, etc.)  This work is a generalized format derived from the secure exchange of incident information defined by RFC6545, Real-time Inter-network Defense (RID).</t>
  </abstract>
</front>

<middle>
  <section title="Introduction" anchor="sec-intro">
    <t>Governance, risk, and compliance (GRC) programs provide oversight (governance) of risks and compliance initiatives within an organization.  The areas typically covered by GRC include:
      <list style="symbols">
        <t>Finance and Business Operations,</t>
        <t>Information Technology,</t>
        <t>Security, and</t>
        <t>Legal and Compliance</t>
      </list>
    </t>
    
    <t>GRC Report Exchange provides a secure method to communicate relevant information and reports, through the automated exchange of extensible markup language (XML) documents. GRC Report Exchange considers security, policy, and privacy issues as related to the exchange of potentially sensitive information.  Additionally, it enables organizations accepting GRC report filings, such as service providers or enterprises, the options to make appropriate decisions according to their policy requirements.  GRC Report Exchange includes provisions for confidentiality, integrity, and authentication.</t>
    
    <t>The data in GRC reports exchanged are represented in an XML <xref target="W3C.REC-xml-20081126"/> document using the appropriate XML schema for the included report. The XML document or formatted report is then enveloped by the GRC Report Exchange schema to set policy options and provide a common secure exchange method for such documents.  By following this model, a single method for all GRC reports can be used, simplifying the integration of GRC reports across platforms.</t>
    
    <!-- TODO: the following section references RFC6546, which does not support transport of this specification -->
    <t>Security and privacy considerations are of high concern since potentially sensitive information may be passed through GRC Report Exchange messages. GRC Report Exchange takes advantage of XML security and privacy policy information set in the GRC Report Exchange schema and provides standard settings for fine grain controls within GRC XML schemas. The GRC Report Exchange schema acts as an XML envelope to support the communication of GRC report documents. GRC Report Exchange messages are encapsulated for transport, which is defined in a separate document [RFC6546]. The authentication, integrity, and authorization features GRC Report Exchange and RID transport offer are used to achieve a necessary level of security.</t>
    
    <t>GRC report exchange is not strictly a technical problem. There are numerous procedural, trust, and legal considerations that might prevent an organization from sharing information.  GRC Report Exchange provides information and options that can be used by organizations who must then apply their own policies for sharing information. Organizations must develop policies and procedures for the use of the GRC Report Exchange protocol and XML reports.</t>
    
    <section title="Normative and Informative">
      <!-- TODO: P2: KM: The templated sections should come from the newer documents. We may want to leave this one out for now.  This was a defensive mechanism for the ITU.  If this document could go to the ITU, we will want the section to match the format of RID and RIDT. -->
      <t>The XML schema <xref target="W3C.REC-xmlschema-1-20041028"/> and transport requirements contained in this document are normative; all other information provided is intended as informative.  More specifically, the following sections of this document are intended as informative: Sections XXX.  The following sections of this document are normative: Sections XXX.</t>
    </section>
    
    <section title="Terminology" anchor="ext-terminology">
      <t>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 <xref target="RFC2119"/>.</t>
    </section>
  </section>
  
  <section title="Report Types">
    <t>There are many possible report types that may be exchanged using GRC Report Exchange.  The reports MUST all be XML formatted reports and MAY leverage the data markings used by this specification to require security options such as encryption on the entire report (XML document) or a section of the report.</t>
    <t>The types of reports may vary within each area of GRC.  Example report types broken out by GRC focus areas include:
      <!-- TODO: P2: From Kathleen: Do we want to expand this list? -->
      <list style="symbols">
        <t>Finance and Business Operations
          <list>
            <t>Finance or business Filing Report</t>
          </list>
        </t>
        <t>Information Technology
          <list>
            <t>Service Level Agreement (SLA) Reports from service providers (public cloud providers, community cloud providers, etc.)</t>
          </list>
        </t>
        <t>Security
          <list>
            <t>Security Report aligned to control requirements (ISO27002, NIST 800-53, etc.) from service providers</t>
          </list>
        </t>
        <t>Legal and Compliance
          <list>
            <t>eDiscovery Reports</t>
            <t>eWarrant Reports</t>
            <t>Compliance report aligned to specific regulations</t>
            <t>Report for internal or external audit aligned to risk and control frameworks (ISO27002, NIST 800-53, COSO, COBIT, etc.)</t>
          </list>
        </t>
      </list>
    </t>
  </section>
  
  <section title="Communication between Entities">
    
    <t>Trust relationships.  Service provider to tenant or client is the most likely scenario for the initial use cases of GRC report exchange.  See <xref target="sec-sharing-profiles-and-policies"/> on profiles.</t>
    
    <section title="Inter-network Provider GRC Messaging">
      <t>GRC Report Exchange provides a standard protocol and format that is required to ensure inter-operability between vendors for the exchange and filing of GRC reports.  GRC Report Exchange provides the framework necessary for communication between entities exchanging or filing GRC reports.  Several message types described in <xref target="sec-grc-messages"/> are necessary to facilitate the exchange or filing of reports.  The message types include the Report, Query, Acknowledgement, Result, and the Request message.</t>
      
      <t>The Report message is used when a GRC report is to be filed on a system or associated database accepting GRC Report Exchange messages, where no further action is required.  A Query message is used to request information on a particular report.  The Acknowledgement and Report messages are used to communicate the status and result of a Query or Request message.</t>
      
      <t>Use of the communication network and the GRC Report Exchange protocol must be for pre-approved, authorized purposes only.  It is the responsibility of each participating party to adhere to guidelines set forth in both a global use policy established through the peering agreements for each bilateral peer or agreed-upon consortium guidelines.  The purpose of such policies is to avoid abuse of the system; the policies shall be developed by a consortium of participating entities.  The global policy may be dependent on the domain it operates under; for example, a government network or a commercial network such as the Internet would adhere to different guidelines to address the individual concerns.  Privacy issues must be considered in public networks such as the Internet.  Privacy issues are discussed in the  Security Requirements section (<xref target="sec-security-requirements"/>), along with other requirements that must be agreed upon by participating entities.</t>
      
      <!-- QUESTION: P2: May not apply to GRC Report Exchange:  The trust relationship may be noted in a confidence rating based on relationships and experience working with peers.  The confidence ratings must adhere to specifications for selecting the percentage used to avoid abuse of the system. -->
      <t>The GRC Report Exchange system should be configurable to either require user input or automatically provide or file reports.  If the trust relationship is not strong, it may not be in the peer's best interest to accept a report or respond to a request.  The trust relationship may evolve over time through experience working with a peer and knowledge and review of their policies and operating procedures.</t>
    </section>
    
    <section title="GRC Report Exchange Communication Topology">
      <!-- TODO: P2: define the abbreviation "GRC-RE" -->
      <t>The most basic topology for communicating GRC Report Exchanges is a direct connection or a bilateral relationship as illustrated below.</t>
      
      <figure title="Direct Peer Topology"  anchor="fig-directTopology">
        <artwork><![CDATA[
        ______________                     _____________
        |            |                     |           |
        |  GRC-RE    |_____________________|  GRC-RE   |
        |____________|                     |___________|
]]></artwork>
      </figure>
      
      <t>A star topology may be desirable in instances where a peer may be a provider of GRC Reports.  This requires trust relationships to be established between the provider of information and each of the consumers of that information.  Examples may include clients that file compliance or business reports to an authoritative entity.</t>
      <!-- QUESTION: P2: what examples?  where are they located in the document? -->
      <t>The examples provided serve as an initial baseline set of expected topologies that may change over time.</t>
    </section>
    
    <section title="Message Formats">
      <!-- TODO: P2: determine if additional clarity is needed relative to the "generalized" approach of messages -->
      <t><xref target="sec-grc-messages"/> describes the five GRC Report Exchange message types, to be used with the appropriate XML documents.  The messages are expected to be generated and received on designated systems for GRC report exchanges.</t>
    </section>

    <section title="GRC Report Exchange Data Types">
      <section title="Boolean">
        <t>A boolean value is represented by the BOOLEAN data type.</t>
        <t>The BOOLEAN data type is implemented as "xs:boolean" <xref target="W3C.REC-xmlschema-1-20041028"/> in the schema.</t>
      </section>  
      
      <!-- TODO: P2: sync use of language tags with the "internationalization" section and the schema with regards to xml:lang -->
      <section title="Language" anchor="data_types_lang">
        <t>A language value is represented by the LANG data type.</t>
        <t>The LANG data type is a valid language code per <xref target="RFC5646"/> constrained by the definition of "xs:language" <xref target="W3C.REC-xmlschema-1-20041028"/> inherited from <xref target="W3C.REC-xml-20081126"/>.</t>
      </section>

      <!-- TODO: P2: This definition is weak.  Consider revising -->
      <section title="Multilingual Strings" anchor="data_types_ml_string">
        <t>STRING data that represents multi-character attributes in a language different than the default encoding of the document is of the ML_STRING data type.</t>
        <t>The ML_STRING data type is implemented as an "grc-exchange:MLStringType" in the schema.</t>
        <t>The base definition of this type is reused from the IODEF specification <xref target="RFC5070"/>, Section 2.4.  This definition is fully included in the GRC-Exchange specification in <xref target="node-class"/> to prevent the need to use the IODEF schema.</t>
      </section>

      <section title="Uniform Resource Locator strings" anchor="data_types_url">
        <t>A uniform resource locator (URL) is represented by the URL data type.  The format of the URL data type is documented in <xref target="RFC3986"/>.</t>      
        <t>The URL data type is implemented as an "xs:anyURI" <xref target="W3C.REC-xmlschema-1-20041028"/> in the schema.</t>
      </section>
      
      <section title="Date-Time Strings" anchor="data_types_datetime">
        <t>Date-time strings are represented by the DATETIME data type.  Each date-time string identifies a particular instant in time; ranges are not supported.</t>

        <t>Date-time strings are formatted according to a subset of ISO 8601:2004 <xref target="ISO.8601.2000"/> documented in <xref target="RFC3339"/>.</t>
        
        <t>The DATETIME data type is implemented as an "xs:dateTime" <xref target="W3C.REC-xmlschema-1-20041028"/> in the schema.</t>
        <t>The base definition of this type is reused from the IODEF specification <xref target="RFC5070"/>, Section 2.8.  This definition is fully included in the GRC-Exchange specification in <xref target="node-class"/> to prevent the need to use the IODEF schema.</t>
      </section>
      
      <section title="Timezone String" anchor="data_types_timezone">
        <t>A timezone offset from UTC is represented by the TIMEZONE data type. It is formatted according to the following regular expression: "Z|[\+\-](0[0-9]|1[0-4]):[0-5][0-9]".</t>
        <t>The TIMEZONE data type is implemented as an "xs:string" <xref target="W3C.REC-xmlschema-1-20041028"/> with a regular expression constraint in the schema.  This regular expression is identical to the timezone representation implemented in an "xs:dateTime".</t>
        <t>The base definition of this type is reused from the IODEF specification <xref target="RFC5070"/>, Section 2.9.  This definition is fully included in the GRC-Exchange specification in <xref target="node-class"/> to prevent the need to use the IODEF schema.</t>
      </section>
      
      <section title="Postal Address" anchor="data_types_postaladdress">
        <t>A postal address is represented by the POSTAL data type.  This data type is an ML_STRING whose format is documented in Section 2.23 of <xref target="RFC4519"/>.  It defines a postal address as a free-form multi-line string separated by the "$" character.</t>
        <!-- QUESTION: P2: if derived from ML_STRING, the following definition is incomplete as it doesn't fully incorporate ML_STRING. -->
        <t>The POSTAL data type is implemented as an "xs:string" <xref target="W3C.REC-xmlschema-1-20041028"/> in the schema.</t>
        <t>The base definition of this type is reused from the IODEF specification <xref target="RFC5070"/>, Section 2.11.  This definition is fully included in the GRC-Exchange specification in <xref target="node-class"/> to prevent the need to use the IODEF schema.</t>
      </section>
      
      <section title="Telephone and Fax Numbers" anchor="data_types_phone">
        <t>A telephone or fax number is represented by the PHONE data type.  The format of the PHONE data type is documented in Section 2.35 of <xref target="RFC4519"/>.</t>
        <t>The PHONE data type is implemented as an "xs:string" <xref target="W3C.REC-xmlschema-1-20041028"/> in the schema.</t>
        <t>The base definition of this type is reused from the IODEF specification <xref target="RFC5070"/>, Section 2.13.  This definition is fully included in the GRC-Exchange specification in <xref target="node-class"/> to prevent the need to use the IODEF schema.</t>
      </section>
      
      <section title="Email String" anchor="data_types_email">
        <!-- QUESTION: updated RFC5322 from 2822 -->
        <t>An email address is represented by the EMAIL data type.  The format of the EMAIL data type is documented in Section 3.4.1 of <xref target="RFC5322"/>.</t>
        <t>The EMAIL data type is implemented as an "xs:string" <xref target="W3C.REC-xmlschema-1-20041028"/> in the schema.</t>
        <t>The base definition of this type is reused from the IODEF specification <xref target="RFC5070"/>, Section 2.14.  This definition is fully included in the GRC-Exchange specification in <xref target="node-class"/> to prevent the need to use the IODEF schema.</t>
      </section>
    </section>
    
    <section title="GRC Report Exchange Message Types" anchor="message_types">
      <t>The five GRC Report Exchange message types are as follows:
        <list style="numbers">
          
          <t>Acknowledgement.  This message is sent to the requestor of a report (Request) or in response to a Query to notify on the state of a request (approved, pending, not approved).</t>
          
          <t>Result.  This message is sent to the requestor of a GRC report (Request) or in response to a Query. The Result may contain the full report requested or a section of the report as appropriate for the request in the Query.</t>
          
          <t>Request.  This message type is used to request a specific type of GRC report.  The Request MUST specify the XML schema and version for the requested report along with any other parameters required in the XML schema to generate the correct report.</t>
          
          <t>Report.  This message is used to provide a GRC Report.  The message can be considered a wrapper for any approved GRC schema used to format a report for submission.</t>
          
          <t>Query.  This message is used to request information about a specific GRC report.  The XML schema and version used MUST be specified along with any details required to provide the proper Report response.  The response is provided through the Report message.</t>
          
        </list>
      </t>
      <t>When an application receives a GRC Report Exchange message, it must be able to determine the type of message and parse it accordingly.  The message type is specified in the GRCPolicy class. The GRCPolicy class may also be used by the transport protocol to facilitate the secure communication of the GRC Report Exchange.</t>
    </section>  
  </section>
  
<section title="GRC-Exchange Schema" anchor="sec-schema">
  <!-- TODO: P2: verify all cardinalities in this document and schema.  Make sure the document and schema are in sync. -->
  <t>There are three classes included in the GRC Report Exchange schema required to facilitate communications.  The RequestStatus class is used to indicate the approval status of a report Request or Query; the GRCDocument class identifies the XML schema to be used by the provided or requested report; and the GRCPolicy class provides information on the agreed-upon policies and specifies the type of communication message being used.</t>

  <t>The GRC Report Exchange schema acts as an envelope for the GRC XML schema to facilitate secure GRC report communications. The intent in maintaining a separate schema is for the flexibility of sending messages between participating entities. Since GRC Report Exchange is a separate schema that includes the appropriate GRC XML schema, the GRC Report Exchange information acts as an envelope, and then the GRCPolicy class can be easily extracted for use by the transport protocol.</t>
  <t>The security requirements of sending GRC reports and associated information on finance, IT operations, legal, compliance, and security across the network include the use of confidentiality (encryption prior to the transport level), authentication (potentially multi-hop), integrity, and non-repudiation.  GRCPolicy uses labels that correspond to policy and agreements to standardize on handling requirements such as encryption and sharing limitations.  The GRCPolicy information should not be encrypted, hence GRC Report Exchange is maintained separate from the GRC XML schema used to send or request a report. This segregation enables flexibility for GRC Report Exchange to be used with any GRC XML schema and removes the need for decrypting and parsing the entire GRC Report and GRC Report Exchange document to determine how it should be handled at each entity communicating via GRC Report Exchange.</t>

  <t>The purpose of the GRCPolicy class is to specify the message type for the receiving host, facilitate the policy needs of GRC Reports, and provide routing information in the form of an IP address of the destination entity accepting GRC Report Exchange messages.</t>

  <t>The policy information and guidelines are discussed in Section <xref target="sec-grcpolicy"/>. The policy is defined between GRC-Exchange peers and within or between consortiums.  The GRCPolicy is meant to be a tool to facilitate the defined policies.  This MUST be used in accordance with policy set between clients, peers, consortiums, and/or regions.  Security, privacy, and confidentiality MUST be considered as specified in this document.</t>

  <t>The GRC Report Exchange (GRC-Exchange) schema is defined as follows:</t>
  <figure title="The GRC-Exchange Schema"  anchor="fig-grcschema">

    <!-- TODO: P2: left out GRCHeader, since this is not defined.  Bring up as a mailing list discussion. -->
    <artwork><![CDATA[
        +------------------+
        |   GRC-Exchange   |
        +------------------+
        | LANG lang        |<>---{0..1}----[ GRCPolicy      ]
        |                  |
        |                  |<>---{0..1}----[ RequestStatus  ]
        |                  |
        |                  |<>---{0..1}----[ GRCDocument    ]
        +------------------+
]]></artwork>
  </figure>
  <t>The aggregate classes that constitute the GRC-Exchange schema in the grc-exchange namespace are as follows:</t>

  <t>GRCPolicy
    <list>
      <t>Zero or One.  The GRCPolicy class is used by all message types to facilitate policy agreements between peers, consortiums, or federations, as well as to properly route messages.</t>
    </list>
  </t>
  <t>RequestStatus
    <list>
      <t>Zero or One.  The RequestStatus class is used only in Acknowledgement messages to report back to the entity requesting a report or sending a report Query if the request is denied or remains in a pending state.</t>
    </list>
  </t>
  <t>GRCDocument
    <list>
      <t>Zero or One.  The GRCDocument class is used in each of the message types to state the XML schema and version for the included XML report, XML report request, or response.</t>
    </list>
  </t>

  <t>The GRC-Exchange class defines one attribute as follows:</t>
  <t>lang
    <list>
      <t>REQUIRED.  ENUM.  A valid language code per <xref target="RFC5646"/> constrained by the definition of "xs:language" <xref target="W3C.REC-xmlschema-1-20041028"/> inherited from <xref target="W3C.REC-xml-20081126"/>.</t>
    </list>
  </t>

  <!-- TODO: P2: 6546 does not support GRC exchange transport.  We need to revise this. -->
  <t>Each of the three listed classes may be the only class included in the GRC-Exchange class, hence the option for zero or one.  In some cases, GRCPolicy MAY be the only class in the GRC-Exchange definition when used by the transport protocol [RFC6546], as that information should be as small as possible and may not be encrypted.  The Acknowledgement message using the RequestStatus class MUST be able to stand alone without the need for an GRC XML document to facilitate the communication, limiting the data transported to the required elements per [RFC6546].</t>

  <section title="GRCPolicy Class" anchor="sec-grcpolicy">
    <t>The GRCPolicy class facilitates the delivery of GRC Report Exchange messages.</t>
    <figure title="The GRCPolicy Class"  anchor="fig-grcpolicy">
      <artwork><![CDATA[
       +--------------------------+
       | GRCPolicy                |
       +--------------------------+
       |                          |<>---{0..1}----[ ReportID     ]
       | ENUM restriction         |
       | STRING ext-restriction   |<>-------------[ Node         ]
       | ENUM MsgType             |
       | STRING ext-MsgType       |<>---{1..*}----[ PolicyRegion ]
       | ENUM MsgDestination      |
       | STRING ext-MsgDestination|
       |                          |
       +--------------------------+
]]></artwork>
    </figure>
    <t>The aggregate elements that constitute the GRCPolicy class are as follows:</t>
    
    <t>ReportID
      <!-- TODO: From Kathleen: This should be at the top level for this version of the document.  Functionally, it makes more sense to group this at the top level in case no document is included.  It may be a query or an Acknowledgement that does not require the information.
          
I know Dave you prefer it here, but if we move it, we should have this as a discussion in the WG.  Functionally, I think it fits better at the top level.  This level requires a document, Report type and from contact, none may be needed, but if this class is used, that all makes sense.-->
      <list>
        <!-- TODO: add xref to "reportid-class" section -->
        <!-- TODO: alternate ID is not defined in this document or the schema. How should we handle this? -->
        <!-- Answer: Great point, it may be best to handle at this layer as not to require this in each document type exchanged -->
        <!-- TODO: what does "Global reference pointing back to the ReportID defined in the GRC XML data model." mean? -->
        <t>Zero or one.  Global reference pointing back to the ReportID defined in the GRC XML data model.  The ReportID includes the domain name of the entity who creates the report, a report number, and an instance of that report number.  The default report number is a date, where the requested report is the most recent report on or prior to the date specified. The format for the date SHALL be YYYYMMDD, where Y is the year, M is the month, and D is the day.  The instance number is appended with a dash separating the values and is used in cases for which there may be multiple reports issued in a day.  The format for the instance SHALL be HHMMSS, where H is the hour as specified in a 24hour range, M is the minute, S is the second provided in GMT.  An alternate ID may be specified within the GRC XML schema for the specific report.  This element has been derived from IODEF <xref target="RFC5070"/>.</t>
      </list>
    </t>
    <t>Node
      <list>
        <t>One.  The Node class is used to identify a host or network device, in this case to identify the system communicating GRC-Exchange messages. The base definition of this class is reused from the IODEF specification <xref target="RFC5070"/>, Section 3.16.  This definition is fully included in the GRC-Exchange specification in <xref target="node-class"/> to prevent the need to use the IODEF schema.</t>
      </list>
    </t>

    <t>PolicyRegion
      <list>
        <t>One or many.  REQUIRED.  The values for the attribute "region" are used to determine what policy area may require consideration before a trace can be approved.  The PolicyRegion may include multiple selections from the attribute list in order to fit all possible policy considerations when crossing regions, consortiums, or networks.</t>
      </list>

      <list>
        <t>region
          <list>
            <t>One.  ENUM.
              <list style="numbers">
                <!-- QUESTION: P2: What about exchanges within an organization? -->
                <t>ClientToSP.  An enterprise initiated the request to their service provider.</t>
                <t>SPToClient.  An service provider passed a GRC request or report to a client or an enterprise based on requested services or service level agreements.</t>
                <t>IntraConsortium.  GRC report information that should have no restrictions within the boundaries of a consortium with the agreed-upon use and abuse guidelines.</t>
                <!-- QUESTION: P2: Do we use profiles to set up peer-to-peer relationships for regulators?  IETF is pretty strict about what gets put here. regulators would make sense though.  -->
                <!-- TODO: P2: Said will look at some workflow to come up with some possible terms -->
                <t>PeerToPeer.  GRC report information that should have no restrictions between two peers but may require further evaluation before continuance beyond that point with the agreed-upon use and abuse guidelines.</t>
                <t>BetweenConsortiums.  GRC report information that should have no restrictions between consortiums that have established agreed-upon use and abuse guidelines.</t>

                <t>ext-value.  An escape value used to extend this attribute.  This attribute has been derived from IODEF <xref target="RFC5070"/>, Section 5.1 and is explained in <xref target="extending_enumerated_values_of_attributes"/>, Extending the Enumerated Values of Attributes.</t>
              </list>
            </t>
            <t>Additionally, there is an extension attribute to add new enumerated values:
              <list>
                <t>ext-region.  An escape value used to extend this attribute.  This attribute has been derived from IODEF <xref target="RFC5070"/> Section 5.1 and is explained in <xref target="extending_enumerated_values_of_attributes"/>, Extending the Enumerated Values of Attributes.</t>
              </list>
            </t>
          </list>
        </t>
      </list>
    </t>

    <t>The GRCPolicy class has six attributes:
      <list>
        <t>restriction
          <list>
            <t>Optional.  ENUM.  This attribute indicates the disclosure guidelines to which the sender expects the recipient to adhere for the information represented in this class and its children.  This guideline provides no security since there are no specified technical means to ensure that the recipient of the document handles the information as the sender requested.</t>
               
            <t>The value of this attribute is logically inherited by the children of this class.  That is to say, the disclosure rules applied to this class, also apply to its children.</t>
               
            <t>It is possible to set a granular disclosure policy, since all of the high-level classes (i.e., children of the Incident class) have a restriction attribute.  Therefore, a child can override the guidelines of a parent class, be it to restrict or relax the disclosure rules (e.g., a child has a weaker policy than an ancestor; or an ancestor has a weak policy, and the children selectively apply more rigid controls).  The implicit value of the restriction attribute for a class that did not specify one can be found in the closest ancestor that did specify a value.</t>
               
            <t>This attribute is defined as an enumerated value with a default value of "private".  Note that the default value of the restriction attribute is only defined in the context of the GRCPolicy class.  In other classes where this attribute is used, no default is specified.</t>
               
            <t>This attribute is derived from IODEF <xref target="RFC5070"/> and is fully included within this schema.
                 
              <list style="numbers">
                <t>public.  There are no restrictions placed in the information.</t>
                   
                <t>need-to-know.  The information may be shared with other parties that are involved in the incident as determined by the recipient of this document (e.g., multiple victim sites can be informed of each other).</t>
                   
                <t>private.  The information may not be shared.</t>
                   
                <t>default.  The information can be shared according to an information disclosure policy pre-arranged by the communicating parties.</t>
                
                <t>ext-value.  An escape value used to extend this attribute.  This attribute has been derived from IODEF <xref target="RFC5070"/>, Section 5.1 and is explained in <xref target="extending_enumerated_values_of_attributes"/>, Extending the Enumerated Values of Attributes.</t>
              </list>
            </t>
          </list>
        </t>
        
        <t>ext-restriction
          <list>
            <t>OPTIONAL.  STRING.  A means by which to extend the restriction attribute.  This attribute has been derived from IODEF <xref target="RFC5070"/> Section 5.1 and is explained in <xref target="extending_enumerated_values_of_attributes"/>, Extending the Enumerated Values of Attributes.</t>
          </list>
        </t>

        <t>MsgType
          <list>
            <t>REQUIRED.  ENUM.  The type of GRC-Exchange message sent.  The five types of messages are described in <xref target="message_types"/> and can be noted as one of the five selections below.

              <list style="numbers">
                <t>Acknowledgement.  This message is sent to the initiating GRC-Exchange entity if a Request or Query has been denied or is pending.</t>
                <t>Result.  This message provides the result of a Query.</t>
                <t>Request.  The purpose of the Request is to request a report from an entity.</t>
                <t>Report.  This message is used to provide a GRC XML report.</t>
                <!-- QUESTION: "The actual query is specified in the GRC XML Schema" should be message body? -->
                <!-- Possible answer: I agree, with the exception of where a ReportID is provided in the GRC-Exchange top level -->
                <!-- We can make that distinction in the guidance -->
                <!-- TODO: P2: We need to define more explicitly how XMLDocument and other extension points can be used to define specific messages. This text needs to be revised. -->
                <t>Query.  This message is used to request information either about a specific report or group of reports.  The actual query is specified in the GRC XML Schema and is outside the scope of this specification.</t>
                
                <t>ext-value.  An escape value used to extend this attribute.  This attribute has been derived from IODEF <xref target="RFC5070"/>, Section 5.1 and is explained in <xref target="extending_enumerated_values_of_attributes"/>, Extending the Enumerated Values of Attributes.</t>
              </list>
            </t>
          </list>
        </t>
        
        <t>ext-MsgType
          <list>
            <t>OPTIONAL.  STRING.  A means by which to extend the MsgType attribute.  This attribute has been derived from IODEF <xref target="RFC5070"/> Section 5.1 and is explained in <xref target="extending_enumerated_values_of_attributes"/>, Extending the Enumerated Values of Attributes.</t>
          </list>
        </t>

        <t>MsgDestination
          <list>
            <t>REQUIRED.  ENUM.  The destination required at this level may either be the system accepting GRC report exchange requests or reports.  The Node element lists the address of the host receiving the GRC-Exchange message.
              <list style="numbers">
                <!-- QUESTION: From Kathleen: We will have to figure out if we are using the NodeName or IP Address in Node.  RID has updated text here that should be included for internationalization. -->
                <!-- TODO: P2: We will use IPs and domain names for now.  Address this later after working out an overall approach for IODEF and RID. -->
                <t>GRCSystem.  The address listed in the Node element of the GRCPolicy class is the system communicating via GRC-Exchange that will receive the message.</t>
                <t>ext-value.  An escape value used to extend this attribute.  This attribute has been derived from IODEF <xref target="RFC5070"/> Section 5.1 and is explained in <xref target="extending_enumerated_values_of_attributes"/>, Extending the Enumerated Values of Attributes.</t>
              </list>
            </t>
          </list>
        </t>

        <t>ext-MsgDestination
          <list>
            <t>OPTIONAL.  STRING.  A means by which to extend the MsgDestination attribute.  This attribute has been derived from IODEF <xref target="RFC5070"/> Section 5.1 and is explained in <xref target="extending_enumerated_values_of_attributes"/>, Extending the Enumerated Values of Attributes.</t>
          </list>
        </t>
      </list>
    </t>
  </section>

  <section title="RequestStatus">
    <t>The RequestStatus class is an aggregate class in the GRC-Exchange class.</t>
    <figure title="The RequestStatus Class"  anchor="fig-requeststatus">
      <artwork><![CDATA[
                  +--------------------------------+
                  | RequestStatus                  |
                  +--------------------------------+
                  |                                |
                  | ENUM restriction               |
                  | STRING ext-restriction         |
                  | ENUM AuthorizationStatus       |
                  | STRING ext-AuthorizationStatus |
                  | ENUM Justification             |
                  | STRING ext-Justification       |
                  |                                |
                  +--------------------------------+
]]></artwork>
    </figure>

    <t>The RequestStatus class has six attributes:
      <list>
        <t>restriction
          <list>
            <t>OPTIONAL.  ENUM.  This attribute indicates the disclosure guidelines to which the sender expects the recipient to adhere.  This guideline provides no real security since it is the choice of the recipient of the document to honor it.  This attribute follows the same guidelines as "restriction" used in IODEF and is explained in the GRCPolicy Class description in <xref target="sec-grcpolicy"/>.</t>
          </list>
        </t>
        
        <t>ext-restriction
          <list>
            <t>OPTIONAL.  STRING.  A means by which to extend the restriction attribute.  This attribute has been derived from IODEF <xref target="RFC5070"/> Section 5.1 and is explained in <xref target="extending_enumerated_values_of_attributes"/>, Extending the Enumerated Values of Attributes.</t>
          </list>
        </t>

        <t>AuthorizationStatus
          <list>
            <t>REQUIRED.  ENUM.  The listed values are used to provide a response to the requesting entity of the ReportRequest or ReportQuery.
              <list style="numbers">
                <t>Approved.  The request was approved and will be provided.  The approved message MAY be sent if there will be a delay in providing the report, otherwise, the Report or Result MAY be provided without sending a Acknowledgement message.</t>
                <t>Denied.  The request has been denied.</t>
                <t>Pending.  Awaiting approval; a timeout period has been reached, which resulted in this Pending status and Acknowledgement message being generated.</t>
                <t>ext-value.  An escape value used to extend this attribute.  This attribute has been derived from IODEF <xref target="RFC5070"/> Section 5.1 and is explained in <xref target="extending_enumerated_values_of_attributes"/>, Extending the Enumerated Values of Attributes.</t>
              </list>
            </t>
          </list>
        </t>

        <t>ext-AuthorizationStatus
          <list>
            <t>OPTIONAL.  STRING.  A means by which to extend the AuthorizationStatus attribute.  This attribute has been derived from IODEF <xref target="RFC5070"/> Section 5.1 and is explained in <xref target="extending_enumerated_values_of_attributes"/>, Extending the Enumerated Values of Attributes.</t>
          </list>
        </t>
        
        <t>Justification
          <list>
            <t>OPTIONAL.  ENUM.  Provides a reason for a Denied or Pending message.
              
              <list style="numbers">
                <t>SystemResource.  A resource issue exists on the systems that would be involved in the request.</t>
                <t>Authentication.  The enveloped digital signature <xref target="RFC3275"/> failed to validate.</t>
                <t>AuthenticationOrigin.  The detached digital signature for the original requestor on the RecordItem entry failed to validate.</t>
                <t>Encryption.  Unable to decrypt the request.</t>
                <t>UnrecognizedFormat.  The format of the provided document was unrecognized.</t>
                <!-- QUESTION: do we need a policy related value? -->
                <!-- QUESTION: How can we handle communication within this "protocol"? -->
                <!-- TODO: P2: Address later.  Look into XACML and other solutions that enable referencing policy artifacts. -->
                <t>CannotProcess.  The document could not be processed. Reasons may include legal or policy decisions.  Resolution may require communication outside of this protocol to resolve legal or policy issues.  No further messages SHOULD be sent until resolved.</t>

                <t>Other.  There were other reasons this request could not be processed.</t>
                <t>ext-value.  An escape value used to extend this attribute.  This attribute has been derived from IODEF <xref target="RFC5070"/> Section 5.1 and is explained in <xref target="extending_enumerated_values_of_attributes"/>, Extending the Enumerated Values of Attributes.</t>
              </list>
            </t>
          </list>
        </t>

        <t>ext-Justification-ext
          <list>
            <t>OPTIONAL.  STRING.  A means by which to extend the Justification attribute.  This attribute has been derived from IODEF <xref target="RFC5070"/> Section 5.1 and is explained in <xref target="extending_enumerated_values_of_attributes"/>, Extending the Enumerated Values of Attributes.</t>
          </list>
        </t>
      </list>
    </t>
  </section>

  <section title="GRCDocument">
    
    <t>The GRCDocument class is an aggregate class in the GRC-Exchange class.</t>
    <figure title="The GRCDocument Class"  anchor="fig-grcdocument">
      <artwork><![CDATA[
         +-------------------------+
         |      GRCDocument        |
         +-------------------------+
         |                         |<>---{1..*}----[ ReportType  ]
         |  ENUM Version           |
         |  STRING ext-Version     |<>---{0..1}----[ FromContact ]
         |  ENUM XMLSchemaID       |
         |  STRING ext-XMLSchemaID |<>---{0..1}----[ URL         ]
         |  ENUM restriction       |
         |  STRING ext-restriction |<>---{1}-------[ XMLDocument ]
         |                         |
         |                         |<>---{0..*}----[ Signature   ]
         |                         |
         |                         |
         +-------------------------+
]]></artwork>
    </figure>
    
    <t>The elements that constitute the GRCDocument class are as follows:
      <list>
        
        <t>ReportType
          <list>
            <t>One or many.  REQUIRED.  The values for the attribute "type" are meant to assist in determining if the included XML report or request is appropriate for the entity receiving the request or report message.  Multiple values may be selected for this element; however, where possible, it should be restricted to one value that most accurately describes the report type.</t>
            
            <t>type
              <list>
                <t>One.  ENUM.
                  <list style="numbers">
                    <t>Filing.  This ReportType is used when a GRC report is included for expected filing purposes.  Examples may include the filing of a regulatory or business operations report to a regulatory body.</t>
                    <t>Service Level Agreement.  This option specifies the report type as a report on a service level agreement.  This report may be sent from a service provide (SP) to a tenant or client or from a trust authority to a requesting entity.  An SLA report may be associated with any report format (XML) associated with an SLA agreement, including but not limited to an IT or security report.</t>
                    <t>Operational.  An operational report may include any standard operating reports used within or between businesses or enterprises.  This may be a routine business, IT operational, or other type of report.</t>
                    <t>Compliance.  A compliance report is specified when there is a specific compliance report format required (as specified by the schema used for the report).  This type may be used for internal or external compliance report exchanges.</t>
                    <t>Audit.  The Audit report type is distinguished from a compliance report as the report contents may vary depending on the report or report request in the exchange.  An audit report may take an approach of only providing the state of compliance or details of findings from an automated control review.</t>
                    <t>RiskAssessment.  A RiskAssessment report differs from the Compliance and Audit reports in that the report may prioritize risks as specified in the XML schema and may include GRC-XML risk ratings.  A RiskAssessment may be provided for any GRC area or on the GRC program as specified by the GRCDocument.</t>
                    <t>OfficialBusiness.  This option MUST be used if the GRC information is requested by or affiliated with any government or other official business request.  This could be used during an investigation for an eDiscovery, eWarrant, or other use case.</t>
                    <t>Other.  If this option is selected, a description of the request MUST be provided so that policy decisions can be made to proceed with the request or act upon the report.  The information should be provided in the GRC-Exchange class meaning attribute.</t>
                    <t>ext-value.  An escape value used to extend this type. This value has been derived from IODEF <xref target="RFC5070"/>, Section 5.1 and is explained in <xref target="extending_enumerated_values_of_attributes"/>, Extending the Enumerated Values of Attributes.</t>
                  </list>
                </t>
              </list>
            </t>
            
            <t>ext-type
              <list>
                <t>OPTIONAL. One.  STRING.  A means by which to extend the type attribute.  This attribute has been derived from IODEF <xref target="RFC5070"/> Section 5.1 and is explained in <xref target="extending_enumerated_values_of_attributes"/>, Extending the Enumerated Values of Attributes.</t>
              </list>
            </t>
          </list>
        </t>
        
        <t>FromContact
          <list>
            <t>Zero or more.  Contact.  Provides contact information for the parties responsible for a report provided in the GRC Report Exchange as defined by the Contact class in <xref target="contact-class"/>.</t>
          </list>
        </t>
        
        <t>URL
          <!-- TODO: update the schemalocation text as needed. -->
          <list>
            <t>Zero or One.  URL.  A reference to the XML schema included.  The URL data type is defined in <xref target="data_types_url"/>.  The schemaLocation for IODEF is already included in the RID schema, so this is not necessary to include a URL for IODEF documents.</t>
          </list>
        </t>

        <t>XMLDocument
          <!-- TODO: move documentation over from IODEF and add "definition derived from IODEF reference" -->
          <!-- TODO: bring over any section references -->
          <list>
            <t>One.  ExtensionType.  The XMLDocument is a complete XML document defined by the ExtensionType class in <xref target="extensiontype-class"/>.  This class follows the guidelines in <xref target="RFC5070"/> Section 5 where the data type is set to "xml" and meaning is set to "xml" to include an xml document.</t>
          </list>
        </t>

        <t>Signature
          <!-- TODO: move documentation over from ODEF & and add "definition derived from IODEF & RID" reference -->
          <!-- Added more guidance for the signature, we probably need to switch this to be an enveloped signature -->
          <!-- TODO: bring over any section references -->
          <list>
            <t>Zero to many.  ExtensionType.  The Signature includes a complete XML document with the type specified by the ExtensionType class in <xref target="extensiontype-class"/>.  This class follows the guidelines in <xref target="RFC5070"/> Section 5 where the data type is set to "xml" and meaning is set to "xml" to include an xml document.  The usage of this element is similar to RID <xref target="RFC6545"/> and is used to encapsulate the detached signature based on a specific class within the XML document to verify the originator of the message.  If a detached signature is used, guidance for the encapsulated document MUST be provided as to which class should be used to create the signature.  Alternatively, if no guidance is provided, the digital signature MUST be an enveloped signature of the entire XML document that is encapsulated.  This attribute has been derived from RID <xref target="RFC6545"/>, Section 5.1.1.</t>
          </list>
        </t>

        <t>The GRCDocument class has six attributes:</t>
        <t>Version
          <list>
            <!-- TODO: update contents removing IODEF references -->
            <!-- TODO: bring over any section references for RID? -->
            <t>OPTIONAL. One.  The Version attribute is the version number of the specified XML schema.  That schema must be an approved version of a schema registered with IANA for use with GRC-Exchange.  The IANA registry for managing schemas used with GRC-Exchange is specified in <xref target="sec-iana"/>.  This attribute has been derived from RID <xref target="RFC6545"/>, Section 5.1.1.
              <list>
                <t>ext-value.  An escape value used to extend this attribute. This attribute has been derived from IODEF <xref target="RFC5070"/>, Section 5.1 and is explained in <xref target="extending_enumerated_values_of_attributes"/>, Extending the Enumerated Values of Attributes.</t>
              </list>
            </t>
          </list>
        </t>

        <t>ext-Version
          <list>
            <!-- TODO: update contents removing IODEF references -->
            <!-- Done -->
            <t>OPTIONAL. One.  STRING.  The ext-Version attribute is the version number of the included XML schema.  This attribute is used if a schema other than an IANA registered schema that has been added to the enumerated list for Version is included.  This attribute has been derived from RID <xref target="RFC6545"/>, Section 5.1.1. </t>
          </list>
        </t>

        <t>XMLSchemaID
          <list>
            <!-- TODO: update contents removing IODEF references -->
            <!-- Done -->
            <t>OPTIONAL. One.  URL.  The XMLSchemaID attribute is the identifier, the defined namespace <xref target="W3C.REC-xml-names-20091208"/>, of the XML schema of the XML document included.  The XMLSchemaID and Version specify the format of the XMLDocument element.  The only permitted values, include any namespace listed in the IANA managed list of registered schemas for use with GRC-Exchange.  The IANA registry for managing schemas is specified in <xref target="sec-iana"/>.  This attribute has been derived from RID <xref target="RFC6545"/>, Section 5.1.1. 
              <list>
                <t>ext-value.  An escape value used to extend this attribute. This attribute has been derived from IODEF <xref target="RFC5070"/>, Section 5.1 and is explained in <xref target="extending_enumerated_values_of_attributes"/>, Extending the Enumerated Values of Attributes.</t>
              </list>
            </t>
          </list>
        </t>

        <t>ext-XMLSchemaID
          <list>
            <!-- TODO: update contents removing IODEF references -->
            <!-- Done -->
            <t>OPTIONAL. One.  The ext-XMLSchemaID attribute is the identifier (defined namespace) of the XML schema of the XML document included.  The ext-XMLSchemaID and ext-Version specify the format of the XMLDocument element and are used if the included schema is not an IANA registered schema that has been added to the enumerated list for XMLSchemaID.  This attribute has been derived from RID <xref target="RFC6545"/>, Section 5.1.1. </t>
          </list>
        </t>

        <t>restriction
          <list>
            <t>OPTIONAL.  ENUM.  This attribute indicates the disclosure guidelines to which the sender expects the recipient to adhere.  This guideline provides no real security since it is the choice of the recipient of the document to honor it.  This attribute follows the same guidelines as "restriction" used in IODEF and is explained in the GRCPolicy Class description in <xref target="sec-grcpolicy"/>.</t>
          </list>
        </t>
        
        <t>ext-restriction
          <list>
            <t>OPTIONAL.  STRING.  A means by which to extend the restriction attribute.  This attribute has been derived from IODEF <xref target="RFC5070"/> Section 5.1 and is explained in <xref target="extending_enumerated_values_of_attributes"/>, Extending the Enumerated Values of Attributes.</t>
          </list>
        </t>
      </list>
    </t>
  </section>  
  
  <section title="Reference Class">
    <t>The Reference class is a reference to the GRC Schema used for the exchange.  A reference consists of a name, a URL to this reference, and an optional description.</t>
    
    <figure title="The Reference Class"  anchor="fig-reference">
      <artwork><![CDATA[
        +------------------+
        | Reference        |
        +------------------+
        |                  |<>----------[ ReferenceName ]
        |                  |<>--{0..*}--[ URL           ]
        |                  |<>--{0..*}--[ Description   ]
        +------------------+
]]></artwork>
    </figure>
    
    <t>The aggregate classes that constitute Reference:
      <list>
        <t>ReferenceName
          <list>
            <!-- QUESTION: P2: From Kathleen: We may need more guidance here so we have parsable items. -->
            <t>One. ML_STRING.  Name of the reference.</t>
          </list>
        </t>
        
        <t>URL
          <list>
            <t>Zero or many.  URL.  A URL associated with the reference.</t>
          </list>
        </t>
        
        <t>Description
          <list>
            <t>Zero or many.  ML_STRING.  A free-form text description of this reference.</t>
          </list>
        </t>
        
      </list>
    </t>
  </section>

  <section title="ReportID Class" anchor="reportid-class">
    <t>The ReportID class represents a report tracking number that is unique in the context of the reporting organization and identifies the activity characterized in a GRCDocument.  This identifier would serve as an index into the organizational reporting system.  The combination of the name attribute and the string in the element content MUST be a globally unique identifier describing the activity.  Documents generated by a given organization MUST NOT reuse the same value unless they are referencing the same report instance.  The ReportID class is derived from IODEF <xref target="RFC5070"/>, Section 3.3. </t>
  
    <figure title="The ReportID Class" anchor="fig-reportid">
      <artwork><![CDATA[
     +------------------------+
     | ReportID               |
     +------------------------+
     | STRING                 |
     |                        |
     | STRING name            |
     | STRING instance        |
     | ENUM restriction       |
     | STRING ext-restriction |
     +------------------------+
]]></artwork>
    </figure>
    
    <t>The ReportID class has four attributes:
      <list>
        <t>name
          <list>
            <t>Required.  STRING.  An identifier describing the organization that created the report.  In order to have a globally unique organization name, the fully qualified domain name associated with the organization MUST be used.</t>
          </list>
        </t>
        <t>instance
          <list>
            <t>Optional.  STRING.  An identifier referencing a subset of the named report.</t>
          </list>
        </t>

        <t>restriction
          <list>
            <t>Optional.  ENUM.  This attribute follows the same guidelines as "restriction" explained in the GRCPolicy Class description in <xref target="sec-grcpolicy"/>.</t>
          </list>
        </t>
        
        <t>ext-restriction
          <list>
            <t>OPTIONAL.  STRING.  A means by which to extend the restriction attribute.  This attribute has been derived from IODEF <xref target="RFC5070"/> Section 5.1 and is explained in <xref target="extending_enumerated_values_of_attributes"/>, Extending the Enumerated Values of Attributes.</t>
          </list>
        </t>
      </list>
    </t>
  </section>
  
  <section title="Contact Class" anchor="contact-class">
    <t>The Contact class describes contact information for organizations and personnel involved in the report exchange.  This class allows for the naming of the involved party, specifying contact information for them, and identifying their role in the XML Report.  The Contact class is derived from IODEF <xref target="RFC5070"/>, Section 3.7. </t>
    
    <t>People and organizations are treated interchangeably as contacts; one can be associated with the other using the recursive definition of the class (the Contact class is aggregated into the Contact class).  The 'type' attribute disambiguates the type of contact information being provided.</t>
    
    <t>The inheriting definition of Contact provides a way to relate information without requiring the explicit use of identifiers in the classes or duplication of data.  A complete point of contact is derived by a particular traversal from the root Contact class to the leaf Contact class.  As such, multiple points of contact might be specified in a single instance of a Contact class.  Each child Contact class logically inherits contact information from its ancestors.</t>
    
    <figure title="The Contact Class" anchor="fig-contact">
      <artwork><![CDATA[
  +------------------------+
  | Contact                |
  +------------------------+
  | ENUM role              |<>-{0..1}-[ ContactName       ]
  | STRING ext-role        |<>-{0..*}-[ Description       ]
  | ENUM type              |<>-{0..*}-[ RegistryHandle    ]
  | STRING ext-type        |<>-{0..1}-[ PostalAddress     ]
  | ENUM restriction       |<>-{0..*}-[ Email             ]
  | STRING ext-restriction |<>-{0..*}-[ Telephone         ]
  |                        |<>-{0..1}-[ Fax               ]
  |                        |<>-{0..1}-[ Timezone          ]
  |                        |<>-{0..*}-[ AdditionalContact ]
  |                        |<>-{0..*}-[ AdditionalData    ]
  +------------------------+
]]></artwork>
    </figure>
    
    <t>The aggregate classes that constitute the Contact class are:
      <list>
        <t>ContactName
          <list>
            <t>Zero or one.  ML_STRING.  The name of the contact.  The contact may either be an organization or a person.  The type attribute disambiguates the semantics.</t>
          </list>
        </t>
        <t>Description
          <list>
            <t>Zero or many.  ML_STRING.  A free-form description of this contact.  In the case of a person, this is often the organizational title of the individual.</t>
          </list>
        </t>
    
        <t>RegistryHandle
          <list>
            <t>Zero or many.  A handle name into the registry of the contact.</t>
          </list>
        </t>
        
        <t>PostalAddress
          <list>
            <t>Zero or one.  The postal address of the contact.</t>
          </list>
        </t>
        
        <t>Email
          <list>
            <t>Zero or many.  The email address of the contact.</t>
          </list>
        </t>
        
        <t>Telephone
          <list>
            <t>Zero or many.  The telephone number of the contact.</t>
          </list>
        </t>
        
        <t>Fax
          <list>
            <t>Zero or one.  The facsimile telephone number of the contact.</t>
          </list>
        </t>
        
        <t>Timezone
          <list>
            <t>Zero or one.  TIMEZONE.  The timezone in which the contact resides formatted according to Section <xref target="data_types_timezone"/>.</t>
          </list>
        </t>
        
        <t>AdditionalContact
          <list>
            <t>Zero or many.  A Contact instance contained within another Contact instance inherits the values of the parent(s).  This recursive definition can be used to group common data pertaining to multiple points of contact and is especially useful when listing multiple contacts at the same organization.</t>
          </list>
        </t>
        
        <t>AdditionalData
          <list>
            <!-- TODO: P2: document the use of the ExtensionType Class here. Also document that the XMLDocument and Signature elements use the ExtensionType class.  -->
            <t>Zero or many.  A mechanism by which to extend the data model.</t>
          </list>
        </t>
      </list>
    </t>

    <t>At least one of the aggregate classes MUST be present in an instance of the Contact class.  This is not enforced in the GRC-Exchange schema as there is no simple way to accomplish it.</t>
    
    <t>The Contact class has six attributes:
      <list>
        <t>role
          <list>
            <t>Required.  ENUM.  Indicates the role the contact fulfills.  This
        attribute is defined as an enumerated list:
              <list style="numbers">
                <!-- QUESTION: P2: We may need a term for regulators without saying regulators as that will be balked at in the IETF. -->
                <t>creator.  The entity that generate the document.</t>
                <t>admin.  An administrative contact for a host, network, or entity.</t>
                <t>tech.  A technical contact for a host or network.</t>
                <t>cc.  (also known as carbon-copy) An entity that is to be kept informed about the report.</t>
                <t>ext-value.  An escape value used to extend this attribute.  This attribute has been derived from IODEF <xref target="RFC5070"/>, Section 5.1 and is explained in <xref target="extending_enumerated_values_of_attributes"/>, Extending the Enumerated Values of Attributes.</t>
              </list>
            </t>
          </list>
        </t>

        <t>ext-role
          <list>
            <t>Optional.  STRING.  A means by which to extend the role attribute.  This attribute has been derived from IODEF <xref target="RFC5070"/> Section 5.1 and is explained in <xref target="extending_enumerated_values_of_attributes"/>, Extending the Enumerated Values of Attributes.</t>
          </list>
        </t>
        <t>type
          <list>
            <t>Required.  ENUM.  Indicates the type of contact being described.  This attribute is defined as an enumerated list:
              <list style="numbers">
                <t>person.  The information for this contact references an individual.</t>
                <t>organization.  The information for this contact references an organization.</t>
                <t>ext-value.  An escape value used to extend this attribute.  This attribute has been derived from IODEF <xref target="RFC5070"/>, Section 5.1 and is explained in <xref target="extending_enumerated_values_of_attributes"/>, Extending the Enumerated Values of Attributes.</t>
              </list>
            </t>
          </list>
        </t>

        <t>ext-type
          <list>
            <t>Optional.  STRING.  A means by which to extend the type attribute.  This attribute has been derived from IODEF <xref target="RFC5070"/> Section 5.1 and is explained in <xref target="extending_enumerated_values_of_attributes"/>, Extending the Enumerated Values of Attributes.</t>
          </list>
        </t>

        <t>restriction
          <list>
            <t>Optional.  ENUM.  This attribute follows the same guidelines as "restriction" used in IODEF and is explained in the GRCPolicy Class description in <xref target="sec-grcpolicy"/>.</t>
          </list>
        </t>
        
        <t>ext-restriction
          <list>
            <t>OPTIONAL.  STRING.  A means by which to extend the restriction attribute.  This attribute has been derived from IODEF <xref target="RFC5070"/> Section 5.1 and is explained in <xref target="extending_enumerated_values_of_attributes"/>, Extending the Enumerated Values of Attributes.</t>
          </list>
        </t>
      </list>    
    </t>
    <t>This definition is from the IODEF specification <xref target="RFC5070"/>, Section 3.7.  This definition is fully included in the GRC-Exchange specification to prevent the need to use the IODEF schema.</t>

    <section title="RegistryHandle Class">
      <t>The RegistryHandle class represents a handle into an Internet registry or community-specific database.  The handle is specified in the element content and the type attribute specifies the database.  The RegistryHandle class is derived from IODEF <xref target="RFC5070"/>, Section 3.7.1. </t>
    
      <figure title="The RegistryHandle Class" anchor="fig-registryhandle">
        <artwork><![CDATA[
    +---------------------+
    | RegistryHandle      |
    +---------------------+
    | STRING              |
    |                     |
    | ENUM registry       |
    | STRING ext-registry |
    +---------------------+
]]></artwork>
      </figure>
    
      <t>The RegistryHandle class has two attributes:
        <list>
          <t>registry
            <list>
              <t>Required.  ENUM.  The database to which the handle belongs.  The default value is 'local'.  The possible values are:
                <list style="numbers">
                  <t>internic.  Internet Network Information Center</t>
                  <t>apnic.  Asia Pacific Network Information Center</t>
                  <t>arin.  American Registry for Internet Numbers</t>
                  <t>lacnic.  Latin-American and Caribbean IP Address Registry</t>
                  <t>ripe.  Reseaux IP Europeens</t>
                  <t>afrinic.  African Internet Numbers Registry</t>
                  <t>local.  A database local to the CSIRT</t>
                  <t>ext-value.  An escape value used to extend this attribute.  This attribute has been derived from IODEF <xref target="RFC5070"/>, Section 5.1 and is explained in <xref target="extending_enumerated_values_of_attributes"/>, Extending the Enumerated Values of Attributes.</t>
                </list>
              </t>
            </list>
          </t>
          <t>ext-registry
            <list>
              <t>Optional.  STRING.  A means by which to extend the registry attribute.  This attribute has been derived from IODEF <xref target="RFC5070"/> Section 5.1 and is explained in <xref target="extending_enumerated_values_of_attributes"/>, Extending the Enumerated Values of Attributes.</t>
            </list>
          </t>
        </list>
      </t>
      <t>This definition is from the IODEF specification <xref target="RFC5070"/>, Section 3.7.1.  This definition is fully included in the GRC-Exchange specification to prevent the need to use the IODEF schema.</t>
    </section>

    <section title="PostalAddress Class">
    
      <t>The PostalAddress class specifies a postal address formatted according to the POSTAL data type (<xref target="data_types_postaladdress"/>).</t>
    
      <figure title="The PostalAddress Class" anchor="fig-postaladdress">
        <artwork><![CDATA[
    +---------------------+
    | PostalAddress       |
    +---------------------+
    | POSTAL              |
    |                     |
    | ENUM meaning        |
    | ENUM lang           |
    +---------------------+
]]></artwork>
      </figure>
    
      <t>The PostalAddress class has two attributes:
        <list>
          <t>meaning
            <list>
              <!-- QUESTION: P2: should this be ML_STRING? -->
              <t>Optional.  ENUM.  A free-form description of the element content.</t>
            </list>
          </t>
          <t>lang
            <list>
              <t>Required.  ENUM.  A valid language code per <xref target="RFC5646"/> constrained by the definition of "xs:language" <xref target="W3C.REC-xmlschema-1-20041028"/> inherited from <xref target="W3C.REC-xml-20081126"/>.</t>
           </list>
          </t>
        </list>
      </t>
      <t>This definition is from the IODEF specification <xref target="RFC5070"/>, Section 3.7.2.  This definition is fully included in the GRC-Exchange specification to prevent the need to use the IODEF schema.</t>
    </section>
    
    <section title="Email Class">
    
      <t>The Email class specifies an email address formatted according to EMAIL data type (<xref target="data_types_email"/>).  </t>
    
      <figure title="The Email Class" anchor="fig-email">
        <artwork><![CDATA[
    +--------------+
    | Email        |
    +--------------+
    | EMAIL        |
    |              |
    | ENUM meaning |
    +--------------+
]]></artwork>
      </figure>

      <t>The Email class has one attribute:
        <list>
          <t>meaning
            <list>
              <!-- QUESTION: P2: should this be ML_STRING? -->
              <t>Optional.  ENUM.  A free-form description of the element content.</t>
            </list>
          </t>
        </list>
      </t>
      <t>This definition is from the IODEF specification <xref target="RFC5070"/>, Section 3.7.3.  This definition is fully included in the GRC-Exchange specification to prevent the need to use the IODEF schema.</t>
    </section>
    
    <section title="Telephone and Fax Classes">
      <t>The Telephone and Fax classes specify a voice or fax telephone number respectively, and are formatted according to PHONE data type (<xref target="data_types_phone"/>).</t>
    
      <figure title="The Telephone and Fax Classes" anchor="fig-telephone-and-fax">
        <artwork><![CDATA[
    +--------------------+
    | {Telephone | Fax } |
    +--------------------+
    | PHONE              |
    |                    |
    | ENUM meaning       |
    +--------------------+
]]></artwork>
      </figure>
    
      <t>The Telephone class has one attribute:
        <list>
          <t>meaning
            <list>
              <!-- QUESTION: P2: should this be ML_STRING? -->
              <t>Optional.  ENUM.  A free-form description of the element content (e.g., hours of coverage for a given number).</t>
            </list>
          </t>
        </list>
      </t>
      <t>This definition is from the IODEF specification <xref target="RFC5070"/>, Section 3.7.4.  This definition is fully included in the GRC-Exchange specification to prevent the need to use the IODEF schema.</t>
    </section>    
  </section>

  <section title="ExtensionType Class" anchor="extensiontype-class">
   
    <t>The ExtensionType class serves as an extension mechanism for information not otherwise represented in the data model.  For relatively simple information, atomic data types (e.g., integers, strings) are provided with a mechanism to annotate their meaning. The class can to encapsulating entire XML documents conforming to an IANA registered Schema.  This class is also used to provide a consistent location for the inclusion of digital signatures.</t>

    <t>Unlike XML, which is self-describing, atomic data must be documented to convey its meaning.  This information is described in the 'meaning' attribute.  Since these description are outside the scope of the specification, some additional coordination may be required to ensure that a recipient of a document using the ExtensionType classes can make sense of the custom extensions.</t>
    
    <figure title="The ExtensionType Class" anchor="fig-extensiontype">
      <artwork><![CDATA[
    +------------------+
    | AdditionalData   |
    +------------------+
    | ANY              |
    |                  |
    | ENUM dtype       |
    | STRING ext-dtype |
    | STRING meaning   |
    | STRING formatid  |
    | ENUM restriction |
    +------------------+
]]></artwork>
      </figure>
    <t>The ExtensionType class has five attributes:
      <list>
        <t>dtype
          <list>
            <t>Required.  ENUM.  The data type of the element content.  The permitted values for this attribute are shown below.  The default value is "string".
              <list style="numbers">
                <!-- TODO: P2: Revisit and make a determination in the future about what to add, keep and remove. -->
                <t>boolean.  The element content is of type BOOLEAN.</t>
                <t>byte.  The element content is of type BYTE.</t>
                <t>character.  The element content is of type CHARACTER.</t>
                <t>date-time.  The element content is of type DATETIME.</t>
                <t>integer.  The element content is of type INTEGER.</t>
                <t>portlist.  The element content is of type PORTLIST.</t>
                <t>real.  The element content is of type REAL.</t>
                <t>string.  The element content is of type STRING.</t>
                <t>file.  The element content is a base64 encoded binary file encoded as a BYTE[] type.</t>
                <t>frame.  The element content is a layer-2 frame encoded as a HEXBIN type.</t>
                <t>packet.  The element content is a layer-3 packet encoded as a HEXBIN type.</t>
                <t>ipv4-packet.  The element content is an IPv4 packet encoded as a HEXBIN type.</t>
                <t>ipv6-packet.  The element content is an IPv6 packet encoded as a HEXBIN type.</t>
                <t>path.  The element content is a file-system path encoded as a STRING type.</t>
                <t>url.  The element content is of type URL.</t>
                <t>csv.  The element content is a common separated value (CSV) list per Section 2 of <xref target="RFC4180"/> encoded as a STRING type.</t>
                <t>winreg.  The element content is a Windows registry key encoded as a STRING type.</t>
                <t>xml.  The element content is XML (see <xref target="extending_enumerated_values_of_attributes"/>).</t>
                <t>ext-value.  An escape value used to extend this attribute.  This attribute has been derived from IODEF <xref target="RFC5070"/>, Section 5.1 and is explained in <xref target="extending_enumerated_values_of_attributes"/>, Extending the Enumerated Values of Attributes.</t>
              </list>
            </t>
          </list>
        </t>

        <t>ext-dtype
          <list>
            <t>Optional.  STRING.  A means by which to extend the dtype attribute.  This attribute has been derived from IODEF <xref target="RFC5070"/> Section 5.1 and is explained in <xref target="extending_enumerated_values_of_attributes"/>, Extending the Enumerated Values of Attributes.</t>
          </list>
        </t>

        <t>meaning
          <list>
            <t>Optional.  STRING.  A free-form description of the element content.</t>
          </list>
        </t>

        <t>formatid
          <list>
            <t>Optional.  STRING.  An identifier referencing the format and semantics of the element content.</t>
          </list>
        </t>

        <t>restriction
          <list>
            <t>Optional.  ENUM.  This attribute follows the same guidelines as "restriction" explained in the GRCPolicy Class description in <xref target="sec-grcpolicy"/>.</t>
          </list>
        </t>
      </list>
    </t>
    
    <t>This definition is from the IODEF specification <xref target="RFC5070"/>, Section 3.6.  This definition is fully included in the GRC-Exchange specification to prevent the need to use the IODEF schema.</t>
  </section>

  <section title="Node Class" anchor="node-class">
    <t>The Node class names a system (e.g., PC, router) or network.</t>

    <t>This class was derived from IODEF <xref target="RFC5070"/> and is partially included in this specification. The original IODEF definition was derived from IDMEF <xref target="RFC4765"/>.</t>


    <figure title="The Node Class" anchor="fig-node">
      <artwork><![CDATA[
   +---------------+
   | Node          |
   +---------------+
   |               |<>--{0..*}--[ NodeName ]
   |               |<>--{0..*}--[ Address  ]
   |               |<>--{0..1}--[ Location ]
   |               |<>--{0..1}--[ DateTime ]
   +---------------+
]]></artwork>
    </figure>

    <t>The aggregate classes that constitute Node are:
      <list>
        <t>NodeName
          <list>
            <t>Zero or more.  ML_STRING.  The name of the Node (e.g., fully
              qualified domain name).  This information MUST be provided if no
              Address information is given.</t>
          </list>
        </t>

        <t>Address
          <list>
            <t>Zero or more.  The hardware, network, or application address of
              the Node.  If a NodeName is not provided, at least one Address
              MUST be specified.  This class is defined in <xref target="address-class"/>.</t>
          </list>
        </t>
        
        <t>Location
          <list>
            <t>Zero or one.  ML_STRING.  A free-from description of the physical
              location of the equipment.</t>
          </list>
        </t>
        
        <t>DateTime
          <list>
            <t>Zero or one.  DATETIME.  A timestamp of when the resolution between the name and address was performed.  This information SHOULD be provided if both an Address and NodeName are specified.</t>
          </list>
        </t>
      </list>
    </t>
  </section>

  <section title="Address Class" anchor="address-class">
    <t>The Address class represents a hardware (layer-2), network (layer-3), or application (layer-7) address.</t>

    <t>This class was derived from IODEF <xref target="RFC5070"/> and is fully included in this specification. The original IODEF definition was derived from IDMEF <xref target="RFC4765"/>.</t>
    
    <figure title="The Address Class" anchor="fig-address">
      <artwork><![CDATA[
   +---------------------+
   | Address             |
   +---------------------+
   | ENUM category       |
   | STRING ext-category |
   | STRING vlan-name    |
   | INTEGER vlan-num    |
   +---------------------+
]]></artwork>
    </figure>

    <t>The Address class has four attributes:
      <list>
        <t>category
          <list>
            <t>Required.  ENUM.  The type of address represented.  The permitted values for this attribute are shown below.  The default value is "ipv4-addr".
              <list>
                <t>asn.  Autonomous System Number</t>
                <t>atm.  Asynchronous Transfer Mode (ATM) address</t>
                <t>e-mail.  Electronic mail address (RFC 822)</t>
                <t>ipv4-addr.  IPv4 host address in dotted-decimal notation (a.b.c.d)</t>
                <t>ipv4-net.  IPv4 network address in dotted-decimal notation, slash, significant bits (a.b.c.d/nn)</t>
                <t>ipv4-net-mask.  IPv4 network address in dotted-decimal notation, slash, network mask in dotted-decimal notation (a.b.c.d/w.x.y.z)</t>
                <t>ipv6-addr.  IPv6 host address</t>
                <t>ipv6-net.  IPv6 network address, slash, significant bits</t>
                <t>ipv6-net-mask.  IPv6 network address, slash, network mask</t>
                <t>mac.  Media Access Control (MAC) address</t>
                <t>ext-value.  An escape value used to extend this attribute. This attribute has been derived from IODEF <xref target="RFC5070"/>, Section 5.1 and is explained in <xref target="extending_enumerated_values_of_attributes"/>, Extending the Enumerated Values of Attributes.</t>
              </list>
            </t>
          </list>
        </t>

        <t>ext-category
          <list>
            <t>Optional.  STRING.  A means by which to extend the category attribute.  This attribute has been derived from IODEF <xref target="RFC5070"/> Section 5.1 and is explained in <xref target="extending_enumerated_values_of_attributes"/>, Extending the Enumerated Values of Attributes.</t>
          </list>
        </t>

        <t>vlan-name
          <list>
            <t>Optional.  STRING.  The name of the Virtual LAN to which the
              address belongs.</t>
          </list>
        </t>

        <t>vlan-num
          <list>
            <t>Optional.  STRING.  The number of the Virtual LAN to which the
              address belongs.</t>
          </list>
        </t>
      </list>
    </t>
  </section>
  
  <!-- QUESTION: P2: Do we want any additional data classes? Ask the mailing list. -->
   <section title="GRC-Exchange Name Spaces" anchor="sec-grc-exchange-namespaces">
     <t>The GRC-Exchange schema declares a namespace of "grc-exchange-1.0" and registers it per <xref target="W3C.REC-xml-names-20091208"/>. Any XML instance incorporating GRC-Exchange MUST use the element GRC-Exchange in the "urn:ietf:params:xml:ns:grc-exchange-1.0" namespace.  It can be referenced as follows:</t>
      <figure suppress-title="true">
        <!-- TODO: P2: Use grc-rx for GRC Report Exchange? Update this document and schema where appropriate. -->
         <artwork><![CDATA[
<GRC-Exchange version="1.00" lang="en-US"
   xmlns:xsi="http://www.w3.org/2001/XMLSchema-Instance"
   xmlns:grc-exchange="urn:ietf:params:xml:ns:grc-exchange-1.0"
   xsi:schemaLocation="http://www.iana.org/assignments/xml-registry/schema
   /grc-exchange-1.0.xsd">
]]></artwork>
      </figure>
   </section> 
</section>



<section title="Extending the Enumerated Values of Attributes" anchor="extending_enumerated_values_of_attributes">

   <t>In order to support the evolving needs of XML Schema exchanges, some extensibility is built into the GRC Report Exchange protocol.  This section discusses how new attributes that have no current representation in the data model can be incorporated into GRC-Exchange.  These techniques are designed so that adding new data will not require a change to the schema.  With proven value, well-documented additions can be incorporated into future versions of the specification.  However, this approach also supports private additions relevant only to a closed consortium.</t>

   <t>The data model supports a means by which to add new enumerated values to an attribute, following the method used in IODEF <xref target="RFC5070"/> for the same purpose.  For each attribute that supports this extension technique, there is a corresponding attribute in the same element whose name is identical, less a prefix of "ext-".  This special attribute is referred to as the extension attribute, and the attribute being extended is referred to as an extensible attribute. For example, an extensible attribute named "foo" will have a corresponding extension attribute named "ext-foo".  An element may have many extensible, and therefore many extension, attributes. In addition to a corresponding extension attribute, each extensible attribute has "ext-value" as one its possible values.  This particular value serves as an escape sequence and has no valid meaning.</t>

   <t>In order to add a new enumerated value to an extensible attribute, the value of this attribute MUST be set to "ext-value", and the new desired value MUST be set in the corresponding extension attribute. For example, an extended instance of the type attribute of the Impact class would look as follows:</t>

   <figure suppress-title="true">
      <artwork><![CDATA[
    <Impact type="ext-value" ext-type="new-attack-type">
]]></artwork>
   </figure>
   
   <t>A given extension attribute MUST NOT be set unless the corresponding extensible attribute has been set to "ext-value".</t>
</section>


<section title="GRC Report Exchange Messages" anchor="sec-grc-messages">
   <!-- TODO: change message names to their shortened form -->
   <t>The GRC-Exchange schema is used in combination with GRC XML documents to facilitate GRC Report Exchange communications. Each message type varies slightly in format and purpose; hence, the requirements vary and are specified for each.</t>

   <t>Note: The implementation of GRC-Exchange may automate the ability to fill in the content required for each message type from the GRC management systems involved in the message exchange.</t>




   <section title="Acknowledgement">
      <t>Description: This message is sent in response to a Request or a Query message to provide status as to the approval of a request. </t>
      <t>The following information is required for Acknowledgement messages and is provided through:</t>
      <t>GRC-Exchange Information:
         <list>
            <t>GRCPolicy
               <list>
                 <!-- TODO: From kathleen: We will have to go back to each of these and define them more specifically. -->
                  <t>GRC-Exchange message type, ReportID, and destination policy information</t>
               </list>
            </t>
            <t>RequestStatus class:
               <list>
                  <t>AuthorizationStatus of request</t>
               </list>
            </t>
         </list>
      </t>
      <t>Standards for encryption and digital signatures <xref target="RFC3275"/>, <xref target="W3C.REC-xmldsig-core-20080610"/>:
         <list>
            <t>Digital signature of responding entity authenticity of GRC-Exchange Message, from the entity creating this message using an enveloped XML digital signature.</t>
            <t>XML encryption as required by policy, agreements, and standard data markers.</t>
         </list>
      </t>
      <t>A pending status is automatically generated after a 5-minute timeout without system predefined or administrator action taken to approve or deny the request.  If a request is left in a pending state for more than a configurable period of time (default of 5 minutes), a response is sent to the requestor with the enumeration value set to pending.  If a request is denied, the response sets the enumeration value to denied.  If the request is approved, but the response will be delayed, a response MAY be sent with the enumerated value set to approved.  The approved message is not mandatory, however the pending and denied message types MUST be sent if the conditions are reached.</t>
   </section> 

   <section title="Result">
      <t>Description: This message provides the result of an approved Query.  The Query may be used when a query is made on a group of reports or a request is made for specific details within a report.  If a standard report is requested based on a specific XML schema, Request MUST be used.  The details of the Query will vary depending on the included GRC XML schema. The XML schema may provide specific guidance on how queries are conducted as this specification is intended to provide a generalized structure for many types of GRC information exchanges.</t>
      <t>The following information is required for Result messages and will be provided through:
         <list>
            <t>GRC-Exchange Information:
               <list>
                  <t>GRCPolicy
                     <list>
                        <t>GRC-Exchange message type, ReportID, and destination policy information</t>
                     </list>
                  </t>
                  <t>GRCDocument
                     <list>
                       <t>The GRCDocument class specifies the specific GRC-Exchange XML schema that is required per the Query.  The Result will include the necessary information to appropriately respond to the request.</t>
                     </list>
                  </t>
               </list>
            </t>

            <t>GRC XML Information:
               <list>
	
                  <t>GRC XML schema elements and attributes as appropriate for the Query.</t>
               </list>
            </t>
            <t>Standards for encryption and digital signatures <xref target="RFC3275"/>:
               <list>
                  <t>Digital signature of sending entity for authenticity of Result message, from the entity creating this message using an enveloped XML digital signature.</t>
                  <t>XML encryption as required by policy, agreements, and standard data markers.</t>
               </list>
            </t>
         </list>
      </t>

      <t>A Result message is sent back to the requesting entity of a Query.  This will include the results of the query using the appropriate XML schema named in the request.  Details of what standard queries are automated in addition to the standard responses are to be detailed by the appropriate GRC communities (GRC-XML, LI-XML, etc.) in guidance documents associated with each of the relevant schemas.</t>
   </section> 

   <section title="Request">
      <t>Description: The Request is used to request a report in a standardized format using the referenced XML schema in the GRCDocument class.  The report requested will be the most recent report to the date and time requested.</t>
      <t>The following information is required for Request messages and is provided through:
         <list>
            <t>GRC-Exchange Information:
               <list>
                  <t>GRCPolicy
                     <list>
                        <t>GRC-Exchange message type, ReportID, and destination policy information</t>
                     </list>
                  </t>
               </list>
            </t>
            <t>GRC XML Information:
               <list>
                  <t>GRC XML schema elements and attributes as appropriate for the Request.</t>
               </list>
            </t>

            <t>Standards for encryption and digital signatures <xref target="RFC3275"/>:
               <list>
                  <t>Digital signature from initiating entity sending the GRC-Exchange message using a detached XML digital signature on the GRC-Exchange information.</t>
                  <t>Digital signature of requesting entity for authenticity of the GRC-Exchange message, from the entity sending this message using an enveloped XML digital signature on the included GRC-XML document document.</t>
                  <t>XML encryption as required by policy, agreements, and data markers.</t>
               </list>
            </t>
         </list>
      </t>

      <t>Security requirements include the ability to encrypt <xref target="W3C.REC-xmlenc-core-20021210"/> the contents of the ReportRequest message using the public key of the destination entity communicating via GCR-Exchange.  If no report is available for the exact date and time in the request, the most recent report details prior to the date requested will be provided.  If there is no report to provide per the specified date and time, the Acknowledgement message will be sent instead setting the AuthorizationStatus to denied and providing the appropriate reason for the deny.</t>

   </section>


   <section title="Report">
      <t>Description: This message is used to provide a report using a specified GRC XML schema.  This message does not require any actions to be taken, except to file the report on the receiving system or associated database.  This message may be in response to a Request or sent as a regularly scheduled report.</t>

      <t>The following information is required for Report messages and will be provided through:
         <list>
            <t>GRC-Exchange Information:
               <list>
                  <t>GRCPolicy GRC-Exchange message type, ReportID, and destination policy information</t>
               </list>
            </t>

            <t>The following data is recommended if available and can be provided through:</t>

            <t>GRC XML Information:
               <list>
                  <t>GRC XML schema elements and attributes as appropriate for the Request.</t>
               </list>
            </t>
            <t>Standards for encryption and digital signatures <xref target="RFC3275"/>:
               <list>
                  <t>Digital signature from initiating entity, passed to all systems receiving the report using an enveloped XML digital signature.</t>
                  <t>XML encryption as required by policy, agreements, and standard data markers.</t>
               </list>
            </t>
         </list>
      </t>
      <t>Security requirements include the ability to encrypt <xref target="W3C.REC-xmlenc-core-20021210"/> the contents of the Report message using the public key of the destination entity.  Senders of a Report message should note that the information may be used to correlate information for the purpose of trending, pattern detection, etc., and may be shared with other parties unless otherwise agreed upon with the receiving entity in an established contract or agreement.  Therefore, sending parties of a Report message may obfuscate or remove sensitive information before sending a Report message.  A Report message may be sent either to file a report or in response to an ReportRequest, and data sensitivity must be considered in both cases.</t>
   </section> 


   <section title="Query">
      <t>Description: The report Query message is used to request information from a trusted entity participating in GRC-Exchanges.  The request can include the ReportID number, if known, or detailed information about the report or group of reports applicable to the query.</t>

      <t>The following information must be used for a report Query message and is provided through:

         <list>
            <t>GRC-Exchange Information:
               <list>
                  <t>GRCPolicy
                     <list>
                        <t>GRC-Exchange message type, ReportID, and destination policy information</t>
                     </list>
                  </t>
               </list>
            </t>

            <t>GRC XML information (optional):
               <list>
                  <t>GRC XML schema elements and attributes as appropriate for the report Query.</t>
               </list>
            </t>

            <t>Standards for encryption and digital signatures <xref target="RFC3275"/>:
               <list>
                  <t>Digital signature from the entity initiating the GRC-Exchange message, passed to all systems receiving the report Query using an enveloped XML digital signature.</t>
                  <t>XML encryption as required by policy, agreements, and standard data markers.</t>
               </list>
            </t>
         </list>
      </t>

      <t>The proper response to the Query message is a Result message.  Security requirements include the ability to encrypt <xref target="W3C.REC-xmlenc-core-20021210"/> the contents of the report Request message using the public key of the destination entity communicating via GCR-Exchange.  If no report is available for the exact date and time in the request, the most recent report details prior to the date requested will be provided.  If there is no report to provide per the specified date and time, the Acknowledgement message will be sent instead setting the AuthorizationStatus to denied and providing the appropriate reason for the deny.</t>
   </section> 
</section>


<section title="GRC-Exchange Communication Flows" anchor="sec-grc-exchange-Communication-flows">
  <!-- TODO: From Kathleen: We should add the short flow description Paul recommended to IODEF when we are ready… maybe on the next revision. -->
   <t>The following section outlines the communication flows for GRC-Exchange and also provides examples of messages.</t>


   <section title="Report Communication Flow" anchor="sec-report-communication-flow">
      <t>The diagram below outlines the communication flow for a GRC-Exchange Report message sent from one entity to another.  This communication flow is the simplest as no response is required.  The Report may be a regularly scheduled report filing.</t>

      <figure title="GRC-Exchange Report Communication Flow"  anchor="fig-reportflow">
         <artwork><![CDATA[
     Sending Entity                    Receiving Entity

     1. Generate Report message

     2.        o----------Report---------->

     3.                                Receive and process report
                                       No Response

]]></artwork>
      </figure>

      <t>The Report message MAY be encrypted <xref target="W3C.REC-xmlenc-core-20021210"/> for the recipient of the report depending upon the markers included in the restriction class either in the GRC-Exchange schema or in the GRC XML schema used for the report.  When a report is received, the receiving entity must verify that the report has not already been filed.  The ReportID and other distinguishing information in the specific report type can be used to compare with existing database entries. The Report message typically does not have a response, but the use of an Acknowledgement message is sometimes required to communicate status or error handling information.</t>

      <section title="GRC-Exchange Report Example" anchor="sec-grc-exchange-report-example">
         <t>The example listed is of a Report based on ...</t>
<!-- This text is old, so replacing, but the references need to be updated to match the references used in this document -->
<!--         <t>In the following example, use of <xref target="W3C.REC-xmldsig-core-20080610"/> to generate digital signatures does not currently provide digest algorithm agility, as <xref target="W3C.REC-xmldsig-core-20080610"/> only supports SHA-1.  A future version of <xref target="W3C.REC-xmldsig-core-20080610"/> may support additional digest algorithms to support digest algorithm agility.</t>  -->
        <t>In the following example, use of <xref target="W3C.REC-xmldsig-core-20080610"/> to generate digital signatures follows the guidance of XMLDsig 1.0 <xref target="W3C.REC-xmldsig-core-20080610"/>.  XMLDsig version 1.1 <xref target="W3C.CR-xmldsig-core1-20110303"/> supports additional digest algorithms.  Reference <xref target="RFC4051"/> for URIs intended for use with XML digital signatures, encryption, and canonicalization.  SHA-1 SHOULD NOT be used, see <xref target="RFC6194"/> for further details.</t>

         <figure>
            <artwork><![CDATA[

Example to be provided in an updated version of this document.

]]></artwork>
         </figure>
      </section>
   </section> 


   <section title="Request Communication Flow" anchor="sec-request-communication-flow">
      <t>The diagram below outlines the GRC-Exchange report request communication flow between participating entities.  The proper response to a report Request is a Report message.  If there is a problem with the request, such as a failure to validate the digital signature or decrypt the request, a Acknowledgement message is sent to the requestor.  The Acknowledgement message should provide the reason why the message could not be processed.</t>

      <figure title="Request Communication Flow"  anchor="fig-reportrequestflow">
         <artwork><![CDATA[
     Sending Entity                    Receiving Entity

     1. Generate report Request

     2.          o--------Request---------->

     3.                                Receive and process request 

     4.                                If denied or pending, send notice
                                       
     5.         <---Acknowledgement---o

     6.                                If request is approved,

     7.         <----------Report----------o

]]></artwork>
      </figure>

      <section title="Request Example">
         <t>The following example of the report Request is based on the ReportID time-based identifier tied to the specified GRC XML GRCDocument.</t>
         <figure>
            <artwork><![CDATA[

Example to be provided in an updated version of this document.

]]></artwork>
         </figure>
      </section>

      <section title="Acknowledgement Message Example">
         <t>The example Acknowledgement message is in response to the report Request listed above.  The entity that received the request was unable to validate the digital signature used to authenticate the sending RID system.</t>

         <figure>
            <artwork><![CDATA[

Example to be provided in an updated version of this document.

]]></artwork>
         </figure>
      </section>

      <!-- FIXME: a t is outside a section here -->
<!--      <t>An example Report has been provided in the previous section.  No Report message would be provided in this example as a result of the denied request.</t> -->
   </section>

   <section title="Query Communication Flow" anchor="sec-query-communication-flow">
      <t>The diagram below outlines the GRC-Exchange report Query communication flow between participating entities.</t>

      <figure title="Query Communication Flow"  anchor="fig-reportqueryflow">
         <artwork><![CDATA[
     Sending Entity                    Receiving Entity

     1. Generate Report Query

     2.          o---------Query----------->

     3.                                Receive and process request 

     4.                                If denied or pending, send notice
                                       
     5.         <---Acknowledgement---o

     6.                                If request approved

     7.         <----------Result----------o


]]></artwork>
      </figure>

      <t>The report Query communication flow is used to request specific information about a GRC report or group of reports.  Information may be shared between participating entities using this format.</t>

      <t>If there is a problem with the Query message, such as a failure to validate the digital signature <xref target="RFC3275"/> or decrypt the request, an Acknowledgement message is sent to the requestor.  The Acknowledgement message should provide the reason why the message could not be processed.</t>

      <section title="Query Example">
         <t>The following example includes the GRC-Exchange information and an example query using an included XML schema, which is also referenced in the GRCDocument class.</t>
         <figure>
            <artwork><![CDATA[

Example to be provided in an updated version of this document.

]]></artwork>
         </figure>
      </section>

      <section title="Acknowledgement Message Example">

         <t>The example Acknowledgement message is in response to the Query message listed above.  The entity that received the request is responding with an answer to the Query.  The Result in this instance will be delayed for more than the 5-minute default time period, hence a Acknowledgement message is sent to notify of the approval status.</t>

         <figure>
            <artwork><![CDATA[

Example to be provided in an updated version of this document.

]]></artwork>
         </figure>
      </section>
      <section title="Result Message Example">
         <t>The example Result message is in response to the Query request.  This message type may be preceded by a Acknowledgement within the report Query flow of messages.  It may be a direct response to a report Query request if the request is approved prior to the timeout period.  This message provides a response to the request in the Query.</t>

         <figure>
            <artwork><![CDATA[

Example to be provided in an updated version of this document.

]]></artwork>
         </figure>
      </section>
   </section> 
</section>

<section title="Internationalization Issues" anchor="internationalization">
  <t>Internationalization and localization is of specific concern to the GRC-Exchange, since information will often need to be exchanged across language barriers.  The GRC-Exchange supports this goal by depending on XML constructs, and through explicit design choices in the data model.</t>

  <t>GRC-Exchange documents are limited to the use of UTF-8 as it adequately provides the necessary support for internationalization.  Additionally, each included document MUST specify the language in which their contents are encoded.  The language can be specified with the attribute "xml:lang" (per <eref target="http://www.w3.org/TR/2008/REC-xml-20081126/#sec-lang-tag">Section 2.12</eref> of <xref target="W3C.REC-xml-20081126"/>) in the top-level element (i.e., GRC-Exchange-Document@lang) and letting all other elements inherit that definition.  All GRC-Exchange classes with a free-form text definition (i.e., all those defined of type grc-exchange:MLStringType) can also specify a language different from the rest of the document.  The valid language codes for the "xml:lang" attribute are described in <xref target="RFC5646"/>.</t>
  <t>The data model supports multiple translations of free-form text.  In the places where free-text is used for descriptive purposes, the given class always has a one-to-many cardinality to its parent (e.g., Description class).  The intent is to allow the identical text to be encoded in different instances of the same class, but each being in a different language.  This approach allows a GRC-Exchange document author to send recipients speaking different languages an identical document. The GRC-Exchange parser SHOULD extract the appropriate language relevant to the recipient.</t>

  <t>While the intent of the data model is to provide internationalization and localization, the intent is not to do so at the detriment of interoperability.  While the GRC-Exchange does support different languages, the data model also relies heavily on standardized enumerated attributes that can crudely approximate the contents of the document. With this approach, an organization should be able to make some sense of an GRC-Exchange document it receives even if the text based data elements are written in a language unfamiliar to the consumer.</t>

  <t>The Node class identifies a host or network device.  This document re-uses the definition of Node from the IODEF specification <xref target="RFC5070"/>, Section 3.16.  However, that document did not clearly specify whether a NodeName could be an Internationalized Domain Name (IDN).  GRC-Exchange systems MUST treat the NodeName class as a domain name slot <xref target="RFC5890"/>.  GRC-Exchange systems SHOULD support IDNs in the NodeName class; if they do so, the UTF-8 representation of the domain name MUST be used, i.e., all of the domain name's labels MUST be U-labels expressed in UTF-8 or NR-LDH labels <xref target="RFC5890"/>; A-labels MUST NOT be used.  An application communicating via GRC-Exchange can convert between A-labels and U-labels by using the Punycode encoding <xref target="RFC3492"/> for A-labels as described in the protocol specification for Internationalized Domain Names in Applications <xref target="RFC5891"/>.</t>
</section>

<section title="GRC-Exchange Schema Definition" anchor="sec-grc-exchange-schema-definition">
   <figure>
 <artwork><![CDATA[
<?xml version="1.0" encoding="UTF-8"?>
<xs:schema xmlns:grc-xml="urn:ietf:params:xml:ns:grc-xml-1.0"
 xmlns:xs="http://www.w3.org/2001/XMLSchema"
 xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
 targetNamespace="urn:ietf:params:xml:ns:grc-xml-1.0"
 elementFormDefault="qualified" attributeFormDefault="unqualified">

<xs:import namespace="http://www.w3.org/2000/09/xmldsig#"
 schemaLocation=
 "http://www.w3.org/TR/xmldsig-core/xmldsig-core-schema.xsd"/>

<!-- ****************************************************************
*********************************************************************
***     GRC Report Exchange - GRC-Exchange                        ***
***     Namespace - grc-exchange, October 2011                    ***
***     The namespace is defined to support transport of XML      ***
***     documents for exchanging GRC information.                 ***
*********************************************************************
-->
<!--GRC-Exchange acts as an envelope for XML documents to support the
    exchange of messages-->
<!--
======          GRC Report Exchange          ======
====  Suggested definition for GRC messaging ======
 -->


***  Schema to be included here  ***


]]></artwork>
   </figure>
</section>

<section title="Requirements for GRC XML Schemas for GRC-Exchange" anchor="sec-requirements-for-grcxml-schema">
   <t>GRC Report Exchange is a generalized version of the Real-time Inter-network Defense (RID) [RFC6545] protocol.  RID leverages certain aspects of the Incident Object Description Exchange Format (IODEF) <xref target="RFC5070"/> schema to provide the necessary security features such as confidentiality and integrity required for the exchange of potentially sensitive information.  In generalizing RID into a schema and set of message exchange flows for GRC reports,  the GRC XML schemas MUST include the following: classes, elements, and attributes with enumerated values to facilitate the automated security and confidentially concerns for GRC Report Exchange.  A GRC XML schema within this document may refer to any type of XML schema used for Governance, Risk, and Compliance information or reporting.  Examples include, but are not limited to GRC-XML, LI-XML, and security automation XML schemas.
      <list>
         <t>The restriction attribute, reused from IODEF <xref target="RFC5070"/> into GRC-Exchange, MUST be included in any individual class of a GRC XML schema that could require XML encryption <xref target="W3C.REC-xmlenc-core-20021210"/> just on the data contained in that class.  If encryption is only required at the full document level based on the sensitivity and sharing requirements, the restriction attribute in GRC-Exchange may be sufficient.</t>
      </list>
   </t>
</section>

<section title="Security Requirements" anchor="sec-security-requirements">
  
  <t>The content in this section is derived from RID <xref target="RFC6545"/>.</t>
  <section title="XML Digital Signatures and Encryption" anchor="sec-xml-signature-encryption">

    <t>GRC-Exchange leverages existing security standards and data markings in GRCPolicy to achieve the required levels of security for the exchange of GRC information.  The use of standards include TLS and the XML security features of encryption <xref target="W3C.REC-xmlenc-core-20021210"/> and digital signatures <xref target="RFC3275"/>, <xref target="W3C.REC-xmldsig-core-20080610"/>.  The standards provide clear methods to ensure that messages are secure, authenticated, and authorized, and that the messages meet policy and privacy guidelines and maintain integrity.</t>
    
    <t>As specified in the relevant sections of this document, the XML digital signature <xref target="RFC3275"/> and XML encryption <xref target="W3C.REC-xmlenc-core-20021210"/> are used in the following cases:</t>
    
    <t>XML Digital Signature
      <list style="symbols">
        <!-- TODO: P2: Need to either just use the enveloped signature or come up with a class that would be in each included schema -->
        <!--      <t>The originator of a Request MUST
      use a detached signature to sign at least one of the original elements contained in the RecordItem class to provide
      authentication to all upstream participants in the trace or those involved in the investigation.  All instances of RecordItem provided by the originator may be individually signed,
      and additional RecordItem entries by upstream peers in the trace or investigation may be
      signed by the peer adding the data, while maintaining the original RecordItem entry(s) and detached signature(s) from the original requestor.  It is important to note that the data is signed at the RecordItem level.  Since multiple RecordItems may exist within an IODEF document and may originate from different sources, the signature is applied at the RecordItem level to enable the use of an XML detached signature.  Exclusive canonicalization [XMLCanon] is REQUIRED for the detached signature and not the references as the XML document generated is then included in the GRC-Exchange message within the Signature element of the GRCDocument class.   This
      signature MUST be passed to all recipients of the Request message.</t>  
      
<t>If a Request does not include a RecordItem entry, a timestamp MUST be used to ensure there is data to be signed for the multi-hop authentication use case.  The DateTime element of the IODEF:RecordItem class, [RFC5070] Section3.19.1, is used for this purpose.</t>
-->
        <t>For all message types, the full GRC-Exchange document MUST be signed
          using an enveloped signature by the sending peer to provide
          authentication and integrity to the receiving GRC-Exchange system.  The signature is placed in an instance of the Signature element.</t>
        
        <t>XML Signature Best Practices <xref target="W3C.WD-xmldsig-bestpractices-20110809"/> guidance SHOULD be followed to prevent or mitigate security risks.  Examples include the recommendation to authenticate a signature prior to processing (executing potentially dangerous operations) and limiting the use of URIs since they may enable cross-site scripting attacks or access to local information.</t>
        
        <t>XML Path Language (XPath) 2.0 <xref target="W3C.REC-xpath20-20101214"/> MUST be followed to specify the portion of the XML document to be signed.  XPath is used to specify a location within an XML document.  Best practice recommendations for using XPath <xref target="W3C.WD-xmldsig-bestpractices-20110809"/> SHOULD be referenced to reduce the risk of denial of service attacks.  The use of XSLT transforms MUST be restricted according to security guidance in <xref target="W3C.WD-xmldsig-bestpractices-20110809"/>.</t>
      </list>
    </t>
    
    <t>XML Encryption
      <list style="symbols">
        <t>The document included in GRC-Exchange messages MAY be encrypted to provide an extra layer of security between peers so that the message is not only encrypted for transport.  This behavior would be agreed upon between peers or a consortium, or determined on a per-message basis, depending on security requirements.  It should be noted that there are cases for transport where the GRCPolicy class needs to be presented in clear text, as detailed in the transport document [RFC6546].</t>
        
        <t>A Request, or any other message type that may be relayed through GRC-Exchange systems before reaching the intended destination as a result of trust relationships, MAY be encrypted specifically for the intended recipient.  This may be necessary if the GRC-Exchange network is being used for message transfer, the intermediate parties do not need to have knowledge of the request contents, and a direct communication path does not exist.  In that case, the GRCPolicy class is used by intermediate parties and as such, GRCPolicy is maintained in clear text.</t>
        
        <t>A message may be encrypted using the key of the request originator, while leaving the GRC-Exchange contents in clear text.  In that case, the intermediate parties can view the GRCPolicy information and know a response has been provided without seeing the contents of the response.  If the use of encryption were limited to sections of the message, the History class information would be encrypted.  Otherwise, it is RECOMMENDED to encrypt the entire included schema plus GRC-Exchange document and use an enveloped signature, for the originator of the request.  The existence of the Result message for an incident would tell any intermediate parties used in the path of the incident investigation that the incident handling has been completed.</t>
        
        <t>The restriction attribute sets expectations for the privacy of an incident and is defined in <xref target="sec-grcpolicy"/>.  Following the guidance for XML encryption in the Security Requirements Section, the restriction attribute can be set in any of the GRC-Exchange classes to define restrictions and encryption requirements for the exchange of GRC information.  The restriction options enable encryption capabilities for the complete exchange of an XML document (including any extensions), within specific classes of a schema that embeds the restriction attribute where more limited restrictions are desired.  The restriction attribute is contained in each of the GRC-Exchange classes and MUST be used in accordance with confidentiality expectations for either sections of the included XML document or the complete included XML document.  Consortiums and organizations should consider this guidance when creating exchange policies.</t>
        <t>Expectations based on restriction setting:
          <list style="symbols">
            <t>If restriction is set to "private", the class or document MUST be encrypted for the recipient using XML encryption and the public key of the recipient.  See <xref target="sec-pki"/> for a discussion on public key infrastructure (PKI) and other security requirements.</t>
            <t>If restriction is set to "need-to-know", the class or document MUST be encrypted to ensure only those with need-to-know access can decrypt the data.  The document can either be encrypted for each individual for which access is intended or a single group key may be used.  The method used SHOULD adhere to any certificate policy and practices agreements between entities for the use of GRC-Exchange.  A group key in this instance refers to a single key (symmetric) that is used to encrypt the block of data.  The users with need-to-know access privileges may be given access to the shared key via a secure distribution method, for example, providing access to the symmetric key encrypted with each of users public keys.</t>
            <t>If restriction is set to "public", the class or document MUST be sent in clear text.  This setting can be critical if certain sections of a document or an entire document are to be shared without restrictions.  This provides flexibility within an exchange to share out certain information freely where appropriate.</t>
            <t>If restriction is set to "default", The information can be shared according to an information disclosure policy pre-arranged by the communicating parties.</t>
          </list>
        </t>
        <t>Expectations based on placement of the restriction setting:
          <list style="symbols">
            <t>If restriction is set within one of the GRC-Exchange classes, the restriction applies to the entire included XML document.</t>
            <t>If restriction is set within individual classes of the included XML document, the restriction applies to the specific class and the children of that class.</t>
          </list>
        </t>
      </list>
    </t>
    
    <t>The formation of policies is a very important aspect of using a messaging system like GRC-Exchange to exchange potentially sensitive information.  Many considerations should be involved for peering parties, and some guidelines to protect the data, systems, and transport are covered in this section.  Policies established should provide guidelines for communication methods, security, and fall-back procedures.  See Sections <xref target="sec-consortiums-pki" format="counter"/> and <xref target="sec-privacy-system-use"/> for additional information on consortiums and PKI considerations.</t>
    
    <t>The security considerations for the storage and exchange of information in GRC-Exchange messaging may include adherence to local, regional, or national regulations in addition to the obligations to protect information.  GRC-Exchange Policy is a necessary tool for listing the requirements of messages to provide a method to categorize data elements for proper handling.  Controls are also provided for the sending entity to protect messages from third parties through XML encryption.</t>
    
    <t>GRC-Exchange provides a method to exchange GRC request and Report messages between entities.  Administrators have the ability to base decisions on the available resources and other factors of their enterprise and maintain control of GRC exchanges.  Thus, GRC-Exchange provides the ability for participating networks to manage their own security controls, leveraging the information listed in GRCPolicy.</t>
    <t>GRC-Exchange is used to transfer or exchange XML documents in an IANA registered format.  Implementations SHOULD NOT download schemas at runtime due to the security implications, and included documents MUST NOT be required to provide a resolvable location of their schema.</t>
    
  </section>
  
  <section title="Public Key Infrastructure" anchor="sec-pki">
    
    <t>It is RECOMMENDED that GRC-Exchange, the XML security functions, and transport protocols properly integrate with a PKI managed by the consortium, federate PKIs within a consortium, or use a PKI managed by a trusted third party.  Entities MAY use shared keys as an alternate solution, although this may limit the ability to validate certificates and could introduce risk.  For the Internet, a few of examples of existing efforts that could be leveraged to provide the supporting PKI include the Regional Internet Registry's (RIR's) PKI hierarchy, vendor issued certificates, or approved issuers of Extended Validation (EV) Certificates.  Security and privacy considerations related to consortiums are discussed in Sections <xref target="sec-consortiums-pki" format="counter"/> and <xref target="sec-privacy-system-use"/>.</t>
    
    <t>The use of PKI between entities or by a consortium SHOULD adhere to any applicable certificate policy and practices agreements for the use of GRC-Exchange.  <xref target="RFC3647"/> specifies a commonly used format for certificate policy (CP) and certification practices statements (CPS).  Systems with predefined relationships for GRC-Exchange
      include those who peer directly or through a consortium with agreed-upon
      appropriate use agreements.  The agreements to trust other entities may be based on assurance levels that could be determined by a comparison of the CP, CPS, and/or GRC-Exchange operating procedures.  The initial comparison of policies and ability to audit controls provides a baseline assurance level for entities to form and maintain trust relationships.  Trust relationships may also be defined through a bridged or hierarchical
      PKI in which both peers belong.  If shared keys or keys issued from a common CA are used, the verification of controls to determine the assurance level to trust other entities may be limited to the GRC-Exchange policies and operating procedures.</t>
    
    <t>XML security
      functions utilized in GRC-Exchange require a trust center such as a PKI for
      the distribution of credentials to provide the necessary level of
      security for this protocol.  Layered transport protocols also utilize
      encryption and rely on a trust center.  Public key certificate pairs
      issued by a trusted Certification Authority (CA) MAY be used to
      provide the necessary level of authentication and encryption for the
      GRC-Exchange protocol.  The CA used for GRC-Exchange messaging must be trusted by all
      involved parties and may take advantage of similar efforts, such as
      the Internet2 federated PKI or the ARIN/RIR effort to provide a PKI
      to service providers.  The PKI used for authentication also
      provides the necessary certificates needed for encryption used for the
      GRC-Exchange transport protocol [RFC6546].</t>
    
    
    <section title="Authentication">
      
      <t>Hosts receiving a GRC-Exchange message MUST be able to verify that the sender
        of the request is valid and trusted.  Using digital signatures on a
        hash of the GRC-Exchange message with an X.509 version 3 certificate issued by
        a trusted party MUST be used to authenticate the request.  The X.509
        version 3 specifications as well as the digital signature
        specifications and path validation standards set forth in <xref target="RFC5280"/>
        MUST be followed in order to interoperate with a PKI designed for
        similar purposes.  Full path validation verifies
        the chaining relationship to a trusted root and also performs a
        certificate revocation check.  
        The use of digital signatures in GRC-Exchange XML messages MUST follow the World
        Wide Web Consortium (W3C) recommendations for signature syntax and
        processing when either the XML encryption <xref target="W3C.REC-xmlenc-core-20021210"/> or digital
        signature <xref target="W3C.REC-xmldsig-core-20080610"/>, <xref target="RFC3275"/> is used within a document.</t>
      
      <t>It might be helpful to define an extension to the authentication
        scheme that uses attribute certificates <xref target="RFC5755"/> in such a way that
        an application could automatically determine whether human
        intervention is needed to authorize a request; however, the
        specification of such an extension is out of scope for this document.</t>
      
      <t>The use of pre-shared keys may be considered for authentication at the transport layer.  If
        this option is selected, the specifications set forth in "Pre-Shared
        Key Ciphersuites for Transport Layer Security (TLS)" <xref target="RFC4279"/> MUST
        be followed.  Transport specifications are detailed in a separate document [RFC6546].</t>
    </section>
    <section title="Multi-Hop Request Authentication">
      <t>The use of multi-hop authentication in a Request is used when a Request is sent to multiple entities in an iterative manner.  Multi-hop authentication is REQUIRED in Requests that involve multiple entities where Requests are forwarded iteratively through peers.  Bilateral trust relationships MAY be used between peers, then Multi-hop authentication MUST be used for cases where the originator of a message is authenticated several hops into the message flow.</t>
      
      <t>For practical
        reasons, entities may want to prioritize incident handling events
        based upon the immediate peer for a Request, the originator of a request, and
        other relevant information provided in metadata.  In order to provide a
        higher assurance level of the authenticity of a Request, the
        originating GRC-Exchange system is included in the Request along with
        contact information and the information of all GRC-Exchange systems in the
        path the Request has taken.  This information is provided through the
        <!-- TODO: changed from IODEF to GRC-Exchange From-Contact: Need to figure out if that will work.  Fix references to "trace" and "infrastructure" -->
        GRC-Exchange From-Contact class nesting the list of systems and contacts
        involved in a request.</t>
      <!-- Removed: , while setting the category attribute to "infrastructure" -->
      
      <!-- TODO: Figure out an alternative -->
      <t>To provide multi-hop authentication, the originating GRC-Exchange system MUST include a
        digital signature in the Request sent to all systems in the
        upstream path.  
        <!-- The digital signature from the GRC-Exchange system is
   performed on the RecordItem class of the IODEF following the XML
   digital signature specifications from W3C [XMLsig] using a detached
   signature.  
-->
        The signature MUST be passed to all parties that receive
        a Request, and each party MUST be able to perform full path
        validation on the digital signature <xref target="RFC5280"/>.  In order to accommodate that
        requirement, the signed data MUST remain
        unchanged as a request is passed along between providers and may be restricted to one element for which the signature is applied.  
        <!-- If additional
   RecordItems are included in the document at upstream peers, the initial
   RecordItem entry MUST still remain with the detached signature.  The subsequent
   RecordItem elements may be signed by the peer adding the incident information for
   the investigation. -->
        A second benefit to this requirement is that the
        integrity of the filter used is ensured as it is passed to subsequent
        entities in the upstream trace of the incident.  The trusted PKI also
        provides the keys used to digitally sign the selected data element for
        a Request to meet the requirement of authenticating the original
        request.  Any host in the path of the trace should be able to verify
        the digital signature using the trusted PKI.</t>
      
      <t>In the case in which an enterprise using GRC-Exchange sends a
        Request to its provider, the signature from the enterprise
        MUST be included in the initial request.  The provider may generate
        a new request to send upstream to members of the provider's consortium to
        continue the request.  If the original request is sent, the originating
        provider, acting on behalf of the enterprise network with a request, MUST
        also digitally sign, with an enveloped signature, the full included XML
        document to assure the authenticity of the Request.  A provider that
        offers GRC-Exchange as a service may be using its own PKI to secure GRC-Exchange
        communications between its GRC-Exchange system and the attached enterprise
        networks.  Providers participating in the trace MUST be able to determine
        the authenticity of GRC-Exchange requests.</t>
    </section>
  </section>
  

  <section title="Consortiums and Public Key Infrastructures" anchor="sec-consortiums-pki">
    <t>Consortiums are an ideal way to establish a communication web
      of trust for GRC-Exchange messaging.  It should be noted that direct relationships may be ideal for some communications, such as those between a provider of incident information and a subscriber of the incident reports.  The consortium could provide centralized
      resources, such as a PKI, and established guidelines and control requirements for use of GRC-Exchange.  The consortium may assist in establishing trust
      relationships between the participating providers to achieve the necessary
      level of cooperation and experience-sharing among the consortium
      entities.  This may be established through PKI certificate policy
      <xref target="RFC3647"/> reviews to determine the appropriate trust levels between
      organizations or entities.  The consortium may also be used for other
      purposes to better facilitate communication among providers in a common
      area (Internet, region, government, education, private networks,
      etc.).</t>
    
    <t>Using a PKI to distribute certificates used by GRC-Exchange systems provides
      an already established method to link trust relationships between consortiums that peer with SPs belonging to a separate
      consortium.  In other words, consortiums could peer with other
      consortiums to enable communication of GRC-Exchange messages between the
      participating providers.  The PKI along with Memorandums of Agreement could
      be used to link border directories to share public key information in
      a bridge, a hierarchy, or a single cross-certification relationship.</t>
    
    <t>Consortiums also need to establish guidelines for each participating
      provider to adhere.  The RECOMMENDED guidelines include:
      
      <list style="symbols">
        <t>Physical and logical practices to protect GRC-Exchange systems;</t>
        
        <t>Network and application layer protection for GRC-Exchange systems and
          communications;</t>
        
        <t>Proper use guidelines for GRC-Exchange systems, messages, and requests; and</t>
        
        <t>A PKI, certificate policy, and certification practices statement to provide authentication, integrity, and privacy.</t>
      </list>
    </t>
    
    <t>The functions described for a consortium's role parallel that
      of a PKI federation.  The PKI federations that currently exist are
      responsible for establishing security guidelines and PKI trust
      models.  The trust models are used to support applications to share
      information using trusted methods and protocols.</t>
    
    <t>A PKI can also provide the same level of security for communication
      between an end entity (enterprise, educational, or government
      customer network) and the provider.</t>
  </section>
  
  <section title="Privacy Concerns and System Use Guidelines" anchor="sec-privacy-system-use">
    <t>Information sharing typically raises many concerns especially when privacy related information may be exchanged.  The GRCPolicy class is used to automate the enforcement of the privacy concerns listed within this document.  The privacy and system use concerns for the system communicating GRC-Exchange messages and other integrated components include the following:</t>
    
    <t>Service Provider Concerns:
      
      <list style="symbols">
        <!-- REOMVED:
      <t>Privacy of data monitored and/or stored on Intrusion Detection Systems (IDSs) for attack
      detection.</t>
      
     <t>Privacy of data monitored and stored on systems used to trace
      traffic across a single network.</t>
      
     <t>Privacy of incident information stored on incident management systems participating in GRC-Exchange communications.</t> 
-->
        
        <t>Privacy information contained in Human Resources, legal, compliance and other reports. </t>
      </list>
    </t>
    <t>Customer Attached Networks Participating in GRC-Exchange with Provider:
      <list style="symbols">
        <t>Customer networks may include an enterprise, educational,
          government, or other attached networks to a provider participating in
          GRC-Exchange.  Customers should review data handling policies to understand how data will be protected by a service provider.   This information will enable customers to decide what types of data at what sensitivity level can be shared with service providers.  This information could be used at the application layer to establish sharing profiles for entities and groups, see <xref target="sec-sharing-profiles-and-policies"/>.</t>
        
        <t>Customers should request information on the security and privacy considerations in
          place by their provider and the consortium of which the provider is a member.  Customers should understand if their data were to be forwarded, how might it be sanitized and how will it be protected.  Customers should also understand if limitations can be placed on how any data they share with their provider will be used in advance of sharing that data.</t>
        
        <t>Customers should be aware that their data can and will be sent to
          other providers in order to complete a request unless an agreement stating
          otherwise is made in the service level agreements between the
          customer and provider.  Customers considering privacy options may limit the use of this feature if they do not want the data forwarded.</t>
      </list>
    </t>

    <t>Parties Involved in Exchanges:
      <list style="symbols">
        <!--     <t>Privacy of the identity of a host involved in an attack or any indicators of compromise.</t> -->
        
        <t>Privacy of information such as the source and destination used for
          communication purposes over the monitored or GRC-Exchange connected
          network(s).</t>
        
        <t>Protection of data from being viewed by intermediate parties in
          the path of an Request request should be considered.</t>
        <!-- TODO: P2: Added below, but not really descriptive enough, placeholder -->
        <t>Privacy of information exchanged in reports. </t>
      </list>
    </t>

    <t>Consortium Considerations:
      <list style="symbols">
        <t>System use restrictions for information sharing within the
          local region's definitions of appropriate traffic.  When participating in a consortium, appropriate use guidelines should be agreed upon and entered into contracts.</t>
        
        <t>System use prohibiting the consortium's participating providers from
          inappropriately requesting information unlawfully within the jurisdiction or region.</t>
      </list>
    </t>

    <t>Inter-Consortium Considerations:
      <list style="symbols">
        <t>System use between peering consortiums should consider any
          government communication regulations that apply between those two
          regions, such as encryption export and import restrictions.</t>
        
        <t>System use between consortiums SHOULD NOT request information and
          actions beyond the scope intended and permitted by law or
          inter-consortium agreements.</t>
        
        <t>System use between consortiums should consider national boundary issues
          and request limits in their appropriate system use agreements.  Appropriate use should include restrictions to prevent the use of the protocol to limit or restrict traffic that is otherwise
          permitted within the country in which the peering consortium
          resides.</t>
      </list>
    </t>
    
    <t>The security and privacy considerations listed above are for the
      consortiums, providers, and enterprises to agree upon.  The agreed-upon
      policies may be facilitated through use of the GRCPolicy class and application layer options.  Some
      privacy considerations are addressed through the GRC-Exchange guidelines for
      encryption and digital signatures as described in
      <xref target="sec-xml-signature-encryption"/>.</t>
    
    <t>GRC-Exchange messaging privacy concerns should be elaborated on here...</t>
    <!-- Edit to remove content that is not relevant -->
    <t>Information shared through through GRC-Exchange could be sensitive.  Such data in GRC-Exchange messages can be protected through the use of encryption <xref target="W3C.REC-xmlenc-core-20021210"/> enveloping the XML and GRC-Exchange document, using the public encryption key of the originating entity.</t>
      
    <t>The decision is left to the system users and consortiums to determine appropriate data to be shared given that the goal of the specification is to provide the appropriate technical options to remain compliant.  Local, state, or national laws may dictate the appropriate reporting requirements for specific exchange types.</t>
    
    <t>Privacy becomes an issue whenever sensitive data traverses a network.</t>
      <!--   For example, if an attack occurred between a specific source and
   destination, then every SP in the path of the trace becomes aware that the cyber attack occurred.  In a targeted
   attack, it may not be desirable that information about two nation
   states that are battling a cyber war would become general knowledge
   to all intermediate parties.  However, it is important to allow the
   traces to take place in order to halt the activity since the health
   of the networks in the path could also be at stake during the attack.
   This provides a second argument for allowing the Result message to
   only include an action taken and not the identity of the offending
   host.  
-->
      
    <t>In the case of a Request or Report, where the originating provider is aware of the entity that will receive the request for processing, the free-form text areas of the document could be encrypted <xref target="W3C.REC-xmlenc-core-20021210"/> using the public key of the destination entity to ensure that no other entity in the path can read the contents.  The encryption is accomplished through the W3C <xref target="W3C.REC-xmlenc-core-20021210"/> specification for encrypting an element.</t>
    
    <!--
   <t>In some situations, all network traffic of a nation may be granted
   through a single SP.  In that situation, options must
   support sending Result messages from a downstream peer of that
   SP.  That option provides an additional level of
   abstraction to hide the identity and the SP of the identified source
   of the traffic.  Legal action may override this technical decision
   after the trace has taken place, but that is out of the technical
   scope of this document.</t>
-->
    
    <t>GRC Report Exchanges must be legitimate incidents and not used for purposes such as sabotage or censorship.  An example of such abuse of the system includes a report containing information about a competitor's compliance that may have been falsified to hurt their business.</t>
    
    <t>Intra-consortium GRC-Exchange communications raise additional issues, especially when the peering consortiums reside in different regions or nations.</t>
    
    <t>The GRC Report Exchange messages may be a valid use of the system within the confines of that country's network border; however, it may not be permitted to continue across network boundaries where such content is permitted under law.  A continued Request, Query, or Report into a second country may break the laws and regulations of that nation.  Any such messages MUST cease at the country's border.</t>
    
    <t>The privacy concerns listed in this section address issues among the trusted parties involved in a trace within an provider, a GRC-Exchange consortium, and peering GRC-Exchange consortiums.  Data used for GRC-Exchange communications must also be protected from parties that are not trusted.  This protection is provided through the authentication and encryption of documents as they traverse the path of trusted servers and the local security controls in place for the GRC Report Exchange systems.  Each GRC-Exchange system MUST perform a bi-directional authentication when sending a GRC-Exchange message and use the public encryption key of the upstream or downstream peer to send a message or document over the network.  This means that the
document is decrypted and re-encrypted at each GRC-Exchange system via TLS over a transport protocol such as [RFC6546].  The GRC-Exchange messages may be decrypted at each GRC-Exchange system in order to properly process the request or relay the information.  Today's processing power is more than sufficient to handle the minimal burden of encrypting and decrypting
relatively small typical GRC-Exchange messages.</t>
  </section>
  
  <section title="Sharing Profiles and Policies" anchor="sec-sharing-profiles-and-policies">
    <t>The application layer can be used to establish workflows and rulesets specific to sharing profiles for entities or consortiums.  The profiles can leverage sharing agreements to restrict data types or classifications of data that are shared.  The level of information or classification of data shared with any entity may be based on protection levels offered by the receiving entity and periodic validation of those controls.  The profile may also indicate how far information can be shared according to the entity and data type.  The profile can also support if requests to share data from an entity must go directly to that entity.</t>
    <t>In some cases, pre-defined sharing profiles will be possible.  These include any use case where an agreement is in place in advance of sharing.  Examples may be between clients and providers, entities such as partners, or consortiums.  There may be other cases when sharing profiles may not be established in advance.  An organization may want to establish sharing profiles specific to possible user groups to prepare for possible incident scenarios.  The user groups could include business partners, industry peers, service providers, experts not part of a service provider, law enforcement, or regulatory repotting bodies.</t>
    <t>Workflows to approve transactions may be specific to sharing profiles and data types.  Application developers should include capabilities to enable these decision points for users of the system.</t>
    <t>Any expectations between entities to preserve the weight and admissibility of evidence should be handled at the policy and agreement level.  A sharing profile may include notes or an indicator for approvers in workflows to reflect if such agreements exist.</t>
    
    
  </section>
</section>
  
<section title="Security Considerations" anchor="sec-security-considerations">
   <t>GRC Report Exchange has many security requirements and considerations built into the design of the protocol,
   several of which are described in the Security Requirements section.  For a
   complete view of security, considerations include the
   availability, confidentiality, and integrity concerns for the
   transport, storage, and exchange of information.</t>

   <t>Authenticated encrypted tunnels
   between systems accepting GRC-Exchange communications are used to provide confidentiality,
   integrity, authenticity, and privacy for the data at the transport layer.  Encryption and digital signatures are also used at the GRC XML document level through GRC-Exchange options to provide confidentiality, integrity, authenticity, privacy and traceability of the document contents.  Trust
   relationships may be through direct peers or consortiums using established trust
   relationships of public key infrastructure (PKI) via cross-certifications.  Trust levels can be established in cross-certification processes where entities compare PKI policies that include the specific management and handling of an entity's PKI and certificates issued under that policy.  <xref target="RFC3647"/> defines an Internet X.509 Public Key Infrastructure Certificate Policy and Certification Practices Framework that may be used in the comparison of policies to establish trust levels and agreements between entities, an entity and a consortium, and consortia.  The agreements SHOULD consider key management practices including the ability to perform path validation on certificates <xref target="RFC5280"/>, key distribution techniques <xref target="RFC2585"/>, Certificate Authority and Registration Authority management practices.</t>

<t>The agreements between entities SHOULD also include a common understanding of the usage of GRC-Exchange security, policy, and privacy options discussed in this section.  The formality, requirements, and complexity of the agreements for the certificate policy, practices, and the use of GRC-Exchange options SHOULD be decided by the entities or consortiums creating those agreements.</t>
</section>
<section title="IANA Considerations" anchor="sec-iana">
  <!-- TODO: From kathleen: We should include the new sections from RID for this so we can have IANA tables to extend attributes without having to update the RFC -->
  <t>This document uses URNs to describe XML namespaces <xref target="W3C.REC-xml-names-20091208"/> and XML schemas <xref target="W3C.REC-xmlschema-1-20041028"/> conforming to a registry mechanism described in <xref target="RFC3688"/>.</t>
  
  <t>Registration request for the grc-exchange namespace:
    <list>
      <t>URI: urn:ietf:params:xml:ns:grc-exchange-1.0</t>
      <t>Registrant Contact: See the "Author's Address" section of this document.</t>
      <t>XML: None.  Namespace URIs do not represent an XML specification.</t>
      <t>Registration request for the grc-exchange XML schema:</t>
      <t>URI: urn:ietf:params:xml:schema:grc-exchange-1.0</t>
      <t>Registrant Contact: See the "Author's Address" section of this document.</t>
      <t>XML: See <xref target="sec-schema"/>, "<xref target="sec-schema" format="title"/>", of this document.</t>
    </list>
  </t>
  <t>Request for the specified registry to be created and managed by IANA:
    <list>
      
      <t>Name of the registry:"XML Schemas Exchanged via GRC-Exchange"</t>
      <t>Namespace details:  A registry entry for an XML Schema Transferred via GRC-Exchange consists of:
        <list>
          <t>Schema Name:  A short string that represents the schema referenced.  This value is for reference only in the table.  The version of the schema MUST be included in this string to allow for multiple versions of the same specification to be in the registry.</t>
          <t>Version: The version of the registered XML schema.  The version is a string that SHOULD be formatted as numbers separated by a '.' (period) character.</t>
          <t>Namespace:  The namespace of the referenced XML schema.  This is represented in the GRC-Exchange GRCDocument class in the XMLSchemaID attribute as an enumerated value is represented by a URN or URI.</t>
          <t>Specification URI:  A URI <xref target="RFC3986"/> from which the registered specification can be obtained.  The specification MUST be publicly available from this URI.</t>
        </list>
      </t>
      <t>Information that must be provided to assign a new value: The above list of information.</t>
      <t>Fields to record in the registry: Schema Name/Version/Namespace/Specification URI</t>
      <t>Initial registry contents: See section <xref target="sec-iana"/></t>
      <t>Allocation Policy: Expert Review <xref target="RFC5226"/> and Specification Required <xref target="RFC5226"/>.</t>
    </list>
  </t>
  <t>The Designated Expert is expected to consult with the MILE (Managed
    Incident Lightweight Exchange) working group or its successor if any
    such WG exists (e.g., via email to the working group's mailing list).
    The Designated Expert is expected to retrieve the XML schema specification
    from the provided URI in order to check the public availability of
    the specification and verify the correctness of the URI.  An
    important responsibility of the Designated Expert is to ensure that
    the XML schema is appropriate for use in GRC-Exchange.</t>
  <t>Request for the specified registry to be created and managed by IANA:
    <list>
      
      <t>Name of the registry:"GRC-Exchange Enumeration List"</t>
      <t>The registry is intended to enable enumeration value additions to attributes in the grc-exchange XML schema.</t>
      <t>Fields to record in the registry: Attribute Name/Attribute Value/Description</t>
      <t>Initial registry content: none.</t>
      <t> Allocation Policy: Expert Review <xref target="RFC5226"/></t>
    </list>
  </t>
  <t>The Designated Expert is expected to consult with the mile (Managed
    Incident Lightweight Exchange) working group or its successor if any
    such WG exists (e.g., via email to the working group's mailing list).
    The Designated Expert is expected to review the request and validate the appropriateness of the enumeration for the attribute.  If a draft specification is associated with the request, it MUST be reviewed by the Designated Expert.</t>
  
</section>
  <section title="Acknowledgements" anchor="sec-acknowledgements">
    <t>Many thanks to colleagues and the Internet community for reviewing and
      commenting on the document.</t>
    <!-- TODO: From kathleen: Authors of IODEF and RID - we need to acknowledge their work since text is included.  Especially IODEF as they are not authors on this document.  There was a WG-Chair discussion recently that covered this issue of using text even posted to a mailing list - how much means someone is added as an editor.  Minimum was Acknowledgements. -->
  </section>
  
<section title="Summary" anchor="sec-summary">
   <t>Governance, Risk, and Compliance reports may contain some of the most sensitive information for a business.  Reports may contain the prioritized risks for the effective management of Business Operations, IT, Security, Compliance, and Legal departments of an enterprise.  There may be a regulatory or legal requirement to share information or formatted reports with a regulatory body or other entities in a legal review.  Outsourcing of computer infrastructure has necessitated the need for service providers to share reports with tenants or clients to ensure SLAs and agreements on security requirements are met.  Each of these use cases require a secure method to exchange reports.  GRC Report Exchange provides a standardized method to exchange reports while considering the security, privacy and policy requirements without relying on the transport layer for security.  Security is provided at the document level to provide methods to share a report where policy requirements can be implemented by mapping to technical options and data markers in the GRC-Exchange protocol.</t>

</section>
</middle>

<back>
<references title="Normative References">
  &RFC2119;
  &RFC2585;
  &RFC3275;
  &RFC3339;
  &RFC3688;
  &RFC3986;
  &RFC4051;
  &RFC4279;
  &RFC4519;
  &RFC5070;
  &RFC5280;
  &RFC5322;
  &RFC5646;
  &RFC5755;
  &RFC5890;
  &RFC5891;
  <reference anchor="RFC6545">
    <front>
      <title abbrev="RID">Real-time Inter-network Defense (RID)</title>
      <author initials="K." surname="Moriarty" fullname="Kathleen M. Moriarty">
        <organization abbrev="EMC">EMC Corporation</organization>
        <address>
          <postal>
            <street>176 South Street</street>
            <city>Hopkinton, MA</city>
            <country>United States</country>
          </postal>
          <phone></phone>
          <email>Kathleen.Moriarty@emc.com</email>
        </address>
      </author>
      <date month='February' year='2012' />
    </front>
    <seriesInfo name="RFC" value="6545" /> 
  </reference>
  <!-- TODO: update to 6546 -->
<!--  &RFC6046;-->
  &XML1.0;
  <!-- TODO: find reference or eliminate -->
  &XMLNames;
  &XMLencrypt;
  &XMLschema;
  &XMLdsig;
  &XMLdsig1.1;
  &XMLSigBP;
  &XMLPath20;
</references>

<references title="Informative References">
  <!-- TODO: these are referenced as normative -->
  &RFC4180;
  &RFC6194;
  <!-- end TODO -->

  &RFC3492;
  &RFC4765;
  &RFC3647;
  <!-- QUESTION: P1: Not sure if this should be normative -->
  &RFC5226;
  <reference anchor="ISO.8601.2000">
    <front>
      <title>Data elements and interchange formats -- Information interchange -- Representation of dates and times</title>
      <author>
        <organization>International Organization for Standardization</organization> 
      </author>
      <date month="December" year="2000" /> 
    </front>
    <seriesInfo name="ISO" value="Standard 8601" /> 
  </reference>
</references>

</back>
</rfc>