INTERNET-DRAFT Adam W. Montville Intended Status: Standards Track (CIS) Expires: January 31, 2014 David Black (EMC) July 30, 2013 IODEF Enumeration Reference Format draft-ietf-mile-enum-reference-format-01 Abstract The Incident Object Description Exchange Format [IODEF] provides a Reference class used to reference external entities (such as enumeration identifiers). However, the method of external entity identification has been left unstructured. This document describes a method to provide structure for referencing external entities for the [IODEF] Reference class. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. 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." The list of current Internet-Drafts can be accessed at http://www.ietf.org/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html Copyright and License Notice Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved. Adam W. Montville Expires January 16, 2014 [Page 1] INTERNET DRAFT IODEF Enumeration Reference Format July 15, 2013 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. Table of Contents 1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Referencing External Enumerations . . . . . . . . . . . . . . 3 3 Security Considerations . . . . . . . . . . . . . . . . . . . . 5 4 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5 5 XML Schema . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 6 References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 6.1 Normative References . . . . . . . . . . . . . . . . . . . 6 6.2 Informative References . . . . . . . . . . . . . . . . . . 7 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7 Adam W. Montville Expires January 16, 2014 [Page 2] INTERNET DRAFT IODEF Enumeration Reference Format July 15, 2013 1 Introduction There is an identified need to specify a format to include relevant enumeration values in an IODEF document. It is anticipated that this requirement will exist in other standardization efforts within several IETF Working Groups, but the scope of this document pertains solely to [IODEF]. 1.1 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 RFC 2119 [RFC2119]. 2. Referencing External Enumerations The need is to place enumeration identifiers and their references in [IODEF]'s Reference class. There are several ways to accomplish this goal, but the most appropriate at this point is to require a specific format for the ReferenceName string of the [IODEF] Reference class, such that an IANA table can be used to catalog a variety of reference types. +------------------+ | Reference | +------------------+ | |<>----------[ ReferenceName ] | |<>--{0..*}--[ URL ] | |<>--{0..*}--[ Description ] +------------------+ FIGURE 1: [IODEF] Reference Class Per [IODEF] the ReferenceName is of type ML_STRING. This becomes problematic when specific references, especially enumerations such as [CVE], [CCE], [CPE] and so on, are referenced - how is an implementer to know which type of reference this is, and thus how to parse it? One solution, presented here, is to require that ReferenceName follow a particular format. 2.1 Reference Name Format The Reference Name Format uses XML to provide the structure for enumeration identification, and requires that a specific Abbreviation and RegistryVersion be associated with the ID. An implementer can look up the ID type (as referenced by the logical tuple of Abbreviation and RegistryVersion) in the IANA table (see Section 4) Adam W. Montville Expires January 16, 2014 [Page 3] INTERNET DRAFT IODEF Enumeration Reference Format July 15, 2013 to understand how the ID is structured. CXI 1 CXI-1234-XYZ http://cxi.example.com Foo Information in the IANA table (see Section 4) would include: Full Name: Concept X Identifier Abbreviation: CXI Registry Version: 1 Enumeration Version: any Specification URI: http://cxi.example.com/spec_url 2.3 Reference Method Applicability While the scope of this document pertains to [IODEF], it should be readily apparent that any standard needing to reference an enumeration identified by a specially formatted string can use this method of providing structure after the standard has been published. In effect, this method provides a standardized interface for enumerations, thus allowing a loose coupling between a given standard and the enumeration identifiers it needs to reference now and in the future. Adam W. Montville Expires January 16, 2014 [Page 4] INTERNET DRAFT IODEF Enumeration Reference Format July 15, 2013 3 Security Considerations None. 4 IANA Considerations This document specifies an identifier format for the [IODEF] ReferenceName string of the Reference class. This memo creates the following registry for IANA to manage: Name of the Registry: "Enumeration Reference Type Identifiers" Note that certain name requests should not be permitted as either Full Name or Abbreviation entries for the requested IANA table. Fields to record in the registry: Full Name: The full name of the enumeration as a string from the ASCII character set. Abbreviation: The abbreviation of the enumeration as a string from the ASCII character set. An abbreviation may be an initialism or acronym, is free-form, but is limited to between two and ten upper-case characters (used to avoid case-specific mismatch errors) meeting the regular expression (between the quotes; Perl Regular Expressions): ^[A-Z]{2,20}$ Registry Version: The IANA-registry-specific version to which an enumeration identifier pertains as an integer greater than zero. The Registry Version is intended to be incremented for each new entry, which permits any string representation for the Enumeration Version, but explicitly structures enumeration ID versions for the purpose of the registry. Enumeration Version: The version of the enumeration as a free- form string from the ASCII character set. Specification URI: A list of one or more URIs [RFC3986] from which the registered specification can be obtained. The registered specification MUST be readily and publicly available from that URI. Initial registry contents: None. Allocation Policy: Expert Review [RFC5226] and Specification Required [RFC5226] Adam W. Montville Expires January 16, 2014 [Page 5] INTERNET DRAFT IODEF Enumeration Reference Format July 15, 2013 The Designated Expert is expected to consult with the MILE (Managed Incident Lightweight Exchange) working group or its successor if any such WG exists (e.g., via email to the working group's mailing list). The Designated Expert is expected to review the request and validate the appropriateness of the enumeration for the attribute. If a specification is associated with the request, it MUST be reviewed by the Designated Expert. The Designated Expert will need to ensure the Full Name or Abbreviation entry under consideration is appropriate for the problem domain and that information at the Specification URI is sufficient for unambiguously parsing the identifier. The Designated Expert should also validate that the next appropriate Registry Version is being used for a new registration. Additionally, the Designated Expert should prefer short Abbreviations over long ones. 5 XML Schema 6 References 6.1 Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [IODEF] Danyliw, R., Meijer, J., and Y. Demchenko, "The Incident Object Description Exchange Format", RFC 5070, December 2007. [3986] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, Adam W. Montville Expires January 16, 2014 [Page 6] INTERNET DRAFT IODEF Enumeration Reference Format July 15, 2013 May 2008. 6.2 Informative References [CCE] http://cce.mitre.org [CPE] http://cpe.mitre.org [CVE] http://cve.mitre.org Authors' Addresses Adam W. Montville Center for Internet Security EMail: adam.montville@cisecurity.org David Black EMC, Inc. EMail: david.black@emc.com Adam W. Montville Expires January 16, 2014 [Page 7]