One document matched: draft-miller-xmpp-posh-prooftype-01.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-miller-xmpp-posh-prooftype-01" ipr="trust200902">
<front>
<title abbrev="XMPP POSH Prooftype">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 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>
<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>
<date month="July" day="13" 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 prooftype involving PKIX over Secure HTTP (POSH) for associating a domain name with an XML stream in the Extensible Messaging and Presence Protocol (XMPP). It also defines a method involving HTTPS redirects (appropriate for use with the POSH prooftype) for securely delegating a source domain to a derived domain in XMPP.</t>
</abstract>
</front>
<middle>
<section title="Introduction" anchor="intro">
<t>The <xref target="XMPP-DNA"/> specification defines a framework for secure delegation and authenticated domain name associations (DNA) in the Extensible Messaging and Presence Protocol (XMPP). This document defines a prooftype for DNA, using PKIX certificates obtained over secure HTTP ("POSH"), as well as a secure delegation method, based on HTTPS redirects, that is appropriate for use with the POSH prooftype.</t>
<t>The rationale for POSH is driven by current operational realities. It is effectively impossible for a hosting service to provide and maintain PKIX certificates <xref target="RFC5280"/> that include the appropriate <xref target="RFC6125"/> identifiers for each hosted domain. It is true that DNS-based technologies are emerging for secure delegation, in the form of DNS Security <xref target="RFC4033"/> and <xref target="DANE"/>); however, these technologies are not yet widely deployed and might not be deployed in the near future for domains outside the most common top-level domains (e.g., ".COM", ".NET", ".EDU"). Because the XMPP community wishes to deploy secure delegation and authenticated domain name associations as widely and as quickly as possible, this document specifies how to use secure HTTP <xref target="RFC2616"/> and PKIX certificates <xref target="RFC5280"/> to verify that a domain is delegated to a hosting provider and authenticate an assocation between a domain name and an XML stream.</t>
</section>
<section title="Terminology" anchor="terms">
<t>This document inherits XMPP-related terminology from <xref target="RFC6120"/> and security-related terminology from <xref target="RFC5280"/>. The terms "source domain", "derived domain", "reference identifier", and "presented identifier" are used as defined in the "CertID" specification <xref target="RFC6125"/>.</t>
<t>This document is applicable to connections made from an XMPP client to an XMPP server ("_xmpp-client._tcp") or between XMPP servers ("_xmpp-server._tcp"). In both cases, the XMPP initiating entity acts as a TLS client and the XMPP receiving entity acts as a TLS server. Therefore, to simplify discussion this document uses "_xmpp-client._tcp" to describe both cases, unless otherwise indicated.</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="Prooftype" anchor="prooftype">
<t>POSH stands for PKIX Over Secure HTTP: the verification materials consist of a PKIX certificate <xref target="RFC5280"/>, they are obtained by retrieving the certificate over HTTPS <xref target="RFC2818"/> from 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 based on the public key infrastructure.</t>
<t>The process for retrieving a PKIX certificate over secure HTTP is as follows.</t>
<t>
<list style="numbers">
<t>The initiating entity performs an HTTPS GET at the source domain to the path "/.well-known/posh._<service>._tcp.cer"; where "_<service>" MUST be either "_xmpp-client" for XMPP client-to-server connections or "_xmpp-server" for XMPP server-to-server connections:
<figure><artwork><![CDATA[
HTTP GET /.well-known/posh._xmpp-server._tcp.cer HTTP/1.1
Host: im.example.com
]]></artwork></figure>
<vspace blankLines="1"/></t>
<t>If the source domain HTTPS server has a certificate for the requested path, it MUST respond with a success status code, with the message body as the DER certificate (optionally encoded as base64 <xref target="RFC4684"/>) that the XMPP server at the source domain will present during the TLS negotiation phase of XMPP stream setup:
<figure><artwork><![CDATA[
HTTP/1.1 200 OK
Content-Type: application/pkix-cert
Content-Length: 839
-----BEGIN CERTIFICATE-----
MIICPTCCAaYCCQDDVeBaBmWC/jANBgkqhkiG9w0BAQUFADBjMQswCQYDVQQGEwJV
UzERMA8GA1UECBMIQ29sb3JhZG8xDzANBgNVBAcTBkRlbnZlcjEXMBUGA1UEChMO
aW0uZXhhbXBsZS5jb20xFzAVBgNVBAMTDmltLmV4YW1wbGUuY29tMB4XDTEyMDYx
MTIxNTQ0NFoXDTIyMDYwOTIxNTQ0NFowYzELMAkGA1UEBhMCVVMxETAPBgNVBAgT
CENvbG9yYWRvMQ8wDQYDVQQHEwZEZW52ZXIxFzAVBgNVBAoTDmltLmV4YW1wbGUu
Y29tMRcwFQYDVQQDEw5pbS5leGFtcGxlLmNvbTCBnzANBgkqhkiG9w0BAQEFAAOB
jQAwgYkCgYEA4hoKhi/B07eQH+1NB9gWiNFDT//AbTHQOEC0AOr4Gh/o9PUp7kD0
gklU4uv7rSAhAyCe4WaOiQ/HShzEryGfHiZmWht0BaYmj19iuPWRecZOXWqKZji9
NtAxn9l3kdon/YLJcrPGyNTGK66+ggNaqy8LkQQpI4rff60yHHZ/0XkCAwEAATAN
BgkqhkiG9w0BAQUFAAOBgQDcwiu30bSMlykWYz+tTDSlQ3wLSVB9RsR8jXmJvMo7
y7icXwg54a9M3xipjZtrfAhYM5I5iqUTQPki6s26n9SQpRm5bonEFDA3WGwrwma3
5biP9+NSBWzSaDF8AztwFNKXXl6/U6hWwG05G/NdeS11gpww9NUDraJgVoDpRK04
tg==
-----END CERTIFICATE-----
]]></artwork></figure>
<vspace blankLines="1"/></t>
</list>
</t>
</section>
<section title="Secure Delegation" anchor="delegation">
<t>When PKIX Over Secure HTTP (POSH) is the DNA prooftype, it is possible to use HTTPS redirects in determining if a domain is securely delegated, as follows:</t>
<t>
<list style="numbers">
<t>The initiating entity performs an HTTPS GET at the source domain to the path "/.well-known/posh._<service>._tcp.cer"; where "_<service>" MUST be either "_xmpp-client" for XMPP client-to-server connections or "_xmpp-server" for XMPP server-to-server connections. Here is an example:
<figure><artwork><![CDATA[
GET /.well-known/posh._xmpp-server._tcp.cer HTTP/1.1
Host: im.example.com
]]></artwork></figure>
<vspace blankLines="1"/></t>
<t>If the source domain HTTPS server has delegated to a derived domain, it MUST respond with one of the redirect mechanisms provided by HTTP (e.g., using the 302, 303, or 307 response). The 'Location' header MUST specify an HTTPS URL, where the hostname and port is the derived domain HTTPS server, and the path MUST match the pattern "_<service>._tcp.cer"; where "_<service>" MUST be identical to the "_<service>" portion of the original request (line breaks added for readability):
<figure><artwork><![CDATA[
HTTP/1.1 302 Found
Location: https://hosting.example.net/.well-known
/posh._xmpp-server._tcp.cer
]]></artwork></figure>
<vspace blankLines="1"/></t>
<t>The initiating entity performs an HTTPS GET to the URL specified in the 'Location' header:
<figure><artwork><![CDATA[
GET /.well-known/posh._xmpp-server._tcp.cer HTTP/1.1
Host: hosting.example.net
]]></artwork></figure>
<vspace blankLines="1"/></t>
<t>If the derived domain HTTPS server has a certificate, it MUST respond with a success status code, with the message body as the DER certificate (optionally encoded as base64 <xref target="RFC4684"/>) that the XMPP server at the derived domain will present during the TLS negotiation phase of XMPP stream setup:
<figure><artwork><![CDATA[
HTTP/1.1 200 OK
Content-Type: application/pkix-cert
Content-Length: 863
-----BEGIN CERTIFICATE-----
MIICUTCCAboCCQCtNQRNu3194zANBgkqhkiG9w0BAQUFADBtMQswCQYDVQQGEwJV
UzERMA8GA1UECBMIQ29sb3JhZG8xDzANBgNVBAcTBkRlbnZlcjEcMBoGA1UEChMT
aG9zdGluZy5leGFtcGxlLm5ldDEcMBoGA1UEAxMTaG9zdGluZy5leGFtcGxlLm5l
dDAeFw0xMjA2MTEyMTQ1MjZaFw0yMjA2MDkyMTQ1MjZaMG0xCzAJBgNVBAYTAlVT
MREwDwYDVQQIEwhDb2xvcmFkbzEPMA0GA1UEBxMGRGVudmVyMRwwGgYDVQQKExNo
b3N0aW5nLmV4YW1wbGUubmV0MRwwGgYDVQQDExNob3N0aW5nLmV4YW1wbGUubmV0
MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDi46kMWnCfg0DTrlcTc6AQUci5
Lu1f2RKRWPEhz8qyt/CO0N5VpxKQMlGp6TApQzFdAfxCUA3rniYFpMq4Hemw2S74
v1LRoWvROKviKRzunDP3EhPXf6GbgnHRlfBx4yvZtcR1BMnkxgJtbTAJu4/wTRXY
RE5FKk3xT4IBXTIQFwIDAQABMA0GCSqGSIb3DQEBBQUAA4GBAAvRohCXSfSnHXjv
84beqmFSYKcZvhVymgxQfhB2ZLNFQvfTO3Qsp/MR0hRRXrJ25n86t49EEXicjC0r
EdmWaIhdDFhw7hva2byYziww7fJuelD0tpL9nfF5uOIMp3JYyXCBn/FKJhi9HMR1
d8avm8gJ5Iu7L96qosWzL3epHYW7
-----END CERTIFICATE-----
]]></artwork></figure>
<vspace blankLines="1"/></t>
</list>
</t>
</section>
<section title="Caching Results" anchor="caching">
<t>Ideally, the initiating entity relies on the expiration time of the certificate obtained via POSH, and not on HTTP caching mechanisms. To that end, the HTTPS servers for source and derived domains SHOULD specify a 'Cache-Control' header indicating a short duration (e.g., max-age=60) or "no-cache" to indicate the response (redirect or content) is not appropriate to cache at the HTTP level.</t>
</section>
<section title="Examples" anchor="examples">
<t>Detailed examples will be provided in a future version of this specification.</t>
</section>
<section title="Security Considerations" anchor="security">
<t>This document supplements but does not supersede the security considerations provided in <xref target="RFC2616"/>, <xref target="RFC2818"/>, <xref target="RFC6120"/>, and <xref target="RFC6125"/>.</t>
<t>Specifically, communication via HTTPS depends on checking the identity of the HTTP server in accordance with <xref target="RFC2818"/>.</t>
</section>
<section title="IANA Considerations" anchor="iana">
<section title="The "posh._xmpp-client._tcp.cer" Well-Known URI" anchor="iana-posh-client">
<t>This specification registers the "posh._xmpp-client._tcp.cer" well-known URI in the Well-Known URI Registry as defined by <xref target="RFC5785"/>.</t>
<t>URI suffix: posh._xmpp-client._tcp.cer</t>
<t>Change controller: IETF</t>
<t>Specification document(s): RFC&rfc.number;.</t>
</section>
<section title="The "posh._xmpp-server._tcp.cer" Well-Known URI" anchor="iana-posh-server">
<t>This specification registers the "posh._xmpp-server._tcp.cer" well-known URI in the Well-Known URI Registry as defined by <xref target="RFC5785"/>.</t>
<t>URI suffix: posh._xmpp-server._tcp.cer</t>
<t>Change controller: IETF</t>
<t>Specification document(s): RFC&rfc.number;.</t>
</section>
</section>
</middle>
<back>
<references title="Normative References">
<reference anchor="XMPP-DNA">
<front>
<title>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</organization>
<address>
<email>psaintan@cisco.com</email>
</address>
</author>
<author initials="M." surname="Miller" fullname="Matthew Miller">
<organization>Cisco</organization>
<address>
<email>mamille2@cisco.com</email>
</address>
</author>
<date month="June" year="2012"/>
</front>
<seriesInfo name="Internet-Draft" value="draft-saintandre-xmpp-dna-00"/>
<format type="TXT" target="http://tools.ietf.org/html/draft-sainandre-xmpp-dna-00.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="RFC2616">
<front>
<title abbrev="HTTP/1.1">Hypertext Transfer Protocol -- HTTP/1.1</title>
<author initials="R." surname="Fielding" fullname="Roy T. Fielding">
<organization abbrev="UC Irvine">Department of Information and Computer Science</organization>
<address>
<postal>
<street>University of California, Irvine</street>
<city>Irvine</city>
<region>CA</region>
<code>92697-3425</code>
</postal>
<facsimile>+1(949)824-1715</facsimile>
<email>fielding@ics.uci.edu</email>
</address>
</author>
<author initials="J." surname="Gettys" fullname="James Gettys">
<organization abbrev="Compaq/W3C">World Wide Web Consortium</organization>
<address>
<postal>
<street>MIT Laboratory for Computer Science, NE43-356</street>
<street>545 Technology Square</street>
<city>Cambridge</city>
<region>MA</region>
<code>02139</code>
</postal>
<facsimile>+1(617)258-8682</facsimile>
<email>jg@w3.org</email>
</address>
</author>
<author initials="J." surname="Mogul" fullname="Jeffrey C. Mogul">
<organization abbrev="Compaq">Compaq Computer Corporation</organization>
<address>
<postal>
<street>Western Research Laboratory</street>
<street>250 University Avenue</street>
<city>Palo Alto</city>
<region>CA</region>
<code>94305</code>
</postal>
<email>mogul@wrl.dec.com</email>
</address>
</author>
<author initials="H." surname="Frystyk" fullname="Henrik Frystyk Nielsen">
<organization abbrev="W3C/MIT">World Wide Web Consortium</organization>
<address>
<postal>
<street>MIT Laboratory for Computer Science, NE43-356</street>
<street>545 Technology Square</street>
<city>Cambridge</city>
<region>MA</region>
<code>02139</code>
</postal>
<facsimile>+1(617)258-8682</facsimile>
<email>frystyk@w3.org</email>
</address>
</author>
<author initials="L." surname="Masinter" fullname="Larry Masinter">
<organization abbrev="Xerox">Xerox Corporation</organization>
<address>
<postal>
<street>MIT Laboratory for Computer Science, NE43-356</street>
<street>3333 Coyote Hill Road</street>
<city>Palo Alto</city>
<region>CA</region>
<code>94034</code>
</postal>
<email>masinter@parc.xerox.com</email>
</address>
</author>
<author initials="P." surname="Leach" fullname="Paul J. Leach">
<organization abbrev="Microsoft">Microsoft Corporation</organization>
<address>
<postal>
<street>1 Microsoft Way</street>
<city>Redmond</city>
<region>WA</region>
<code>98052</code>
</postal>
<email>paulle@microsoft.com</email>
</address>
</author>
<author initials="T." surname="Berners-Lee" fullname="Tim Berners-Lee">
<organization abbrev="W3C/MIT">World Wide Web Consortium</organization>
<address>
<postal>
<street>MIT Laboratory for Computer Science, NE43-356</street>
<street>545 Technology Square</street>
<city>Cambridge</city>
<region>MA</region>
<code>02139</code>
</postal>
<facsimile>+1(617)258-8682</facsimile>
<email>timbl@w3.org</email>
</address>
</author>
<date year="1999" month="June"/>
<abstract>
<t>
The Hypertext Transfer Protocol (HTTP) is an application-level
protocol for distributed, collaborative, hypermedia information
systems. It is a generic, stateless, protocol which can be used for
many tasks beyond its use for hypertext, such as name servers and
distributed object management systems, through extension of its
request methods, error codes and headers . A feature of HTTP is
the typing and negotiation of data representation, allowing systems
to be built independently of the data being transferred.
</t>
<t>
HTTP has been in use by the World-Wide Web global information
initiative since 1990. This specification defines the protocol
referred to as "HTTP/1.1", and is an update to RFC 2068 .
</t>
</abstract>
</front>
<seriesInfo name="RFC" value="2616"/>
<format type="TXT" octets="422317" target="http://www.rfc-editor.org/rfc/rfc2616.txt"/>
<format type="PS" octets="5529857" target="http://www.rfc-editor.org/rfc/rfc2616.ps"/>
<format type="PDF" octets="550558" target="http://www.rfc-editor.org/rfc/rfc2616.pdf"/>
<format type="HTML" octets="636125" target="http://xml.resource.org/public/rfc/html/rfc2616.html"/>
<format type="XML" octets="493420" target="http://xml.resource.org/public/rfc/xml/rfc2616.xml"/>
</reference>
<reference anchor="RFC2818">
<front>
<title>HTTP Over TLS</title>
<author initials="E." surname="Rescorla" fullname="E. Rescorla">
<organization/>
</author>
<date year="2000" month="May"/>
<abstract>
<t>This memo describes how to use Transport Layer Security (TLS) to secure Hypertext Transfer Protocol (HTTP) connections over the Internet. This memo provides information for the Internet community.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="2818"/>
<format type="TXT" octets="15170" target="http://www.rfc-editor.org/rfc/rfc2818.txt"/>
</reference>
<reference anchor="RFC4684">
<front>
<title>The Base16, Base32, and Base64 Data Encodings</title>
<author initials="S." surname="Josefsson" fullname="S. Josefsson">
<organization/>
</author>
<date year="2006" month="October"/>
<abstract>
<t>This document describes the commonly used base 64, base 32, and base 16 encoding schemes. It also discusses the use of line-feeds in encoded data, use of padding in encoded data, use of non-alphabet characters in encoded data, use of different encoding alphabets, and canonical encodings. [STANDARDS TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="4648"/>
<format type="TXT" octets="35491" target="ftp://ftp.isi.edu/in-notes/rfc4648.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>
</references>
<references title="Informative 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>VPN Consortium</organization>
<address>
<email>paul.hoffman@vpnc.org</email>
</address>
</author>
<author initials="J." surname="Schlyter" fullname="Jakob Schlyter">
<organization>Kirei AB</organization>
<address>
<email>jakob@kirei.se</email>
</address>
</author>
<date month="June" year="2012"/>
</front>
<seriesInfo name="Internet-Draft" value="draft-ietf-dane-protocol-23"/>
<format type="TXT" target="http://tools.ietf.org/html/draft-ietf-dane-protocol-23.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>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 03:13:10 |