doc: Add RFC documents

1 files changed, 731 insertions, 0 deletions

diff --git a/doc/rfc/rfc7481.txt b/doc/rfc/rfc7481.txt
new file mode 100644
index 0000000..a7e4093
--- /dev/null
+++ b/doc/rfc/rfc7481.txt
@@ -0,0 +1,731 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF)                     S. Hollenbeck
+Request for Comments: 7481                                 Verisign Labs
+Category: Standards Track                                        N. Kong
+ISSN: 2070-1721                                                    CNNIC
+                                                              March 2015
+
+
+   Security Services for the Registration Data Access Protocol (RDAP)
+
+Abstract
+
+   The Registration Data Access Protocol (RDAP) provides "RESTful" web
+   services to retrieve registration metadata from Domain Name and
+   Regional Internet Registries.  This document describes information
+   security services, including access control, authentication,
+   authorization, availability, data confidentiality, and data integrity
+   for RDAP.
+
+Status of This Memo
+
+   This is an Internet Standards Track document.
+
+   This document is a product of the Internet Engineering Task Force
+   (IETF).  It represents the consensus of the IETF community.  It has
+   received public review and has been approved for publication by the
+   Internet Engineering Steering Group (IESG).  Further information on
+   Internet Standards is available in Section 2 of RFC 5741.
+
+   Information about the current status of this document, any errata,
+   and how to provide feedback on it may be obtained at
+   http://www.rfc-editor.org/info/rfc7481.
+
+Copyright Notice
+
+   Copyright (c) 2015 IETF Trust and the persons identified as the
+   document authors.  All rights reserved.
+
+   This document is subject to BCP 78 and the IETF Trust's Legal
+   Provisions Relating to IETF Documents
+   (http://trustee.ietf.org/license-info) in effect on the date of
+   publication of this document.  Please review these documents
+   carefully, as they describe your rights and restrictions with respect
+   to this document.  Code Components extracted from this document must
+   include Simplified BSD License text as described in Section 4.e of
+   the Trust Legal Provisions and are provided without warranty as
+   described in the Simplified BSD License.
+
+
+
+
+
+Hollenbeck & Kong            Standards Track                    [Page 1]
+
+RFC 7481                 RDAP Security Services               March 2015
+
+
+Table of Contents
+
+   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
+   2.  Conventions Used in This Document . . . . . . . . . . . . . .   2
+     2.1.  Acronyms and Abbreviations  . . . . . . . . . . . . . . .   3
+   3.  Information Security Services and RDAP  . . . . . . . . . . .   3
+     3.1.  Access Control  . . . . . . . . . . . . . . . . . . . . .   3
+     3.2.  Authentication  . . . . . . . . . . . . . . . . . . . . .   3
+       3.2.1.  Federated Authentication  . . . . . . . . . . . . . .   4
+     3.3.  Authorization . . . . . . . . . . . . . . . . . . . . . .   6
+     3.4.  Availability  . . . . . . . . . . . . . . . . . . . . . .   6
+     3.5.  Data Confidentiality  . . . . . . . . . . . . . . . . . .   7
+     3.6.  Data Integrity  . . . . . . . . . . . . . . . . . . . . .   7
+   4.  Privacy Threats Associated with Registration Data . . . . . .   8
+   5.  Security Considerations . . . . . . . . . . . . . . . . . . .   9
+   6.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  10
+     6.1.  Normative References  . . . . . . . . . . . . . . . . . .  10
+     6.2.  Informative References  . . . . . . . . . . . . . . . . .  11
+   Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .  13
+   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  13
+
+1.  Introduction
+
+   The Registration Data Access Protocol (RDAP) is specified in multiple
+   documents, including "Registration Data Access Protocol (RDAP) Query
+   Format" [RFC7482], "JSON Responses for the Registration Data Access
+   Protocol (RDAP)" [RFC7483], and "HTTP Usage in the Registration Data
+   Access Protocol (RDAP)" [RFC7480].
+
+   One goal of RDAP is to provide security services that do not exist in
+   the WHOIS [RFC3912] protocol, including access control,
+   authentication, authorization, availability, data confidentiality,
+   and data integrity.  This document describes how each of these
+   services is achieved by RDAP using features that are available in
+   other protocol layers.  Additional or alternative mechanisms can be
+   added in the future.  Where applicable, informative references to
+   requirements for a WHOIS replacement service [RFC3707] are noted.
+
+2.  Conventions Used in This Document
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+   document are to be interpreted as described in [RFC2119].
+
+
+
+
+
+
+
+
+Hollenbeck & Kong            Standards Track                    [Page 2]
+
+RFC 7481                 RDAP Security Services               March 2015
+
+
+2.1.  Acronyms and Abbreviations
+
+      DNR: Domain Name Registry
+
+      HTTP: Hypertext Transfer Protocol
+
+      JSON: JavaScript Object Notation
+
+      RDAP: Registration Data Access Protocol
+
+      RIR: Regional Internet Registry
+
+      TLS: Transport Layer Security
+
+3.  Information Security Services and RDAP
+
+   RDAP itself does not include native security services.  Instead, RDAP
+   relies on features that are available in other protocol layers to
+   provide needed security services, including access control,
+   authentication, authorization, availability, data confidentiality,
+   and data integrity.  A description of each of these security services
+   can be found in "Internet Security Glossary, Version 2" [RFC4949].
+   No requirements have been identified for other security services.
+
+3.1.  Access Control
+
+   WHOIS does not include specific features to control access to
+   registration information.  As described in the following sections,
+   RDAP includes features to identify, authenticate, and authorize
+   clients, allowing server operators to control access to information
+   based on a client's identity and associated authorizations.
+   Information returned to a client can be clearly marked with a status
+   value (see Section 10.2.2 of [RFC7483]) that identifies the access
+   granted to the client.
+
+3.2.  Authentication
+
+   This section describes security authentication mechanisms and the
+   need for authorization policies to include them.  It describes
+   requirements for the implementations of clients and servers but does
+   not dictate the policies of server operators.  For example, a server
+   operator with no policy regarding differentiated or tiered access to
+   data will have no authorization mechanisms and will have no need for
+   any type of authentication.  A server operator with policies on
+   differentiated access will have to construct an authorization scheme
+   and will need to follow the specified authentication requirements.
+
+
+
+
+
+Hollenbeck & Kong            Standards Track                    [Page 3]
+
+RFC 7481                 RDAP Security Services               March 2015
+
+
+   WHOIS does not provide features to identify and authenticate clients.
+   As noted in Section 3.1.4.2 of "Cross Registry Internet Service
+   Protocol (CRISP) Requirements" [RFC3707], there is utility in
+   allowing server operators to offer "varying degrees of access
+   depending on policy and need."  Clients have to be identified and
+   authenticated to provide that utility.
+
+   RDAP's authentication framework needs to accommodate anonymous access
+   as well as verification of identities using a range of authentication
+   methods and credential services.  To that end, RDAP clients and
+   servers MUST implement the authentication framework specified in
+   "Hypertext Transfer Protocol (HTTP/1.1): Authentication" [RFC7235].
+   The "basic" scheme can be used to send a client's user name and
+   password to a server in plaintext, base64-encoded form.  The "digest"
+   scheme can be used to authenticate a client without exposing the
+   client's plaintext password.  If the "basic" scheme is used, HTTP
+   over TLS [RFC2818] MUST be used to protect the client's credentials
+   from disclosure while in transit (see Section 3.5).
+
+   Servers MUST support either Basic or Digest authentication; they are
+   not required to support both.  Clients MUST support both to
+   interoperate with servers that support one or the other.  Servers may
+   provide a login page that triggers HTTP authentication.  Clients
+   should continue sending the HTTP authentication header once they
+   receive an initial 401 (Unauthorized) response from the HTTP server
+   as long as the scheme portion of the URL doesn't change.
+
+   The Transport Layer Security protocol [RFC5246] includes an optional
+   feature to identify and authenticate clients who possess and present
+   a valid X.509 digital certificate [RFC5280].  Support for this
+   feature is OPTIONAL.
+
+   RDAP does not impose any unique server authentication requirements.
+   The server authentication provided by TLS fully addresses the needs
+   of RDAP.  In general, transports for RDAP must either provide a
+   TLS-protected transport (e.g., HTTPS) or a mechanism that provides an
+   equivalent level of server authentication.
+
+   Work on HTTP authentication methods continues.  RDAP is designed to
+   be agile enough to support additional methods as they are defined.
+
+3.2.1.  Federated Authentication
+
+   The traditional client-server authentication model requires clients
+   to maintain distinct credentials for every RDAP server.  This
+   situation can become unwieldy as the number of RDAP servers
+   increases.  Federated authentication mechanisms allow clients to use
+   one credential to access multiple RDAP servers and reduce client
+
+
+
+Hollenbeck & Kong            Standards Track                    [Page 4]
+
+RFC 7481                 RDAP Security Services               March 2015
+
+
+   credential management complexity.  RDAP MAY include a federated
+   authentication mechanism that permits a client to access multiple
+   RDAP servers in the same federation with one credential.
+
+   Federated authentication mechanisms used by RDAP MUST be fully
+   supported by HTTP.  OAuth, OpenID, Security Assertion Markup Language
+   (SAML), and mechanisms based on Certification Authority (CA) are all
+   possible approaches to provide federated authentication.  At the time
+   of this document's publication, negotiation or advertisement of
+   federated authentication services is still an undefined mechanism by
+   the noted federated authentication protocols.  Developing this
+   mechanism is beyond the scope of this document.
+
+   The OAuth authorization framework [RFC6749] describes a method for
+   users to access protected web resources without having to hand out
+   their credentials.  Instead, clients are issued access tokens by
+   authorization servers with the permission of the resource owners.
+   Using OAuth, multiple RDAP servers can form a federation, and the
+   clients can access any server in the same federation by providing one
+   credential registered in any server in that federation.  The OAuth
+   authorization framework is designed for use with HTTP and thus can be
+   used with RDAP.
+
+   OpenID [OpenID] is a decentralized single sign-on authentication
+   system that allows users to log in at multiple web sites with one ID
+   instead of having to create multiple unique accounts.  An end user
+   can freely choose which OpenID provider to use and can preserve their
+   Identifier if they switch OpenID providers.
+
+   Note that OAuth and OpenID do not consistently require data
+   confidentiality services to protect interactions between providers
+   and consumers.  HTTP over TLS [RFC2818] can be used as needed to
+   provide protection against man-in-the-middle attacks.
+
+   SAML 2.0 [SAML] is an XML-based protocol that can be used to
+   implement web-based authentication and authorization services,
+   including single sign on.  It uses security tokens containing
+   assertions to exchange information about an end user between an
+   identity provider and a service provider.
+
+   The Transport Layer Security protocol describes the specification of
+   a client certificate in Section 7.4.6 of [RFC5246].  Clients who
+   possess and present a valid X.509 digital certificate, issued by a
+   CA, could be identified and authenticated by a server who trusts the
+   corresponding CA.  A certificate authentication method can be used to
+   achieve federated authentication in which multiple RDAP servers all
+   trust the same CAs, and then any client with a certificate issued by
+   a trusted CA can access any RDAP server in the federation.  This
+
+
+
+Hollenbeck & Kong            Standards Track                    [Page 5]
+
+RFC 7481                 RDAP Security Services               March 2015
+
+
+   certificate-based mechanism is supported by HTTPS and can be used
+   with RDAP.
+
+3.3.  Authorization
+
+   WHOIS does not provide services to grant different levels of access
+   to clients based on a client's authenticated identity.  As noted in
+   Section 3.1.4.2 of "Cross Registry Internet Service Protocol (CRISP)
+   Requirements" [RFC3707], there is utility in allowing server
+   operators to offer "varying degrees of access depending on policy and
+   need."  Access control decisions can be made once a client's identity
+   has been established and authenticated (see Section 3.2).
+
+   Server operators MAY offer varying degrees of access depending on
+   policy and need in conjunction with the authentication methods
+   described in Section 3.2.  If such varying degrees of access are
+   supported, an RDAP server MUST provide granular access controls (that
+   is, per registration data object) in order to implement authorization
+   policies.  Some examples:
+
+   -  Clients will be allowed access only to data for which they have a
+      relationship.
+
+   -  Unauthenticated or anonymous access status may not yield any
+      contact information.
+
+   -  Full access may be granted to a special group of authenticated
+      clients.
+
+   The type of access allowed by a server will most likely vary from one
+   operator to the next.  A description of the response privacy
+   considerations associated with different levels of authorization can
+   be found in Section 13 of [RFC7483].
+
+3.4.  Availability
+
+   An RDAP service has to be available to be useful.  There are no RDAP-
+   unique requirements to provide availability, but as a general
+   security consideration, a service operator needs to be aware of the
+   issues associated with denial of service.  A thorough reading of
+   "Internet Denial-of-Service Considerations" [RFC4732] is advised.
+
+   An RDAP service MAY use an HTTP throttling mechanism to limit the
+   number of queries that a single client can send in a given period of
+   time.  If used, the server SHOULD return an HTTP 429 (Too Many
+   Requests) response code as described in "Additional HTTP Status
+   Codes" [RFC6585].  A client that receives a 429 response SHOULD
+   decrease its query rate and honor the Retry-After header field if one
+
+
+
+Hollenbeck & Kong            Standards Track                    [Page 6]
+
+RFC 7481                 RDAP Security Services               March 2015
+
+
+   is present.  Note that this is not a defense against
+   denial-of-service attacks, since a malicious client could ignore the
+   code and continue to send queries at a high rate.  A server might use
+   another response code if it did not wish to reveal to a client that
+   rate limiting is the reason for the denial of a reply.
+
+3.5.  Data Confidentiality
+
+   WHOIS does not provide the ability to protect data from inadvertent
+   disclosure while in transit.  RDAP uses HTTP over TLS [RFC2818] to
+   provide that protection by encrypting all traffic sent on the
+   connection between client and server.  HTTP over TLS MUST be used to
+   protect all client-server exchanges unless operational constraints
+   make it impossible to meet this requirement.  It is also possible to
+   encrypt discrete objects (such as command path segments and JSON-
+   encoded response objects) at one endpoint, send them to the other
+   endpoint via an unprotected transport protocol, and decrypt the
+   object on receipt.  Encryption algorithms as described in "Internet
+   Security Glossary, Version 2" [RFC4949] are commonly used to provide
+   data confidentiality at the object level.
+
+   There are no current requirements for object-level data
+   confidentiality using encryption.  Support for this feature could be
+   added to RDAP in the future.
+
+   As noted in Section 3.2, the HTTP "basic" authentication scheme can
+   be used to authenticate a client.  When this scheme is used, HTTP
+   over TLS MUST be used to protect the client's credentials from
+   disclosure while in transit.  If the policy of the server operator
+   requires encryption to protect client-server data exchanges (such as
+   to protect non-public data that cannot be accessed without client
+   identification and authentication), HTTP over TLS MUST be used to
+   protect those exchanges.
+
+   A description of privacy threats that can be addressed with
+   confidentiality services can be found in Section 4.  Section 10.2.2
+   of [RFC7483] describes status values that can be used to describe
+   operator actions used to protect response data from disclosure to
+   unauthorized clients.
+
+3.6.  Data Integrity
+
+   WHOIS does not provide the ability to protect data from modification
+   while in transit.  Web services such as RDAP commonly use HTTP over
+   TLS [RFC2818] to provide that protection by using a keyed Message
+   Authentication Code (MAC) to detect modifications.  It is also
+   possible to sign discrete objects (such as command path segments and
+   JSON-encoded response objects) at one endpoint, send them to the
+
+
+
+Hollenbeck & Kong            Standards Track                    [Page 7]
+
+RFC 7481                 RDAP Security Services               March 2015
+
+
+   other endpoint via a transport protocol, and validate the signature
+   of the object on receipt.  Digital signature algorithms as described
+   in "Internet Security Glossary, Version 2" [RFC4949] are commonly
+   used to provide data integrity at the object level.
+
+   There are no current requirements for object-level data integrity
+   using digital signatures.  Support for this feature could be added to
+   RDAP in the future.
+
+   The most specific need for this service is to provide assurance that
+   HTTP 30x redirection hints [RFC7231] and response elements returned
+   from the server are not modified while in transit.  If the policy of
+   the server operator requires message integrity for client-server data
+   exchanges, HTTP over TLS MUST be used to protect those exchanges.
+
+4.  Privacy Threats Associated with Registration Data
+
+   Registration data has historically included personal data about
+   registrants.  WHOIS services have historically made this information
+   available to the public, creating a privacy risk by revealing the
+   personal details of registrants.  WHOIS services have not had the
+   benefit of authentication or access control mechanisms to gate access
+   to registration data.  As a result of this, proxy and privacy
+   services have arisen to shield the identities of registrants.
+
+   The standardization of RDAP does not change or impact the data that
+   operators may require to be collected from registrants, but it
+   provides support for a number of mechanisms that may be used to
+   mitigate privacy threats to registrants should operators choose to
+   use them.
+
+   RDAP includes mechanisms that can be used to authenticate clients,
+   allowing servers to support tiered access based on local policy.
+   This means that all registration data need no longer be public, and
+   personal data or data that may be considered more sensitive can have
+   its access restricted to specifically privileged clients.
+
+   RDAP data structures allow servers to indicate via status values when
+   data returned to clients has been made private, redacted, obscured,
+   or registered by a proxy.  "Private" means that the data is not
+   designated for public consumption.  "Redacted" means that some
+   registration data fields are not being made available.  "Obscured"
+   means that data has been altered for the purposes of not readily
+   revealing the actual registration information.  One option that
+   operators have available to them to reduce privacy risks to
+   registrants is to adopt policies that make use of these status values
+   to restrict the registrant data shared with any or all clients
+
+
+
+
+Hollenbeck & Kong            Standards Track                    [Page 8]
+
+RFC 7481                 RDAP Security Services               March 2015
+
+
+   according to the sensitivity of the data, the privileges of the
+   clients, or some other heuristics.
+
+   RDAP uses the jCard [RFC7095] standard format for entity
+   representation.  Operators may find that many of the jCard fields are
+   irrelevant for registry operation purposes or that they have no
+   reason to collect information from registrants that would correspond
+   to certain fields.  Operators wishing to reduce privacy risks for
+   registrants may restrict which information they collect and/or which
+   fields they populate in responses.
+
+   In addition to privacy risks to registrants, there are also potential
+   privacy risks for those who query registration data.  For example,
+   the fact that a registry employee performs a particular query may
+   reveal information about the employee's activities that he or she
+   would have preferred to keep private.  RDAP supports the use of HTTP
+   over TLS to provide privacy protection for those querying registrant
+   data as well as registrants, unless operational constraints make it
+   impossible to meet this requirement.
+
+5.  Security Considerations
+
+   One of the goals of RDAP is to provide security services that do not
+   exist in the WHOIS protocol.  This document describes the security
+   services provided by RDAP and associated protocol layers, including
+   authentication, authorization, availability, data confidentiality,
+   and data integrity.  Non-repudiation services were also considered
+   and ultimately rejected due to a lack of requirements.  There are,
+   however, currently deployed WHOIS servers that can return signed
+   responses that provide non-repudiation with proof of origin.  RDAP
+   might need to be extended to provide this service in the future.
+
+   As an HTTP-based protocol, RDAP is susceptible to code injection
+   attacks.  Code injection refers to adding code into a computer system
+   or program to alter the course of execution.  There are many types of
+   code injection, including SQL injection, dynamic variable or function
+   injection, include-file injection, shell injection, and HTML-script
+   injection, among others.  Data confidentiality and integrity services
+   provide a measure of defense against man-in-the-middle injection
+   attacks, but vulnerabilities in both client- and server-side software
+   make it possible for injection attacks to succeed.  Consistently
+   checking and validating server credentials can help detect
+   man-in-the-middle attacks.
+
+   As noted in Section 3.2.1, digital certificates can be used to
+   implement federated authentication.  There is a risk of too
+   promiscuous, or even rogue, CAs being included in the list of
+   acceptable CAs that the TLS server sends the client as part of the
+
+
+
+Hollenbeck & Kong            Standards Track                    [Page 9]
+
+RFC 7481                 RDAP Security Services               March 2015
+
+
+   TLS client-authentication handshake and lending the appearance of
+   trust to certificates signed by those CAs.  Periodic monitoring of
+   the list of CAs that RDAP servers trust for client authentication can
+   help reduce this risk.
+
+   The Transport Layer Security protocol [RFC5246] includes a null
+   cipher suite that does not encrypt data and thus does not provide
+   data confidentiality.  This option MUST NOT be used when data
+   confidentiality services are needed.  Additional considerations for
+   secure use of TLS are described in [SECURE-TLS-DTLS].
+
+   Data integrity services are sometimes mistakenly associated with
+   directory service operational policy requirements focused on data
+   accuracy.  "Accuracy" refers to the truthful association of data
+   elements (such as names, addresses, and telephone numbers) in the
+   context of a particular directory object (such as a domain name).
+   Accuracy requirements are out of scope for this protocol.
+
+   Additional security considerations are described in the
+   specifications for HTTP [RFC7231], HTTP Basic and Digest access
+   authentication [RFC7235], HTTP over TLS [RFC2818], and additional
+   HTTP status codes [RFC6585].  Security considerations for federated
+   authentication systems can be found in the OAuth [RFC6749] and OpenID
+   [OpenID] specifications.
+
+6.  References
+
+6.1.  Normative References
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119, March 1997,
+              <http://www.rfc-editor.org/info/rfc2119>.
+
+   [RFC2818]  Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000,
+              <http://www.rfc-editor.org/info/rfc2818>.
+
+   [RFC6585]  Nottingham, M. and R. Fielding, "Additional HTTP Status
+              Codes", RFC 6585, April 2012,
+              <http://www.rfc-editor.org/info/rfc6585>.
+
+   [RFC7231]  Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
+              Protocol (HTTP/1.1): Semantics and Content", RFC 7231,
+              June 2014, <http://www.rfc-editor.org/info/rfc7231>.
+
+   [RFC7235]  Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
+              Protocol (HTTP/1.1): Authentication", RFC 7235, June 2014,
+              <http://www.rfc-editor.org/info/rfc7235>.
+
+
+
+
+Hollenbeck & Kong            Standards Track                   [Page 10]
+
+RFC 7481                 RDAP Security Services               March 2015
+
+
+   [RFC7480]  Newton, A., Ellacott, B., and N. Kong, "HTTP Usage in the
+              Registration Data Access Protocol (RDAP)", RFC 7480, March
+              2015, <http://www.rfc-editor.org/info/rfc7480>.
+
+   [RFC7482]  Newton, A. and S. Hollenbeck, "Registration Data Access
+              Protocol (RDAP) Query Format", RFC 7482, March 2015,
+              <http://www.rfc-editor.org/info/rfc7482>.
+
+   [RFC7483]  Newton, A. and S. Hollenbeck, "JSON Responses for the
+              Registration Data Access Protocol (RDAP)", RFC 7483, March
+              2015, <http://www.rfc-editor.org/info/rfc7483>.
+
+6.2.  Informative References
+
+   [OpenID]   OpenID Foundation, "OpenID Authentication 2.0 - Final",
+              December 2007, <http://specs.openid.net/auth/2.0>.
+
+   [RFC3707]  Newton, A., "Cross Registry Internet Service Protocol
+              (CRISP) Requirements", RFC 3707, February 2004,
+              <http://www.rfc-editor.org/info/rfc3707>.
+
+   [RFC3912]  Daigle, L., "WHOIS Protocol Specification", RFC 3912,
+              September 2004, <http://www.rfc-editor.org/info/rfc3912>.
+
+   [RFC4732]  Handley, M., Ed., Rescorla, E., Ed., and IAB, "Internet
+              Denial-of-Service Considerations", RFC 4732, December
+              2006, <http://www.rfc-editor.org/info/rfc4732>.
+
+   [RFC4949]  Shirey, R., "Internet Security Glossary, Version 2", FYI
+              36, RFC 4949, August 2007,
+              <http://www.rfc-editor.org/info/rfc4949>.
+
+   [RFC5246]  Dierks, T. and E. Rescorla, "The Transport Layer Security
+              (TLS) Protocol Version 1.2", RFC 5246, August 2008,
+              <http://www.rfc-editor.org/info/rfc5246>.
+
+   [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,
+              <http://www.rfc-editor.org/info/rfc5280>.
+
+   [RFC6749]  Hardt, D., Ed., "The OAuth 2.0 Authorization Framework",
+              RFC 6749, October 2012,
+              <http://www.rfc-editor.org/info/rfc6749>.
+
+   [RFC7095]  Kewisch, P., "jCard: The JSON Format for vCard", RFC 7095,
+              January 2014, <http://www.rfc-editor.org/info/rfc7095>.
+
+
+
+Hollenbeck & Kong            Standards Track                   [Page 11]
+
+RFC 7481                 RDAP Security Services               March 2015
+
+
+   [SAML]     OASIS, "Security Assertion Markup Language (SAML) v2.0",
+              March 2005, <https://www.oasis-open.org/
+              standards#samlv2.0>.
+
+   [SECURE-TLS-DTLS]
+              Sheffer, Y., Holz, R., and P. Saint-Andre,
+              "Recommendations for Secure Use of TLS and DTLS", Work in
+              Progress, draft-ietf-uta-tls-bcp-09, February 2015.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hollenbeck & Kong            Standards Track                   [Page 12]
+
+RFC 7481                 RDAP Security Services               March 2015
+
+
+Acknowledgements
+
+   The authors would like to acknowledge the following individuals for
+   their contributions to this document: Richard Barnes, Marc Blanchet,
+   Alissa Cooper, Ernie Dainow, Spencer Dawkins, Jean-Philippe Dionne,
+   Byron Ellacott, Stephen Farrell, Tony Hansen, Peter Koch, Murray
+   Kucherawy, Barry Leiba, Andrew Newton, and Linlin Zhou.
+
+Authors' Addresses
+
+   Scott Hollenbeck
+   Verisign Labs
+   12061 Bluemont Way
+   Reston, VA  20190
+   United States
+
+   EMail: shollenbeck@verisign.com
+   URI:   http://www.verisignlabs.com/
+
+
+   Ning Kong
+   China Internet Network Information Center
+   4 South 4th Street, Zhongguancun, Haidian District
+   Beijing  100190
+   China
+
+   Phone: +86 10 5881 3147
+   EMail: nkong@cnnic.cn
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hollenbeck & Kong            Standards Track                   [Page 13]
+