XMLencrypt] and digital signatures [RFC3275] [XMLsig]. The standards provide clear methods to ensure that messages are secure, authenticated, and authorized; meet policy and privacy guidelines; and maintain integrity. XML
Signature Best Practices [XMLSigBP] should be referenced by implementers for information on improving security to mitigate attacks. As specified in the relevant sections of this document, the XML digital signature [RFC3275] and XML encryption [XMLencrypt] are used in the following cases: XML Digital Signature o 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 RID message within the Signature element of the ReportSchema class. This signature MUST be passed to all recipients of the Request message. o 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: RecordData class ([RFC5070], Section 3.19.1) is used for this purpose. o For all message types, the full IODEF-RID document MUST be signed using an enveloped signature by the sending peer to provide authentication and integrity to the receiving RID system. The signature is placed in an instance of the Signature element. o XML Signature Best Practices [XMLSigBP] 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 the recommendation to limit the use of URIs since they may enable cross-site scripting attacks or access to local information.
o XML Path Language (XPath) 2.0 [XMLPath] 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 [XMLSigBP] 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 [XMLSigBP]. XML Encryption o The IODEF-RID document MAY be encrypted to provide an extra layer of security between peers so that not only the message is 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 RIDPolicy class needs to be presented in clear text, as detailed in the transport document [RFC6546]. o A Request, or any other message type that may be relayed through RID 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 RID 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 RIDPolicy class is used by intermediate parties and as such, RIDPolicy is maintained in clear text. o The action taken in the Result message may be encrypted using the key of the request originator. In that case, the intermediate parties can view the RIDPolicy information and know the trace has been completed and do not need to see the action. 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 IODEF-RID 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. o The iodef:restriction attribute sets expectations for the privacy of an incident and is defined in Section 3.2 of RFC 5070. Following the guidance for XML encryption in the Security Requirements section, the iodef:restriction attribute can be set in any of the RID classes to define restrictions and encryption requirements for the exchange of incident information. The restriction options enable encryption capabilities for the
complete exchange of an IODEF document (including any extensions), within specific classes of IODEF, or IODEF extensions, where more limited restrictions are desired. The restriction attribute is contained in each of the RID classes and MUST be used in accordance with confidentiality expectations for either sections of the IODEF document or the complete IODEF document. Consortiums and organizations should consider this guidance when creating exchange policies. o Expectations based on how restriction is set: * 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 9.3 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 be encrypted with a single group key. The method used SHOULD adhere to any certificate policy and practices agreements between entities for the use of RID. 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 the user's 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 incident to share 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. o Expectations based on placement of the restriction setting: * If restriction is set within one of the RID classes, the restriction applies to the entire IODEF document. * If restriction is set within individual IODEF classes, the restriction applies to the specific IODEF class and the children of that class.
The formation of policies is a very important aspect of using a messaging system like RID 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 9.4 and 9.5 for additional information on consortiums and PKI considerations. The security considerations for the storage and exchange of information in RID messaging may include adherence to local, regional, or national regulations in addition to the obligations to protect client information during an investigation. RIDPolicy 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. RID provides a method to exchange incident-handling requests and Report messages between entities. Administrators have the ability to base decisions on the available resources and other factors of their network and maintain control of incident investigations within their own network. Thus, RID provides the ability for participating networks to manage their own security controls, leveraging the information listed in RIDPolicy. RID is used to transfer or exchange XML documents in an IODEF format or using another 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. RFC6546]. The specified transport protocols MUST use encryption to provide an additional level of security and integrity, while supporting mutual authentication through bidirectional certificate usage. Any subsequent transport method defined should take advantage of existing standards for ease of implementation and integration of RID systems. Session encryption for the transport of RID messages is enforced in the transport specification. The privacy and security considerations are addressed fully in RID to protect sensitive portions of documents and to provide a method to authenticate the messages. Therefore, RID messages do not rely on the security provided by the transport layer alone. The encryption requirements and considerations for RID messages are discussed in Section 9.1 of this document.
Consortiums may vary their selected transport mechanisms and thus decide upon a mutual protocol to use for transport when communicating with peers in a neighboring consortium using RID. RID systems MUST implement and deploy HTTPS as defined in the transport document [RFC6546] and optionally MAY support other protocols such as the Blocks Extensible Exchange Protocol (BEEP) [RFC3080]. Bindings would need to be defined to enable support for other transport protocols. Systems used to send authenticated RID messages between networks MUST use a secured system and interface to connect to a border network's RID systems. Each connection to a RID system MUST meet the security requirements agreed upon through the consortium regulations, peering, or SLAs. The RID system MUST listen for and send RID messages on only the designated port, which also MUST be over an encrypted tunnel meeting the minimum requirement of algorithms and key lengths established by the consortium, peering, or SLA. The selected cryptographic algorithms for symmetric encryption, digital signatures, and hash functions MUST meet minimum security levels of the times. The encryption strength MUST adhere to import and export regulations of the involved countries for data exchange. Out-of-band communications dedicated to SP interaction for RID messaging would provide additional security as well as guaranteed bandwidth during a denial-of-service attack. For example, an out-of- band channel may consist of logical paths defined over the existing network. Out-of-band communications may not be practical or possible between service providers, but provisions should be considered to protect the incident management systems used for RID messaging. Methods to protect the data transport may also be provided through session encryption. 9.4 and 9.5. The use of PKI between entities or by a consortium SHOULD adhere to any applicable certificate policy and practices agreements for the use of RID. [RFC3647] specifies a commonly used format for
certificate policy (CP) and certification practices statements (CPS). Systems with predefined relationships for RID 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 RID operating procedures. The initial comparison of policies and the ability to audit controls provide 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 RID policies and operating procedures. XML security functions utilized in RID 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 RID protocol. The CA used for RID 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 RID transport protocol [RFC6546]. 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 RID XML messages MUST follow the World Wide Web Consortium (W3C) recommendations for signature syntax and processing when either the XML encryption [XMLencrypt] or digital signature [XMLsig] [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]. 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 [RFC5280]. In order to accommodate that requirement, the RecordItem data MUST remain unchanged as a request is passed along between providers and is the only 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 SPs in the upstream trace of the incident. The trusted PKI also provides the keys used to digitally sign the RecordItem class 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 RID sends a Request to its provider, the signature from the enterprise MUST be included in the initial request. The SP may generate a new request to send upstream to members of the SP consortium to continue the investigation. If the original request is sent, the originating SP, acting on behalf of the enterprise network under attack, MUST also digitally sign, with an enveloped signature, the full IODEF document to assure the authenticity of the Request. An SP that offers RID as a service may be using its own PKI to secure RID communications between its RID system and the attached enterprise networks. SPs participating in the trace MUST be able to determine the authenticity of RID requests. 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 SPs in a common area (Internet, region, government, education, private networks, etc.). Using a PKI to distribute certificates used by RID 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 RID messages between the participating SPs. 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 SP to adhere to. The RECOMMENDED guidelines include: o Physical and logical practices to protect RID systems; o Network- and application-layer protection for RID systems and communications; o Proper use guidelines for RID systems, messages, and requests; and o A PKI, certificate policy, and certification practices statement to provide authentication, integrity, and privacy. The functions described for a consortium's role parallel those 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 SP.
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 9.6. o Customers should request information on the security and privacy considerations in place by their SP and the consortium of which the SP is a member. Customers should understand if their data were to be forwarded, how it might be sanitized and how it will be protected. In advance of sharing data with their SP, customers should also understand if limitations can be placed on how it will be used. o Customers should be aware that their data can and will be sent to other SPs in order to complete a trace unless an agreement stating otherwise is made in the service level agreements between the customer and SP. Customers considering privacy options may limit the use of this feature if they do not want the data forwarded. Parties Involved in the Attack: o Privacy of the identity of a host involved in an attack or any indicators of compromise. o Privacy of information such as the source and destination used for communication purposes over the monitored or RID-connected network(s). o Protection of data from being viewed by intermediate parties in the path of an Request request should be considered. Consortium Considerations: o System use restrictions for security incident handling 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. o System use prohibiting the consortium's participating SPs from inappropriately tracing traffic to locate sources or mitigate traffic unlawfully within the jurisdiction or region. Inter-Consortium Considerations: o System use between peering consortiums should consider any government communication regulations that apply between those two regions, such as encryption export and import restrictions.
o System use between consortiums SHOULD NOT request traffic traces and actions beyond the scope intended and permitted by law or inter-consortium agreements. o 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 for limiting or restricting 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, SPs, and enterprises to agree upon. The agreed-upon policies may be facilitated through use of the RIDPolicy class and application-layer options. Some privacy considerations are addressed through the RID guidelines for encryption and digital signatures as described in Section 9.1. RID is useful in determining the true source of an incident that traverses multiple networks or to communicate security incidents and automate the response. The information obtained from the investigation may determine the identity of the source host or the SP used by the source of the traffic. It should be noted that the trace mechanism used across a single SP may also raise privacy concerns for the clients of the network. Methods that may raise concern include those that involve storing packets for some length of time in order to trace packets after the fact. Monitoring networks for intrusions and for tracing capabilities also raises concerns for potentially sensitive valid traffic that may be traversing the monitored network. IDSs and single-network tracing are outside of the scope of this document, but the concern should be noted and addressed within the use guidelines of the network. Some IDSs and single-network trace mechanisms attempt to properly address these issues. RID is designed to provide the information needed by any single-network trace mechanism. The provider's choice of a single trace mechanism depends on resources, existing solutions, and local legislation. Privacy concerns in regard to the single-network trace must be dealt with at the client-to-SP level and are out of scope for RID messaging. The identity of the true source of an attack being traced through RID could be sensitive. The true identity listed in a Result message can be protected through the use of encryption [XMLencrypt] enveloping the IODEF document and RID Result information, using the public encryption key of the originating SP. Alternatively, the action taken may be listed without the identity being revealed to the originating SP. The ultimate goal of the RID communication system is to stop or mitigate attack traffic, not to ensure that the identity of the attack traffic is known to involved parties. The SP that
identifies the source should deal directly with the involved parties and proper authorities in order to determine the guidelines for the release of such information, if it is regarded as sensitive. In some situations, systems used in attacks are compromised by an unknown source and, in turn, are used to attack other systems. In that situation, the reputation of a business or organization may be at stake, and the action taken may be the only additional information reported in the Result message to the originating system. If the security incident is a minor incident, such as a zombie system used in part of a large-scale DDoS attack, ensuring the system is taken off the network until it has been fixed may be sufficient. 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. The textual descriptions should include details of the incident in order to protect the reputation of the unknowing attacker and prevent the need for additional investigation. Local, state, or national laws may dictate the appropriate reporting action for specific security incidents. Privacy becomes an issue whenever sensitive data traverses a network. 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. In the case of a Request or Report, where the originating SP is aware of the SP that will receive the request for processing, the free-form text areas of the document could be encrypted [XMLencrypt] using the public key of the destination SP to ensure that no other SP in the path can read the contents. The encryption is accomplished through the W3C [XMLencrypt] specification for encrypting an element. 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.
Privacy concerns when using an Request message to request action close to the source of valid attack traffic need to be considered. Although the intermediate SPs may relay the request if there is no direct trust relationship to the closest SP to the source, the intermediate SPs do not require the ability to see the contents of the packet or the text description field(s) in the request. This message type does not require any action by the intermediate RID systems, except to relay the packet to the next SP in the path. Therefore, the contents of the request may be encrypted for the destination system. The intermediate SPs only need to know how to direct the request to the manager of the ASN in which the source IP address belongs. Traces must be legitimate security-related incidents and not used for purposes such as sabotage or censorship. An example of such abuse of the system includes a request to block or rate-limit legitimate traffic to prevent information from being shared between users on the Internet (restricting access to online versions of papers) or restricting access from a competitor's product in order to sabotage a business. Intra-consortium RID communications raise additional issues, especially when the peering consortiums reside in different regions or nations. Request messages and requested actions to mitigate or stop traffic must adhere to the appropriate use guidelines and yet prevent abuse of the system. First, the peering consortiums must identify the types of traffic that can be traced between the borders of the participating SPs of each consortium. The traffic traced should be limited to security-incident-related traffic. Second, the traces permitted within one consortium, if passed to a peering consortium, may infringe upon the peering consortium's freedom-of- information laws. An example would be a consortium in one country permitting a trace of traffic containing objectionable material, outlawed within that country. The RID trace 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. By continuing the trace in another country's network, the trace and response could have the effect of improperly restricting access to data. A continued trace into a second country may break the laws and regulations of that nation. Any such traces 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 SP, a RID consortium, and peering RID consortiums. Data used for RID 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 through the local security controls in place for the incident management systems. Each RID system MUST perform a bidirectional authentication when sending a RID 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 RID system via TLS over a transport protocol such as [RFC6546]. The RID messages may be decrypted at each RID 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 RID messages.
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 consortiums. The agreements SHOULD consider key management practices including the ability to perform path validation on certificates [RFC5280], key distribution techniques [RFC2585], and Certificate Authority and Registration Authority management practices. The agreements between entities SHOULD also include a common understanding of the usage of RID security, policy, and privacy options discussed in both the Security Requirements and Security Considerations sections. The formality, requirements, and complexity of the agreements for the certificate policy, practices, supporting infrastructure, and the use of RID options SHOULD be decided by the entities or consortiums creating those agreements. RFC5070], Section 3.16. However, that document did not clearly specify whether a NodeName could be an Internationalized Domain Name (IDN). RID systems MUST treat the NodeName class as a domain name slot [RFC5890]. RID 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 RID 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]. XMLschema] conforming to a registry mechanism described in [RFC3688]. Registration request for the iodef-rid namespace: URI: urn:ietf:params:xml:ns:iodef-rid-2.0 Registrant Contact: IESG. XML: None. Namespace URIs do not represent an XML specification. Registration request for the iodef-rid XML schema: URI: urn:ietf:params:xml:schema:iodef-rid-2.0 Registrant Contact: IESG. XML: See Section 8, "RID Schema Definition", of this document. The following registry has been created and is now managed by IANA: Name of the registry: "XML Schemas Exchanged via RID" Namespace details: A registry entry for an XML Schema Transferred via RID 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 RID ReportSchema 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. Reference: The reference to the document that describes the schema. 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, Reference Initial registry contents: See Section 5.6.1. 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 RID. The following registry has been created and is now managed by IANA: Name of the registry: "RID Enumeration List" The registry is intended to enable enumeration value additions to attributes in the iodef-rid XML schema. Fields to record in the registry: Attribute Name, Attribute Value, Description, Reference 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 specification is associated with the request, it MUST be reviewed by the Designated Expert. [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.
[RFC3023] Murata, M., St. Laurent, S., and D. Kohn, "XML Media Types", RFC 3023, January 2001. [RFC3275] Eastlake, D., Reagle, J., and D. Solo, "(Extensible Markup Language) XML-Signature Syntax and Processing", RFC 3275, March 2002. [RFC3470] Hollenbeck, S., Rose, M., and L. Masinter, "Guidelines for the Use of Extensible Markup Language (XML) within IETF Protocols", BCP 70, RFC 3470, January 2003. [RFC3492] Costello, A., "Punycode: A Bootstring encoding of Unicode for Internationalized Domain Names in Applications (IDNA)", RFC 3492, March 2003. [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, January 2004. [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. [RFC5070] Danyliw, R., Meijer, J., and Y. Demchenko, "The Incident Object Description Exchange Format", RFC 5070, December 2007. [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008. [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. [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. [RFC6546] Trammell, B., "Transport of Real-time Inter-network Defense (RID) Messages over HTTP/TLS", RFC 6546, April 2012. [XML1.0] Bray, T., Maler, E., Paoli, J., Sperberg-McQueen, C., and F. Yergeau, "Extensible Markup Language (XML) 1.0", W3C Recommendation XML 1.0, November 2008, <http://www.w3.org/TR/xml/>. [XMLCanon] Boyer, J., "Canonical XML 1.0", W3C Recommendation 1.0, December 2001, <http://www.w3.org/TR/xml-c14n>. [XMLPath] Berglund, A., Boag, S., Chamberlin, D., Fernandez, M., Kay, M., Robie, J., and J. Simeon, "XML Schema Part 1: Structures", W3C Recommendation Second Edition, December 2010, <http://www.w3.org/TR/xpath20/>. [XMLSigBP] Hirsch, F. and P. Datta, "XML-Signature Best Practices", W3C Recommendation, August 2011, <http://www.w3.org/TR/xmldsig-bestpractices/>. [XMLencrypt] Imaura, T., Dillaway, B., and E. Simon, "XML Encryption Syntax and Processing", W3C Recommendation, December 2002, <http://www.w3.org/TR/xmlenc-core/>. [XMLschema] Thompson, H., Beech, D., Maloney, M., and N. Mendelsohn, "XML Schema Part 1: Structures", W3C Recommendation Second Edition, October 2004, <http://www.w3.org/TR/xmlschema-1/>. [XMLsig] Bartel, M., Boyer, J., Fox, B., LaMaccia, B., and E. Simon, "XML-Signature Syntax and Processing", W3C Recommendation Second Edition, June 2008, <http://www.w3.org/TR/xmldsig-core/>. [RFC1930] Hawkinson, J. and T. Bates, "Guidelines for creation, selection, and registration of an Autonomous System (AS)", BCP 6, RFC 1930, March 1996. [RFC3080] Rose, M., "The Blocks Extensible Exchange Protocol Core", RFC 3080, March 2001.
[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. [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005. [RFC5735] Cotton, M. and L. Vegoda, "Special Use IPv4 Addresses", BCP 153, RFC 5735, January 2010. [RFC6045] Moriarty, K., "Real-time Inter-network Defense (RID)", RFC 6045, November 2010. [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. [XMLNames] Bray, T., Hollander, D., Layman, A., Tobin, R., and H. Thomson, "Namespaces in XML 1.0 (Third Edition)", W3C Recommendation , December 2009, <http://www.w3.org/TR/xml-names/>.