One document matched: draft-petithuguenin-p2psip-reload-eku-00.xml

<?xml version="1.0" ?>
<?rfc compact="yes" ?>
<?rfc strict="no" ?>
<?rfc symrefs="yes" ?>
<?rfc toc="yes" ?>
<rfc category="std" docName="draft-petithuguenin-p2psip-reload-eku-00" ipr="noModificationTrust200902">
  <front>
    <title abbrev="RELOAD EKU">Using Extended Key Usage (EKU) for REsource LOcation And Discovery (RELOAD) X.509 Certificates</title>
    <author fullname="Marc Petit-Huguenin" initials="M.P.H" surname="Petit-Huguenin">
      <organization>Impedance Mismatch</organization>
      <address>
        <email>petithug@acm.org</email>
      </address>
    </author>
    <date day="12" month="October" year="2012"/>
    <area>RAI</area>
    <workgroup>P2PSIP</workgroup>
    <abstract>
      <t>This document describes an Extended Key Usage (EKU) X.509 certificate extension for restricting the usage of a certificate to a REsource LOcation And Discovery (RELOAD) overlay.</t>
    </abstract>
  </front>
  <middle>
    <section title="Introduction">
      <t>
        An enrollment server as defined by section 11.3 of
        <xref target="RELOAD"/>
        generates certificates that are used by a RELOAD implementation as client and server certificates for the purpose of establishing (D)TLS links, and to sign RELOAD messages and data.
				The enrollment server also manage the CA certificate used as Issuer for these certificates, but this CA cannot be used to sign any other kind of certificate, like an HTTPS certificate that can be used to manage the OAM API of the enrollment server, because there is no possibility to restrict a certificate to be used only in a RELOAD overlay.
      </t>
      <t>
        This document solves this problem by describing an Extended Key Usage (EKU) X.509 certificate extension for restricting the usage of a certificate to a
        <xref target="RELOAD">REsource LOcation And Discovery</xref>
        overlay.
      </t>
    </section>
    <section title="Terminology">
      <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
        <xref target="RFC2119"/>
        .
      </t>
      <t>"SHOULD", "SHOULD NOT", "RECOMMENDED", and "NOT RECOMMENDED" are appropriate when valid exceptions to a general requirement are known to exist or appear to exist, and it is infeasible or impractical to enumerate all of them.
				However, they should not be interpreted as permitting implementors to fail to implement the general requirement when such failure would result in interoperability failure.</t>
    </section>
    <section title="Extended Key Usage">
      <t>
        This document defines the
        <xref target="RFC5280">KeyPurposeId</xref>
        id-kp-reload.
				The presence of this KeyPurposeId in a certificate indicates that the usage of this certificate is restricted for use in a RELOAD overlay.
      </t>
      <t>
        <figure>
          <artwork><![CDATA[id-kp-reload OBJECT IDENTIFIER ::= { id-kp TBD }]]></artwork>
        </figure>
      </t>
    </section>
    <section title="Support in implementations">
      <t>To be compatible with RELOAD implementations that predates this extension, only the RELOAD overlays running with a configuration file that contains a mandatory-extension element containing the namespace registered by IANA MUST enforce this restriction.</t>
    </section>
    <section anchor="security" title="Security Considerations"/>
    <section title="IANA Considerations">
      <t>If this document is accepted as a standard track document the EKU used in this document will be registered in an arc delegated by IANA to the PKIX Working Group.</t>
      <t>Until an official OID is assigned, the following OID allocated in the PEN of the author can be used for experimental purpose:</t>
      <t>
        <figure>
          <artwork><![CDATA[1.3.6.1.4.1.40544.5.5.7.3.30]]></artwork>
        </figure>
      </t>
      <t>If this document is accepted as a standard track document this section will request an URN in the "XML Namespaces" class of the "IETF XML Registry" from IANA.
				Until this is done, implementations should use the following URN:</t>
      <t>
        <figure>
          <artwork><![CDATA[http://implementers.org/reload-eku]]></artwork>
        </figure>
      </t>
    </section>
    <!--section title="Acknowledgements">
		</section-->
  </middle>
  <back>
    <references title="Normative References">
      <reference anchor="RFC2119">
        <front>
          <title abbrev="RFC Key Words">Key words for use in RFCs to Indicate Requirement Levels</title>
          <author fullname="Scott Bradner" initials="S." surname="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>sob@harvard.edu</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"/>
        <format octets="4723" target="ftp://ftp.isi.edu/in-notes/rfc2119.txt" type="TXT"/>
        <format octets="17491" target="http://xml.resource.org/public/rfc/html/rfc2119.html" type="HTML"/>
        <format octets="5777" target="http://xml.resource.org/public/rfc/xml/rfc2119.xml" type="XML"/>
      </reference>
      <reference anchor="RFC5280">
        <front>
          <title>Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile</title>
          <author fullname="D. Cooper" initials="D." surname="Cooper">
            <organization/>
          </author>
          <author fullname="S. Santesson" initials="S." surname="Santesson">
            <organization/>
          </author>
          <author fullname="S. Farrell" initials="S." surname="Farrell">
            <organization/>
          </author>
          <author fullname="S. Boeyen" initials="S." surname="Boeyen">
            <organization/>
          </author>
          <author fullname="R. Housley" initials="R." surname="Housley">
            <organization/>
          </author>
          <author fullname="W. Polk" initials="W." surname="Polk">
            <organization/>
          </author>
          <date month="May" year="2008"/>
        </front>
        <seriesInfo name="RFC" value="5280"/>
        <format octets="352580" target="ftp://ftp.isi.edu/in-notes/rfc5280.txt" type="TXT"/>
      </reference>
      <reference anchor="RELOAD">
        <front>
          <title>REsource LOcation And Discovery (RELOAD) Base Protocol</title>
          <author fullname="Cullen Jennings" initials="C" surname="Jennings">
            <organization/>
          </author>
          <author fullname="Bruce Lowekamp" initials="B" surname="Lowekamp">
            <organization/>
          </author>
          <author fullname="Eric Rescorla" initials="E" surname="Rescorla">
            <organization/>
          </author>
          <author fullname="Salman Baset" initials="S" surname="Baset">
            <organization/>
          </author>
          <author fullname="Henning Schulzrinne" initials="H" surname="Schulzrinne">
            <organization/>
          </author>
          <date day="16" month="July" year="2012"/>
          <abstract>
            <t>This specification defines REsource LOcation And Discovery (RELOAD), a peer-to-peer (P2P) signaling protocol for use on the Internet.
					A P2P signaling protocol provides its clients with an abstract storage and messaging service between a set of cooperating peers that form the overlay network.
					RELOAD is designed to support a P2P Session Initiation Protocol (P2PSIP) network, but can be utilized by other applications with similar requirements by defining new usages that specify the kinds of data that must be stored for a particular application.
					RELOAD defines a security model based on a certificate enrollment service that provides unique identities.
					NAT traversal is a fundamental service of the protocol.
					RELOAD also allows access from "client" nodes that do not need to route traffic or store data for others.</t>
          </abstract>
        </front>
        <seriesInfo name="Internet-Draft" value="draft-ietf-p2psip-base-22"/>
        <format target="http://www.ietf.org/internet-drafts/draft-ietf-p2psip-base-22.txt" type="TXT"/>
      </reference>
    </references>
    <!--references title="Informative References">
		</references-->
    <!--section title="Release notes">
			<t>This section must be removed before publication as an RFC.</t>

			<section title="Design Notes">
				<t>
					<list style="symbols">
						<t>
						</t>
					</list>
				</t>
			</section>

			<section title="TODO List">
				<t>
					<list style="symbols">
						<t>
						</t>
					</list>
				</t>
			</section>
		</section-->
  </back>
</rfc>