Internet DRAFT - draft-petithuguenin-p2psip-reload-eku
draft-petithuguenin-p2psip-reload-eku
P2PSIP M. Petit-Huguenin
Internet-Draft Impedance Mismatch
Intended status: Standards Track April 29, 2013
Expires: October 31, 2013
Using Extended Key Usage (EKU) for REsource LOcation And Discovery
(RELOAD) X.509 Certificates
draft-petithuguenin-p2psip-reload-eku-01
Abstract
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.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on October 31, 2013.
Copyright Notice
Copyright (c) 2013 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.
Petit-Huguenin Expires October 31, 2013 [Page 1]
Internet-Draft RELOAD EKU April 2013
This document may not be modified, and derivative works of it may not
be created, except to format it for publication as an RFC or to
translate it into languages other than English.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2
3. Extended Key Usage . . . . . . . . . . . . . . . . . . . . . 3
4. Support in implementations . . . . . . . . . . . . . . . . . 3
5. Implementation Status . . . . . . . . . . . . . . . . . . . . 3
5.1. reloadd . . . . . . . . . . . . . . . . . . . . . . . . . 3
6. Security Considerations . . . . . . . . . . . . . . . . . . . 4
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 4
8.1. Normative References . . . . . . . . . . . . . . . . . . 4
8.2. Informative References . . . . . . . . . . . . . . . . . 5
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 5
1. Introduction
An enrollment server as defined by section 11.3 of [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.
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 REsource LOcation And Discovery [RELOAD] overlay.
2. Terminology
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].
"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.
Petit-Huguenin Expires October 31, 2013 [Page 2]
Internet-Draft RELOAD EKU April 2013
3. Extended Key Usage
This document defines the KeyPurposeId [RFC5280] 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.
id-kp-reload OBJECT IDENTIFIER ::= { id-kp TBD }
4. Support in implementations
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.
5. Implementation Status
Note to RFC Editor: Please remove this section before publication.
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
[RUNNING-CODE]. According to [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".
5.1. reloadd
Name: reloadd 0.6.1
Description: An implementation of the configuration and enrollment
servers as specified in [RELOAD]. The certificates generated
contains the extension described in this document.
Level of maturity: Experimental.
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.
Licensing: Proprietary. Free accounts available for
interoperability testing.
Petit-Huguenin Expires October 31, 2013 [Page 3]
Internet-Draft RELOAD EKU April 2013
Contact: Marc Petit-Huguenin <marc@petit-huguenin.org>.
6. Security Considerations
TBD
7. IANA Considerations
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.
Until an official OID is assigned, the following OID allocated in the
PEN of the author can be used for experimental purpose:
1.3.6.1.4.1.40544.5.5.7.3.30
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:
http://implementers.org/reload-eku
8. References
8.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[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.
[RELOAD] Jennings, C., Lowekamp, B., Rescorla, E., Baset, S., and
H. Schulzrinne, "REsource LOcation And Discovery (RELOAD)
Base Protocol", draft-ietf-p2psip-base-26 (work in
progress), February 2013.
Petit-Huguenin Expires October 31, 2013 [Page 4]
Internet-Draft RELOAD EKU April 2013
8.2. Informative References
[RUNNING-CODE]
Sheffer, Y. and A. Farrel, "Improving Awareness of Running
Code: the Implementation Status Section", draft-sheffer-
running-code-03 (work in progress), April 2013.
Author's Address
Marc Petit-Huguenin
Impedance Mismatch
Email: petithug@acm.org
Petit-Huguenin Expires October 31, 2013 [Page 5]
