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

Figure 18: Query Communication Flow

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.

If there is a problem with the Query message, such as a failure to validate the digital signature [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.

7.3.1. Query Example

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.

Example to be provided in an updated version of this document.

7.3.2. Acknowledgement Message Example

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.

Example to be provided in an updated version of this document.

7.3.3. Result Message Example

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.

Example to be provided in an updated version of this document.

8. Internationalization Issues

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.

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 Section 2.12 of [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 [RFC5646].

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.

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.

The Node class identifies a host or network device. This document re-uses the definition of Node from the IODEF specification [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 [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 [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 [RFC3492] for A-labels as described in the protocol specification for Internationalized Domain Names in Applications [RFC5891].

9. GRC-Exchange Schema Definition

<?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  ***

10. Requirements for GRC XML Schemas for GRC-Exchange

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) [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.

• The restriction attribute, reused from IODEF [RFC5070] into GRC-Exchange, MUST be included in any individual class of a GRC XML schema that could require XML encryption [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.

11. Security Requirements

The content in this section is derived from RID [RFC6545].

11.1. XML Digital Signatures and Encryption

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 [W3C.REC-xmlenc-core-20021210] and digital signatures [RFC3275], [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.

As specified in the relevant sections of this document, the XML digital signature [RFC3275] and XML encryption [W3C.REC-xmlenc-core-20021210] are used in the following cases:

XML Digital Signature

• 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.
• XML Signature Best Practices [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.
• XML Path Language (XPath) 2.0 [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 [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 [W3C.WD-xmldsig-bestpractices-20110809].

XML Encryption

• 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].
• 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.
• 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.
• The restriction attribute sets expectations for the privacy of an incident and is defined in Section 4.1. 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.
• Expectations based on restriction setting:
  • 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 Section 11.2 for a discussion on public key infrastructure (PKI) and other security requirements.
  • 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.
  • 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.
  • If restriction is set to "default", The information can be shared according to an information disclosure policy pre-arranged by the communicating parties.

• Expectations based on placement of the restriction setting:
  • If restriction is set within one of the GRC-Exchange classes, the restriction applies to the entire included XML document.
  • 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.

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 11.3 and Section 11.4 for additional information on consortiums and PKI considerations.

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.

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.

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.

11.2. Public Key Infrastructure

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 11.3 and Section 11.4.

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. [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.

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].

11.2.1. Authentication

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 [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 [W3C.REC-xmlenc-core-20021210] or digital signature [W3C.REC-xmldsig-core-20080610], [RFC3275] is used within a document.

It might be helpful to define an extension to the authentication scheme that uses attribute certificates [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.

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)" [RFC4279] MUST be followed. Transport specifications are detailed in a separate document [RFC6546].

11.2.2. Multi-Hop Request Authentication

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.

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 GRC-Exchange From-Contact class nesting the list of systems and contacts involved in a request.

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 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 [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. 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.

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.

11.3. Consortiums and Public Key Infrastructures

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 [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.).

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.

Consortiums also need to establish guidelines for each participating provider to adhere. The RECOMMENDED guidelines include:

• Physical and logical practices to protect GRC-Exchange systems;
• Network and application layer protection for GRC-Exchange systems and communications;
• Proper use guidelines for GRC-Exchange systems, messages, and requests; and
• A PKI, certificate policy, and certification practices statement to provide authentication, integrity, and privacy.

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.

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.

11.4. Privacy Concerns and System Use Guidelines

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:

Service Provider Concerns:

• Privacy information contained in Human Resources, legal, compliance and other reports.

Customer Attached Networks Participating in GRC-Exchange with Provider:

• 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 Section 11.5.
• 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.
• 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.

Parties Involved in Exchanges:

• Privacy of information such as the source and destination used for communication purposes over the monitored or GRC-Exchange connected network(s).
• Protection of data from being viewed by intermediate parties in the path of an Request request should be considered.
• Privacy of information exchanged in reports.

Consortium Considerations:

• 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.
• System use prohibiting the consortium's participating providers from inappropriately requesting information unlawfully within the jurisdiction or region.

Inter-Consortium Considerations:

• System use between peering consortiums should consider any government communication regulations that apply between those two regions, such as encryption export and import restrictions.
• System use between consortiums SHOULD NOT request information and actions beyond the scope intended and permitted by law or inter-consortium agreements.
• 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.

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 Section 11.1.

GRC-Exchange messaging privacy concerns should be elaborated on here...

Information shared through through GRC-Exchange could be sensitive. Such data in GRC-Exchange messages can be protected through the use of encryption [W3C.REC-xmlenc-core-20021210] enveloping the XML and GRC-Exchange document, using the public encryption key of the originating entity.

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.

Privacy becomes an issue whenever sensitive data traverses a network.

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 [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 [W3C.REC-xmlenc-core-20021210] specification for encrypting an element.

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.

Intra-consortium GRC-Exchange communications raise additional issues, especially when the peering consortiums reside in different regions or nations.

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.

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.

11.5. Sharing Profiles and Policies

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.

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.

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.

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.

12. Security Considerations

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.

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. [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 [RFC5280], key distribution techniques [RFC2585], Certificate Authority and Registration Authority management practices.

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.

13. IANA Considerations

This document uses URNs to describe XML namespaces [W3C.REC-xml-names-20091208] and XML schemas [W3C.REC-xmlschema-1-20041028] conforming to a registry mechanism described in [RFC3688].

Registration request for the grc-exchange namespace:

• URI: urn:ietf:params:xml:ns:grc-exchange-1.0
• Registrant Contact: See the "Author's Address" section of this document.
• XML: None. Namespace URIs do not represent an XML specification.
• Registration request for the grc-exchange XML schema:
• URI: urn:ietf:params:xml:schema:grc-exchange-1.0
• Registrant Contact: See the "Author's Address" section of this document.
• XML: See Section 4, "GRC-Exchange Schema", of this document.

Request for the specified registry to be created and managed by IANA:

• Name of the registry:"XML Schemas Exchanged via GRC-Exchange"
• Namespace details: A registry entry for an XML Schema Transferred via GRC-Exchange consists of:
  • 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.
  • Version: The version of the registered XML schema. The version is a string that SHOULD be formatted as numbers separated by a '.' (period) character.
  • 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.
  • Specification URI: A URI [RFC3986] from which the registered specification can be obtained. The specification MUST be publicly available from this URI.

• Information that must be provided to assign a new value: The above list of information.
• Fields to record in the registry: Schema Name/Version/Namespace/Specification URI
• Initial registry contents: See section Section 13
• Allocation Policy: Expert Review [RFC5226] and Specification Required [RFC5226].

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.

Request for the specified registry to be created and managed by IANA:

• Name of the registry:"GRC-Exchange Enumeration List"
• The registry is intended to enable enumeration value additions to attributes in the grc-exchange XML schema.
• Fields to record in the registry: Attribute Name/Attribute Value/Description
• Initial registry content: none.
• Allocation Policy: Expert Review [RFC5226]

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.

14. Acknowledgements

Many thanks to colleagues and the Internet community for reviewing and commenting on the document.

15. Summary

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.

16. References

16.1. Normative References

[RFC2119]	Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2585]	Housley, R. and P. Hoffman, "Internet X.509 Public Key Infrastructure Operational Protocols: FTP and HTTP", RFC 2585, May 1999.
[RFC3275]	Eastlake, D., Reagle, J. and D. Solo, "(Extensible Markup Language) XML-Signature Syntax and Processing", RFC 3275, March 2002.
[RFC3339]	Klyne, G. and C. Newman, "Date and Time on the Internet: Timestamps", RFC 3339, July 2002.
[RFC3688]	Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, January 2004.
[RFC3986]	Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005.
[RFC4051]	Eastlake, D., "Additional XML Security Uniform Resource Identifiers (URIs)", RFC 4051, April 2005.
[RFC4279]	Eronen, P. and H. Tschofenig, "Pre-Shared Key Ciphersuites for Transport Layer Security (TLS)", RFC 4279, December 2005.
[RFC4519]	Sciberras, A., "Lightweight Directory Access Protocol (LDAP): Schema for User Applications", RFC 4519, June 2006.
[RFC5070]	Danyliw, R., Meijer, J. and Y. Demchenko, "The Incident Object Description Exchange Format", RFC 5070, December 2007.
[RFC5280]	Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R. and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, May 2008.
[RFC5322]	Resnick, P., "Internet Message Format", RFC 5322, October 2008.
[RFC5646]	Phillips, A. and M. Davis, "Tags for Identifying Languages", BCP 47, RFC 5646, September 2009.
[RFC5755]	Farrell, S., Housley, R. and S. Turner, "An Internet Attribute Certificate Profile for Authorization", RFC 5755, January 2010.
[RFC5890]	Klensin, J., "Internationalized Domain Names for Applications (IDNA): Definitions and Document Framework", RFC 5890, August 2010.
[RFC5891]	Klensin, J., "Internationalized Domain Names in Applications (IDNA): Protocol", RFC 5891, August 2010.
[RFC6545]	Moriarty, K., "Real-time Inter-network Defense (RID)", RFC 6545, February 2012.
[W3C.REC-xml-20081126]	Sperberg-McQueen, C., Yergeau, F., Maler, E., Paoli, J. and T. Bray, "Extensible Markup Language (XML) 1.0 (Fifth Edition)", World Wide Web Consortium Recommendation REC-xml-20081126, November 2008.
[W3C.REC-xml-names-20091208]	Hollander, D., Layman, A., Bray, T., Tobin, R. and H. Thompson, "Namespaces in XML 1.0 (Third Edition)", World Wide Web Consortium Recommendation REC-xml-names-20091208, December 2009.
[W3C.REC-xmlenc-core-20021210]	Eastlake, D. and J. Reagle, "XML Encryption Syntax and Processing", World Wide Web Consortium Recommendation REC-xmlenc-core-20021210, December 2002.
[W3C.REC-xmlschema-1-20041028]	Thompson, H., Beech, D., Mendelsohn, N. and M. Maloney, "XML Schema Part 1: Structures Second Edition", World Wide Web Consortium Recommendation REC-xmlschema-1-20041028, October 2004.
[W3C.REC-xmldsig-core-20080610]	Solo, D., Roessler, T., Eastlake, D., Hirsch, F. and J. Reagle, "XML Signature Syntax and Processing (Second Edition)", World Wide Web Consortium Recommendation REC-xmldsig-core-20080610, June 2008.
[W3C.CR-xmldsig-core1-20110303]	Eastlake, D., Nyström, M., Solo, D., Reagle, J., Roessler, T., Hirsch, F. and K. Yiu, "XML Signature Syntax and Processing Version 1.1", World Wide Web Consortium CR CR-xmldsig-core1-20110303, March 2011.
[W3C.WD-xmldsig-bestpractices-20110809]	Datta, P. and F. Hirsch, "XML Signature Best Practices", World Wide Web Consortium WD WD-xmldsig-bestpractices-20110809, August 2011.
[W3C.REC-xpath20-20101214]	Robie, J., Berglund, A., Fernández, M., Boag, S., Chamberlin, D., Siméon, J. and M. Kay, "XML Path Language (XPath) 2.0 (Second Edition)", World Wide Web Consortium Recommendation REC-xpath20-20101214, December 2010.

16.2. Informative References

[RFC4180]	Shafranovich, Y., "Common Format and MIME Type for Comma-Separated Values (CSV) Files", RFC 4180, October 2005.
[RFC6194]	Polk, T., Chen, L., Turner, S. and P. Hoffman, "Security Considerations for the SHA-0 and SHA-1 Message-Digest Algorithms", RFC 6194, March 2011.
[RFC3492]	Costello, A., "Punycode: A Bootstring encoding of Unicode for Internationalized Domain Names in Applications (IDNA)", RFC 3492, March 2003.
[RFC4765]	Debar, H., Curry, D. and B. Feinstein, "The Intrusion Detection Message Exchange Format (IDMEF)", RFC 4765, March 2007.
[RFC3647]	Chokhani, S., Ford, W., Sabett, R., Merrill, C. and S. Wu, "Internet X.509 Public Key Infrastructure Certificate Policy and Certification Practices Framework", RFC 3647, November 2003.
[RFC5226]	Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
[ISO.8601.2000]	International Organization for Standardization, "Data elements and interchange formats -- Information interchange -- Representation of dates and times", ISO Standard 8601, December 2000.

Authors' Addresses