One document matched: draft-saintandre-xmpp-dna-00.xml
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc compact="yes"?>
<?rfc strict="yes"?>
<?rfc symrefs="yes"?>
<?rfc toc="yes"?>
<?rfc tocdepth="4"?>
<rfc category="std" docName="draft-saintandre-xmpp-dna-00" ipr="trust200902">
<front>
<title abbrev="XMPP DNA">Domain Name Associations (DNA) in the Extensible Messaging and Presence Protocol (XMPP)</title>
<author initials="P." surname="Saint-Andre" fullname="Peter Saint-Andre">
<organization>Cisco Systems, Inc.</organization>
<address>
<postal>
<street>1899 Wynkoop Street, Suite 600</street>
<city>Denver</city>
<region>CO</region>
<code>80202</code>
<country>USA</country>
</postal>
<email>psaintan@cisco.com</email>
</address>
</author>
<author initials="M." surname="Miller" fullname="Matthew Miller">
<organization>Cisco Systems, Inc.</organization>
<address>
<postal>
<street>1899 Wynkoop Street, Suite 600</street>
<city>Denver</city>
<region>CO</region>
<code>80202</code>
<country>USA</country>
</postal>
<email>mamille2@cisco.com</email>
</address>
</author>
<date month="June" day="27" year="2012"/>
<area>RAI</area>
<keyword>Internet-Draft</keyword>
<keyword>XMPP</keyword>
<keyword>Extensible Messaging and Presence Protocol</keyword>
<keyword>Jabber</keyword>
<keyword>federation</keyword>
<abstract>
<t>This document defines a framework for improving the security of the Extensible Messaging and Presence Protocol (XMPP) in two respects. First, it introduces the concept of a prooftype for establishing a strong association between a domain name and an XML stream. Second, it provides guidelines for securely delegating a source domain to a derived domain, which is especially important in virtual hosting environments.</t>
</abstract>
</front>
<middle>
<section title="Introduction" anchor="intro">
<t>This document defines a framework for improving the security of the Extensible Messaging and Presence Protocol (XMPP) in two respects. First, it introduces the concept of a prooftype for establishing a strong association between a domain name and an XML stream (i.e., a domain name association or "DNA"). Second, it provides guidelines for securely delegating a source domain to a derived domain, which is especially important in virtual hosting environments.</t>
<t>The need to establish a strong association between a domain name and an XML stream arises in both client-to-server and server-to-server communication using XMPP, because XMPP servers are typically identified by domain names. However, a client or peer server needs to verify the identity of a server to which it connects. To date, such verification has been established based on information obtained from the Domain Name System (DNS), the Public Key Infrastructure (PKI), or similar sources. This document generalizes the model currently in use so that additional prooftypes can be defined, and also provides a basis for modernizing some prooftypes (e.g., Server Dialback <xref target="XEP-0220"/>) to reflect progress in several underlying technologies, especially DNS Security <xref target="RFC4033"/>.</t>
<t>The process for resolving the domain name of an XMPP service into the IP address at which an XML stream will be negotiated (defined in <xref target='RFC6120'/>) can involve delegation of a source domain (say, im.example.com) to a derived domain (say, hosting.example.net). If such delegation is not done in a secure manner, then the domain name association cannot be authenticated. Therefore, this document also provides guidelines for defining secure delegation methods.</t>
<t>This document does not define any DNA prooftypes or secure delegation methods; such technologies are defined in companion documents.</t>
</section>
<section title="Terminology" anchor="terms">
<t>This document inherits XMPP-related terminology from <xref target="RFC6120"/> and <xref target="XEP-0220"/>, DNS-related terminology from <xref target="RFC1034"/>, <xref target="RFC1035"/>, <xref target="RFC2782"/> and <xref target="RFC4033"/>, and security-related terminology from <xref target="RFC4949"/> and <xref target="RFC5280"/>. The terms "source domain", "derived domain", "reference identity", and "presented identity" are used as defined in the "CertID" specification <xref target="RFC6125"/>. The terms "permissive federation", "verified federation", and "encrypted federation" are derived from <xref target="XEP-0238"/>, although we substitute the term "authenticated federation" for the term "trusted federation" from that document.</t>
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in <xref target="RFC2119"/>.</t>
</section>
<section title="Problem Statement" anchor="problem">
<t>In XMPP, each party to a stream expects the other party to provide some proof of its identity. For example, in client-to-server streams the server expects the client to present some credentials (such as a username and password or a client certificate), and ideally the client also expects the server to provide a certificate that identifies the domain(s) of the server. Similar considerations hold true for server-to-server streams, also called "interdomain federation".</t>
<t>When the Jabber.org open-source community developed the precursor to XMPP in 1999, it defined methods for interdomain federation but no mechanisms for authenticating or checking the identity of peer servers. We could describe this as "permissive federation", which is clearly sub-optimal given the strong potential for domain spoofing. In the year 2000, the community filled the gap to some extent by defining a technology called Server Dialback (first documented in <xref target="RFC3920"/> and since moved to <xref target="XEP-0220"/>). Although Server Dialback does not provide a strong mechanism for identity checking without the use of DNSSEC, it does provide DNS-based verification and thus has effectively prevented most instances of domain spoofing on the XMPP network since late 2000. Also, because Server Dialback typically does not involve the use of server certificates, it does not result in an encrypted stream; thus we refer to it as a technology for "verified federation".</t>
<t>In 2002-2004, the IETF's XMPP Working Group hardened the original Jabber.org protocols by adding Transport Layer Security (TLS) and Simple Authentication and Security Layer (SASL), thus making it possible for two servers to engage in "authenticated federation" (i.e., when two peer servers present PKIX certificates anchored to trusted roots during negotiation of a server-to-server stream) or "encrypted federation" (i.e., when two peer servers present PKIX certificates that are self-signed or not anchored to trusted roots during negotiation of a server-to-server stream).</t>
<t>Unfortunately, authenticated federation has not been widely deployed on the XMPP network (indeed, even encrypted federation is not widely deployed because verified federation is perceived as "good enough"); one of the primary reasons is that it is feasible (although not always easy) for single-domain servers to obtain the proper certificates, but much more difficult (or practically impossible) for large XMPP hosting providers to do so. The primary challenge here is operational: it is highly unlikely that an organization (say, example.com) wishing to delegate its XMPP service (say, im.example.com) to a hosting provider (say, hosting.example.net) will hand over its private key to the hosting provider. Even if that were feasible, further operational challenges (e.g., maintaining large numbers of certificates for hosted domains, and configuring XMPP software to present the correct certificate based on the 'to' address of the initial stream header) have also discouraged deployment of authenticated federation in virtual hosting environments, which happen to be a common deployment scenario.</t>
<t>Furthermore, the prevalence of delegation to hosting providers leads to one additional shortcoming, caused by the use of DNS SRV records <xref target="RFC2782"/> in XMPP: if DNSSEC is not used, the act of delegation is inherently insecure. Unfortunately, no existing documentation explains how to use DNSSEC for secure delegation, with the result that clients and servers often take a "leap of faith" if using an SRV record to determine that when communicating with, say, im.example.com they actually need to connect to, say, hosting.example.net.</t>
<t>In order to meet the requirements for strong security <xref target="RFC3365"/>, both authenticated federation and secure delegation are needed so that the association between a domain name and an XML stream can be trusted by XMPP entities. Unfortunately, authenticated federation is uncommon and secure delegation is unheard of on the XMPP network today. Because the current situation is clearly sub-optimal, this document defines a framework for both authenticated federation and secure delegation in XMPP.</t>
</section>
<section title="Framework" anchor="framework">
<t>In essence, we need to establish an association between a domain and an XML stream: is the XMPP server to which a client or peer server connects "allowed" to accept stanzas for or send stanzas from a given domain? If so, we say that there is a domain name association ("DNA") for the stream.</t>
<t>For TLS in general, the TLS client has some expectations about the identity of the TLS server (in the language of the "CertID" specification <xref target="RFC6125"/>, the TLS client has a "reference identity"), and then checks some material presented by the TLS server (the "presented identity" within the server certificate) to verify that its expectations have been met. In XMPP, Server Dialback follows a similar model, except that the verification material takes the form of a token instead of a certificate. The DNS-Based Authentication of Named Entities protocol <xref target="DANE"/>, at least in some of its modes, adds another kind of verification material: not the presented identity within a PKIX certificate, but a complete certificate or hash thereof. And other kinds of verification material could be envisioned (e.g., OpenPGP keys, Kerberos tickets, OAuth tokens), although they are not considered here.</t>
<t>No matter what kind of verification material is used, an XMPP client or peer server that wishes to verify a domain name association needs a way to obtain the verification material it will refer to when establishing the association. For instance, when a server presents a PKIX certificate during TLS negotiation, the connecting client or peer server has traditionally obtained its verification material out of band or via configuration from a certification authority (i.e., in the form of a root certificate contained in a certificate bundle). In the Server Dialback protocol, the verification material is a token that is obtained over XMPP itself. In DANE, the verification material is obtained from the Domain Name System. In the PKIX Over Secure HTTP ("POSH") method described in an accompanying specification, the verification material is obtained over secure HTTP. And other methods for obtaining verification material could be envisioned (e.g., IPsec), although they are not considered here.</t>
<t>Furthermore, the matching rules for checking the verification material will depend on the nature of that material; for example, <xref target="RFC6120"/> defines a profile of the rules from the "CertID" specification <xref target="RFC6125"/>, Server Dialback <xref target="XEP-0220"/> typically performs a character-for-character comparison of tokens, DANE might compare the SubjectPublicKeyInfo data or the full certificate, and so on.</t>
<t>Finally, given the relationship between XMPP and the DNS (XMPP services are usually identified by domain name, not IP address), it is important to make it clear whether a given verification method can (or must) be used only with secure DNS or also with insecure DNS.</t>
<t>Putting these pieces together, we define a "DNA prooftype" as follows.</t>
<t>
<list style="hanging">
<t hangText="prooftype:">A mechanism for proving an association between a domain name and an XML stream, where the mechanism defines (1) the verification material to be used, (2) the matching rules for comparing the reference version and presented version of the material, (3) how the verification material is obtained, and (4) whether the mechanism depends on secure DNS.</t>
</list>
</t>
<t>The following sections outline several prooftypes that are used, or could be used, in XMPP; detailed definitions are provided in separate specifications.</t>
<t>Note: So far, our definition of a prooftype does not include the exact protocol mechanism that is used to assert a domain name; this is explained further under <xref target="assertions"/>.</t>
</section>
<section title="Prooftypes" anchor="prooftypes">
<section title="PKI" anchor="prooftype-pki">
<t>The PKI prooftype is a DNA proof that follows the rules from <xref target="RFC6120"/>: that is, the verification materials consist of a PKIX certificate that is checked according to a profile of the matching rules from <xref target="RFC6125"/>, the client's verification materials are obtained out of band in the form of a trusted root, and secure DNS is not necessary.</t>
</section>
<section title="DANE" anchor="prooftype-dane">
<t>In the DANE prooftype, the verification materials consist of a PKIX certificate that is compared as an exact match or a hash of either the SubjectPublicKeyInfo or the full certificate, and the verification materials are obtained via secure DNS. See the accompanying <xref target="XMPP-DANE"/> spec for complete discussion and examples.</t>
</section>
<section title="POSH" anchor="prooftype-posh">
<t>POSH stands for PKIX Over Secure HTTP: the verification materials consist of a PKIX certificate, it is obtained by retrieving it over HTTPS at a well-known URI <xref target="RFC5785"/>, the certificate is checked according to the rules from <xref target="RFC6120"/> and <xref target="RFC6125"/>, and secure DNS is not necessary since the HTTPS retrieval mechanism relies on the chain of trust from the public key infrastructure. See the accompanying <xref target="XMPP-POSH"/> spec for complete discussion and examples.</t>
</section>
<section title="Dialback Keys" anchor="prooftype-dbkeys">
<t>The Dialback Keys prooftype formalizes the existing Server Dialback protocol: the verification materials consist of a token obtained over XMPP, the token is checked by the authoritative server for a given domain using implementation-specific methods such as character-by-character comparison, and secure DNS is needed in order to place significant trust in such tokens, although it is known that at the time of this writing many domains use Dialback Keys even in the absence of secure DNS.</t>
</section>
</section>
<section title="Assertion Mechanisms" anchor="assertions">
<t>An assertion is a server's statement that an XML stream is to be associated with the asserted domain.</t>
<section title="TLS" anchor="assertions-tls">
<t>During TLS negotiation, an XMPP server acting as a TLS server sends its certificate to the connecting client or peer server acting as a TLS client. This certificate is interpreted as an assertion of the server's identity.</t>
</section>
<section title="SASL" anchor="assertions-sasl">
<t>During SASL negotiation after TLS negotiation, an XMPP server acting as a TLS server can include an authorization identity; such an authzid is an assertion of the server's identity.</t>
</section>
<section title="<db:result>" anchor="assertions-dbresult">
<t>When two servers use the Server Dialback protocol <xref target="XEP-0220"/>, the originating server asserts its identity by sending a <db:result/> element to the receiving server, where the 'from' attribute specifies the domain name being asserted by the originating server.</t>
<t>Note: Although historically the <db:result/> element has contained a dialback key as XML character data, the <db:result/> element can also be used without dialback keys as a mere assertion; this usage is sometimes colloquially referred to as "dialback without dialback".</t>
</section>
<section title="A Note about Stream Attributes" anchor="assertions-attributes">
<t>XML streams include 'to' and 'from' attributes. However, these are not assertions of identity, and are merely early indications of the identity that a client or server will later assert during TLS negotiation, SASL negotiation, or Server Dialback negotiation.</t>
</section>
</section>
<section title="Delegation Methods" anchor="delegation">
<t>Although domain name associations are closely tied to delegation in some scenarios, delegation is irrelevant when the source domain is exactly the same as the hostname of the XMPP service, as is often the case with single-domain services. There are two methods for secure delegation: DNSSEC (see the <xref target="XMPP-DANE"/> spec) and HTTPS Redirect (see the <xref target="XMPP-POSH"/> spec).</t>
</section>
<section title="Security Considerations" anchor="security">
<t>This document supplements but does not supersede the security considerations provided in <xref target="RFC6120"/> and <xref target="RFC6125"/>.</t>
</section>
<section title="IANA Considerations" anchor="iana">
<t>This document has no actions for the IANA.</t>
</section>
</middle>
<back>
<references title="Normative References">
<reference anchor="DANE">
<front>
<title>The DNS-Based Authentication of Named Entities (DANE) Transport Layer Security (TLS) Protocol: TLSA</title>
<author initials="P" surname="Hoffman" fullname="Paul Hoffman">
<organization/>
</author>
<author initials="J" surname="Schlyter" fullname="Jakob Schlyter">
<organization/>
</author>
<date month="June" day="14" year="2012"/>
<abstract>
<t>Encrypted communication on the Internet often uses Transport Level Security (TLS), which depends on third parties to certify the keys used. This document improves on that situation by enabling the administrators of domain names to specify the keys used in that domain's TLS servers. This requires matching improvements in TLS client software, but no change in TLS server software.</t>
</abstract>
</front>
<seriesInfo name="Internet-Draft" value="draft-ietf-dane-protocol-23"/>
<format type="TXT" target="http://www.ietf.org/internet-drafts/draft-ietf-dane-protocol-23.txt"/>
</reference>
<reference anchor="XMPP-DANE">
<front>
<title>Using DNS Security Extensions (DNSSEC) and DNS-based Authentication of Named Entities (DANE) as a Prooftype for XMPP Domain Name Associations</title>
<author initials="M." surname="Miller" fullname="Matthew Miller">
<organization>Cisco</organization>
<address>
<email>mamille2@cisco.com</email>
</address>
</author>
<author initials="P." surname="Saint-Andre" fullname="Peter Saint-Andre">
<organization>Cisco</organization>
<address>
<email>psaintan@cisco.com</email>
</address>
</author>
<date month="June" year="2012"/>
</front>
<seriesInfo name="Internet-Draft" value="draft-miller-xmpp-dnssec-prooftype-02"/>
<format type="TXT" target="http://tools.ietf.org/html/draft-miller-xmpp-prooftype-dnsssec-prooftype-02.txt"/>
</reference>
<reference anchor="XMPP-POSH">
<front>
<title>Using PKIX over Secure HTTP (POSH) as a Prooftype for XMPP Domain Name Associations</title>
<author initials="M." surname="Miller" fullname="Matthew Miller">
<organization>Cisco</organization>
<address>
<email>mamille2@cisco.com</email>
</address>
</author>
<author initials="P." surname="Saint-Andre" fullname="Peter Saint-Andre">
<organization>Cisco</organization>
<address>
<email>psaintan@cisco.com</email>
</address>
</author>
<date month="June" year="2012"/>
</front>
<seriesInfo name="Internet-Draft" value="draft-miller-xmpp-posh-prooftype-00"/>
<format type="TXT" target="http://tools.ietf.org/html/draft-miller-xmpp-posh-prooftype-00.txt"/>
</reference>
<reference anchor="RFC1034">
<front>
<title abbrev="Domain Concepts and Facilities">Domain names - concepts and facilities</title>
<author initials="P." surname="Mockapetris" fullname="P. Mockapetris">
<organization>Information Sciences Institute (ISI)</organization>
</author>
<date year="1987" day="1" month="November"/>
</front>
<seriesInfo name="STD" value="13"/>
<seriesInfo name="RFC" value="1034"/>
<format type="TXT" octets="129180" target="http://www.rfc-editor.org/rfc/rfc1034.txt"/>
</reference>
<reference anchor="RFC1035">
<front>
<title abbrev="Domain Implementation and Specification">Domain names - implementation and specification</title>
<author initials="P." surname="Mockapetris" fullname="P. Mockapetris">
<organization>USC/ISI</organization>
<address>
<postal>
<street>4676 Admiralty Way</street>
<city>Marina del Rey</city>
<region>CA</region>
<code>90291</code>
<country>US</country>
</postal>
<phone>+1 213 822 1511</phone>
</address>
</author>
<date year="1987" day="1" month="November"/>
</front>
<seriesInfo name="STD" value="13"/>
<seriesInfo name="RFC" value="1035"/>
<format type="TXT" octets="125626" target="http://www.rfc-editor.org/rfc/rfc1035.txt"/>
</reference>
<reference anchor="RFC2119">
<front>
<title abbrev="RFC Key Words">Key words for use in RFCs to Indicate Requirement Levels</title>
<author initials="S." surname="Bradner" fullname="Scott Bradner">
<organization>Harvard University</organization>
<address>
<postal>
<street>1350 Mass. Ave.</street>
<street>Cambridge</street>
<street>MA 02138</street>
</postal>
<phone>- +1 617 495 3864</phone>
<email>-</email>
</address>
</author>
<date month="March" year="1997"/>
<area>General</area>
<keyword>keyword</keyword>
<abstract>
<t>In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. Authors who follow these guidelines should incorporate this phrase near the beginning of their document:
<list><t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119.</t></list>
</t>
<t>Note that the force of these words is modified by the requirement level of the document in which they are used.</t>
</abstract>
</front>
<seriesInfo name="BCP" value="14"/>
<seriesInfo name="RFC" value="2119"/>
</reference>
<reference anchor="RFC2782">
<front>
<title abbrev="DNS SRV RR">A DNS RR for specifying the location of services (DNS SRV)</title>
<author initials="A." surname="Gulbrandsen" fullname="Arnt Gulbrandsen">
<organization>Troll Tech</organization>
<address>
<postal>
<street>Waldemar Thranes gate 98B</street>
<city>Oslo</city>
<region/>
<code>N-0175</code>
<country>NO</country>
</postal>
<phone>+47 22 806390</phone>
<facsimile>+47 22 806380</facsimile>
<email>arnt@troll.no</email>
</address>
</author>
<author initials="P." surname="Vixie" fullname="Paul Vixie">
<organization>Internet Software Consortium</organization>
<address>
<postal>
<street>950 Charter Street</street>
<city>Redwood City</city>
<region>CA</region>
<code>94063</code>
<country>US</country>
</postal>
<phone>+1 650 779 7001</phone>
</address>
</author>
<author initials="L." surname="Esibov" fullname="Levon Esibov">
<organization>Microsoft Corporation</organization>
<address>
<postal>
<street>One Microsoft Way</street>
<city>Redmond</city>
<region>WA</region>
<code>98052</code>
<country>US</country>
</postal>
<email>levone@microsoft.com</email>
</address>
</author>
<date year="2000" month="February"/>
<abstract>
<t>This document describes a DNS RR which specifies the location of the
server(s) for a specific protocol and domain.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="2782"/>
<format type="TXT" octets="24013" target="http://www.rfc-editor.org/rfc/rfc2782.txt"/>
</reference>
<reference anchor="RFC3365">
<front>
<title>Strong Security Requirements for Internet Engineering Task Force Standard Protocols</title>
<author initials="J." surname="Schiller" fullname="J. Schiller">
<organization/>
</author>
<date year="2002" month="August"/>
</front>
<seriesInfo name="BCP" value="61"/>
<seriesInfo name="RFC" value="3365"/>
<format type="TXT" octets="16411" target="http://www.rfc-editor.org/rfc/rfc3365.txt"/>
</reference>
<reference anchor="RFC4033">
<front>
<title>DNS Security Introduction and Requirements</title>
<author initials="R." surname="Arends" fullname="Roy Arends">
<organization>Telematica Instituut</organization>
<address>
<email>roy.arends@telin.nl</email>
</address>
</author>
<author initials="R." surname="Austein" fullname="Rob Austein">
<organization>Internet Systems Consortium</organization>
<address>
<email>sra@isc.org</email>
</address>
</author>
<author initials="M." surname="Larson" fullname="Matt Larson">
<organization>VeriSign, Inc.</organization>
<address>
<email>mlarson@verisign.com</email>
</address>
</author>
<author initials="D." surname="Massey" fullname="Dan Massey">
<organization>Colorado State University</organization>
<address>
<email>massey@cs.colostate.edu</email>
</address>
</author>
<author initials="S." surname="Rose" fullname="Scott Rose">
<organization>National Institute for Standards and Technology</organization>
<address>
<email>scott.rose@nist.gov</email>
</address>
</author>
<date month="May" year="2005"/>
</front>
<seriesInfo name="RFC" value="4033"/>
<format type="TXT" target="http://tools.ietf.org/rfc/rfc4033.txt"/>
</reference>
<reference anchor="RFC4949">
<front>
<title>Internet Security Glossary, Version 2</title>
<author initials="R." surname="Shirey" fullname="R. Shirey">
<organization/>
</author>
<date year="2007" month="August"/>
<abstract>
<t>This Glossary provides definitions, abbreviations, and explanations of terminology for information system security. The 334 pages of entries offer recommendations to improve the comprehensibility of written material that is generated in the Internet Standards Process (RFC 2026). The recommendations follow the principles that such writing should (a) use the same term or definition whenever the same concept is mentioned; (b) use terms in their plainest, dictionary sense; (c) use terms that are already well-established in open publications; and (d) avoid terms that either favor a particular vendor or favor a particular technology or mechanism over other, competing techniques that already exist or could be developed. This memo provides information for the Internet community.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="4949"/>
<format type="TXT" octets="867626" target="ftp://ftp.isi.edu/in-notes/rfc4949.txt"/>
</reference>
<reference anchor="RFC5280">
<front>
<title>Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile</title>
<author initials="D." surname="Cooper" fullname="D. Cooper">
<organization/>
</author>
<author initials="S." surname="Santesson" fullname="S. Santesson">
<organization/>
</author>
<author initials="S." surname="Farrell" fullname="S. Farrell">
<organization/>
</author>
<author initials="S." surname="Boeyen" fullname="S. Boeyen">
<organization/>
</author>
<author initials="R." surname="Housley" fullname="R. Housley">
<organization/>
</author>
<author initials="W." surname="Polk" fullname="W. Polk">
<organization/>
</author>
<date year="2008" month="May"/>
<abstract>
<t>This memo profiles the X.509 v3 certificate and X.509 v2 certificate revocation list (CRL) for use in the Internet. An overview of this approach and model is provided as an introduction. The X.509 v3 certificate format is described in detail, with additional information regarding the format and semantics of Internet name forms. Standard certificate extensions are described and two Internet-specific extensions are defined. A set of required certificate extensions is specified. The X.509 v2 CRL format is described in detail along with standard and Internet-specific extensions. An algorithm for X.509 certification path validation is described. An ASN.1 module and examples are provided in the appendices. [STANDARDS TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="5280"/>
<format type="TXT" octets="352580" target="ftp://ftp.isi.edu/in-notes/rfc5280.txt"/>
</reference>
<reference anchor="RFC5785">
<front>
<title>Defining Well-Known Uniform Resource Identifiers (URIs)</title>
<author initials="M." surname="Nottingham" fullname="M. Nottingham">
<organization/>
</author>
<author initials="E." surname="Hammer-Lahav" fullname="E. Hammer-Lahav">
<organization/>
</author>
<date year="2010" month="April"/>
<abstract>
<t>This memo defines a path prefix for "well-known locations", "/.well-known/", in selected Uniform Resource Identifier (URI) schemes. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="5785"/>
<format type="TXT" octets="13779" target="http://www.rfc-editor.org/rfc/rfc5785.txt"/>
</reference>
<reference anchor="RFC6120">
<front>
<title>Extensible Messaging and Presence Protocol (XMPP): Core</title>
<author initials="P." surname="Saint-Andre" fullname="Peter Saint-Andre">
<organization>Cisco</organization>
<address>
<email>psaintan@cisco.com</email>
</address>
</author>
<date month="March" year="2011"/>
</front>
<seriesInfo name="RFC" value="6120"/>
<format type="TXT" target="http://tools.ietf.org/rfc/rfc6120.txt"/>
</reference>
<reference anchor="RFC6125">
<front>
<title>Representation and Verification of Domain-Based Application Service Identity within Internet Public Key Infrastructure Using X.509 (PKIX) Certificates in the Context of Transport Layer Security (TLS)</title>
<author initials="P." surname="Saint-Andre" fullname="Peter Saint-Andre">
<organization>Cisco</organization>
<address>
<email>psaintan@cisco.com</email>
</address>
</author>
<author initials="J." surname="Hodges" fullname="Jeff Hodges">
<organization>PayPal</organization>
<address>
<email>jeff.hodges@paypal.com</email>
</address>
</author>
<date month="March" year="2011"/>
</front>
<seriesInfo name="RFC" value="6125"/>
<format type="TXT" target="http://tools.ietf.org/rfc/rfc6125.txt"/>
</reference>
<reference anchor="XEP-0220">
<front>
<title>Server Dialback</title>
<author initials="J" surname="Miller" fullname="Jeremie Miller">
<address>
<email>jer@jabber.org</email>
</address>
</author>
<author initials="P" surname="Saint-Andre" fullname="Peter Saint-Andre">
<organization>Cisco</organization>
<address>
<email>psaintan@cisco.com</email>
</address>
</author>
<author initials="P" surname="Hancke" fullname="Philipp Hancke">
<address>
<email>fippo@goodadvice.pages.de</email>
</address>
</author>
<date month="August" year="2011"/>
</front>
<seriesInfo name="XSF XEP" value="0220"/>
<format type="HTML" target="http://xmpp.org/extensions/xep-0220.html#appendix-authorinfo"/>
</reference>
</references>
<references title="Informative References">
<reference anchor="RFC3920">
<front>
<title abbrev="XMPP Core">Extensible Messaging and Presence Protocol (XMPP): Core</title>
<author initials="P." surname="Saint-Andre" fullname="Peter Saint-Andre" role="editor">
<organization>Jabber Software Foundation</organization>
<address>
<email>stpeter@jabber.org</email>
</address>
</author>
<date year="2004" month="October"/>
<area>Applications</area>
<workgroup>XMPP Working Group</workgroup>
<keyword>RFC</keyword>
<keyword>Request for Comments</keyword>
<keyword>I-D</keyword>
<keyword>Internet-Draft</keyword>
<keyword>XMPP</keyword>
<keyword>Extensible Messaging and Presence Protocol</keyword>
<keyword>Jabber</keyword>
<keyword>IM</keyword>
<keyword>Instant Messaging</keyword>
<keyword>Presence</keyword>
<keyword>XML</keyword>
<keyword>Extensible Markup Language</keyword>
<abstract>
<t>This memo defines the core features of the Extensible Messaging and Presence Protocol (XMPP), a protocol for streaming Extensible Markup Language (XML) elements in order to exchange structured information in close to real time between any two network endpoints. While XMPP provides a generalized, extensible framework for exchanging XML data, it is used mainly for the purpose of building instant messaging and presence applications that meet the requirements of RFC 2779.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="3920"/>
<format type="TXT" octets="194313" target="http://www.rfc-editor.org/rfc/rfc3920.txt"/>
<format type="HTML" octets="279912" target="http://xml.resource.org/public/rfc/html/rfc3920.html"/>
<format type="XML" octets="234610" target="http://xml.resource.org/public/rfc/xml/rfc3920.xml"/>
</reference>
<reference anchor="XEP-0238">
<front>
<title>XMPP Protocol Flows for Inter-Domain Federation</title>
<author initials="P." surname="Saint-Andre" fullname="Peter Saint-Andre">
<organization/>
<address>
<email>stpeter@jabber.org</email>
</address>
</author>
<date day="31" month="March" year="2008"/>
</front>
<seriesInfo name="XSF XEP" value="0238"/>
<format type="HTML" target="http://xmpp.org/extensions/xep-0238.html"/>
</reference>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 02:41:13 |