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 November 01, 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.

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. Terminology
• 3. Extended Key Usage
• 4. Support in implementations
• 5. Implementation Status
• 5.1. reloadd
• 6. Security Considerations
• 7. IANA Considerations
• 8. References
• 8.1. Normative References
• 8.2. Informative References
• Author's Address

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.

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.

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

8.2. Informative References

Author's Address