One document matched: draft-petithuguenin-p2psip-reload-eku-01.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-01" 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." surname="Petit-Huguenin">
<organization>Impedance Mismatch</organization>
<address>
<email>petithug@acm.org</email>
</address>
</author>
<date day="29" month="April" year="2013"/>
<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 signing RELOAD messages and data.
The enrollment server also manages 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 could 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="impl-status" title="Implementation Status">
<t>Note to RFC Editor: Please remove this section before publication.</t>
<t>
This section records the status of known implementations of the protocol defined by this specification at the time of posting of this Internet-Draft, and is based on a proposal described in <xref target="RUNNING-CODE"/>.
According to <xref target="RUNNING-CODE"/>, "this will allow reviewers and working groups to assign due consideration to documents that have the benefit of running code, by considering the running code as evidence of valuable experimentation and feedback that has made the implemented protocols more mature.
It is up to the individual working groups to use this information as they see fit".
</t>
<section anchor="section.impl-status.implementers" title="reloadd">
<t>
<list style="hanging">
<t hangText="Name: ">reloadd 0.6.1</t>
<t hangText="Description: ">
An implementation of the configuration and enrollment servers as specified in <xref target="RELOAD"/>.
The certificates generated contains the extension described in this document.
</t>
<t hangText="Level of maturity: ">Experimental.</t>
<t hangText="Coverage: ">
Fully implements this specification.
The RESTful API used to manage the configuration and enrollment servers uses a client certificate signed with the same CA that is used to sign the RELOAD certificate, but without the EKU described in this document.
</t>
<t hangText="Licensing: ">
Proprietary.
Free accounts available for interoperability testing.
</t>
<t hangText="Contact: ">Marc Petit-Huguenin <marc@petit-huguenin.org>.</t>
</list>
</t>
</section>
</section>
<section anchor="security" title="Security Considerations">
<t>TBD</t>
</section>
<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="24" month="February" year="2013"/>
<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-26"/>
<format target="http://www.ietf.org/internet-drafts/draft-ietf-p2psip-base-26.txt" type="TXT"/>
</reference>
</references>
<references title="Informative References">
<reference anchor="RUNNING-CODE">
<front>
<title>Improving Awareness of Running Code: the Implementation Status Section</title>
<author fullname="Yaron Sheffer" initials="Y" surname="Sheffer">
<organization/>
</author>
<author fullname="Adrian Farrel" initials="A" surname="Farrel">
<organization/>
</author>
<date day="5" month="April" year="2013"/>
<abstract>
<t>
This document describes a simple process that allows authors of Internet-Drafts to record the status of known implementations by including an Implementation Status section.
This will allow reviewers and working groups to assign due consideration to documents that have the benefit of running code and potentially reward the documented protocols by treating the documents with implementations preferentially.
The process in this document is offered as an experiment.
Authors of Internet-Drafts are encouraged to consider using the process for their documents, and working groups are invited to think about applying the process to all of their protocol specifications.
The authors of this document intend to collate experiences with this experiment and to report them to the community.
</t>
</abstract>
</front>
<seriesInfo name="Internet-Draft" value="draft-sheffer-running-code-03"/>
<format target="http://www.ietf.org/internet-drafts/draft-sheffer-running-code-03.txt" type="TXT"/>
</reference>
</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>
| PAFTECH AB 2003-2026 | 2026-04-24 01:55:58 |