GENERAL PROCEDURES FOR REGISTERING COMPUTER SECURITY OBJECTS NISTIR 5308 - December 1993 FOREWORD The National Institute of Standards and Technology is responsible, under the Computer Security Act of 1987, for the development of standards and guidelines to assure the cost-effective security and privacy of sensitive information in Federal computer systems. In meeting this responsibility, NIST promotes development of commercial products that meet Government security requirements for secure communication. The heterogeneous nature of existing Government systems highlights the need to adhere to standards to foster interoperability among communicating systems. The use of standards alone does not insure interoperability. Implementations of specific standards may fail to interoperate because they support incompatible sets of options, accept different parameters, or employ incompatible mechanisms. For instance, security standards that rely on cryptographic algorithms to provide a confidentiality service do not usually specify what algorithm to use. Furthermore, some cryptographic algorithms have various modes of operation. To improve chances of interoperability, some implementations handle multiple options. Those implementations require that options be unambiguously identified and agreed upon by the communicating parties before data can be securely exchanged. The use of a common source for specifications of these optional elements should further interoperability. The elements referred to above are generically known as objects. A Computer Security Object (CSO) is the definition or representation of a resource, tool, or mechanism used to maintain a condition of security in computerized environments. This broad definition covers many elements referred to in standards that are either selected or defined by separate user communities. NIST is establishing a register for CSOs to provide stable object definitions identified by unique names. The use of this register will enable the unambiguous specification of security parameters and algorithms to be used in secure data exchanges. These "General Procedures for Registering Computer Security Objects" describe the object-independent procedures for operating the Computer Security Objects Register (CSOR). The CSOR services organizations and individuals seeking to use a common set of tools and techniques in the area of computer security. The procedures described herein follow guidelines for registration of the ISO/IEC Joint Technical Committee 1 (JTC1) and the American National Standards Institute (ANSI). The CSOR is not associated with a particular standard nor is it recognized by the ISO/IEC at the time of its establishment. In the future, however, NIST may turn the CSOR over to an organization recognized by the ISO/IEC for operation. Initially, one family of objects will be registered in the CSOR: network security labels. Other families of security objects that eventually may be registered include cryptographic algorithm modes of operation, security association parameter sets, and authentication techniques. Procedures for registering specific families of objects appear as appendices to this document. Further details and additional appendices will be added by the registration authority as necessary and included in updates to this document. DISCLAIMER The registration service described in this document does not provide an endorsement or approval for techniques, algorithms, or products using the specifications maintained. Similarly, there is no explicit or implicit indication of the correctness or suitability of registered computer security objects for any use. Use of the Computer Security Objects Register (CSOR) is not mandatory, although recommended as a tool for achieving interoperability. Conflicts with ownership and/or rights over alpha-numeric object names and specifications must be resolved by applicants prior to the submission of a request for registration. The registration of a security object assigns the applicant no rights over the object or its name and is therefore no absolute proof of ownership. Registered objects and their names may be protected by copyrights and or patents and their use by others than the owner may require special arrangements without the involvement of the Registration Authority. Upon requesting registration, applicants give the Registration Authority permission to reproduce and distribute the names and specifications of all objects. TABLE OF CONTENTS 1.0 Introduction. . . . . . . . . . . . . . . . . . . . . . . 1 1.1 Purpose. . . . . . . . . . . . . . . . . . . . . . . 1 1.2 Scope. . . . . . . . . . . . . . . . . . . . . . . . 1 1.3 Overview . . . . . . . . . . . . . . . . . . . . . . 2 2.0 References. . . . . . . . . . . . . . . . . . . . . . . . 2 3.0 Definitions and Abbreviations . . . . . . . . . . . . . . 2 3.1 Definitions. . . . . . . . . . . . . . . . . . . . . 2 3.2 Abbreviations. . . . . . . . . . . . . . . . . . . . 3 4.0 Registration Authority. . . . . . . . . . . . . . . . . . 4 5.0 Criteria for Eligibility . . . . . . . . . . . . . . . . 4 6.0 Processing of Applications. . . . . . . . . . . . . . . . 4 6.1 Application for Registration . . . . . . . . . . . . 5 6.2 Review of Application. . . . . . . . . . . . . . . . 5 6.3 Assignment of CSO Names. . . . . . . . . . . . . . . 6 7.0 Maintenance of the Register . . . . . . . . . . . . . . . 7 8.0 Supplemental Services . . . . . . . . . . . . . . . . . . 8 8.1 Register Inquiry . . . . . . . . . . . . . . . . . . 8 8.2 Register Publication . . . . . . . . . . . . . . . . 8 9.0 Fees. . . . . . . . . . . . . . . . . . . . . . . . . . . 8 9.1 Registration Fee . . . . . . . . . . . . . . . . . . 9 9.2 Inquiry Fee. . . . . . . . . . . . . . . . . . . . . 9 9.3 Publication Fee. . . . . . . . . . . . . . . . . . . 9 APPENDIX A - REGISTRATION AUTHORITY. . . . . . . . . . . . . .10 APPENDIX B - INFORMATION REQUESTS AND NOTICES. . . . . . . . .11 B.1 Request for Registration Application . . . . . . . .11 B.2 Registration Application Acknowledgement . . . . . .11 B.3 Rejection of Application Notice. . . . . . . . . . .12 B.4 Registration Notice. . . . . . . . . . . . . . . . .12 B.5 Inquiry Request. . . . . . . . . . . . . . . . . . .12 B.6 Inquiry Response . . . . . . . . . . . . . . . . . .13 APPENDIX C - REGISTRATION REQUIREMENTS FOR SECURITY LABELS. .14 C.1 Required Information . . . . . . . . . . . . . . . .14 C.1.1 Applicant Information . . . . . . . . . . . .14 C.1.2 General Tag Set Information . . . . . . . . .14 C.1.3 Tag-Specific Information. . . . . . . . . . .15 C.1.4 Security Object Usage Rules and Handling Instructions . 16 C.2 Security Tag Registration Rules. . . . . . . . . . .16 C.2.1 Special Rules for Bit Map Tags. . . . . . . .16 C.2.2 Special Rules for Enumerated Tags . . . . . .16 C.2.3 Special Rules for Range Tags. . . . . . . . .16 C.2.4 Special Rules for Free Form Tags. . . . . . .17 APPENDIX D - OBJECT-SPECIFIC REGISTRATION INFORMATION. . . . .18 General Procedures for Registering Computer Security Objects 1.0 Introduction 1.1 Purpose Increasingly, the establishment and use of standards in the field of Open Systems Communications is based on the use of information objects that are unambiguously identifiable. To meet this requirement, ISO/IEC JTC1 has established a hierarchical structure (a tree) of Registration Authorities. This tree is the basis for a naming methodology that assures that an object may be unambiguously identified. Unique names are constructed by concatenating name components along the path from the root to the registered object. Each name component is guaranteed to be unique within each Registration Authority's structure. ISO/IEC has designated the American National Standards Institute (ANSI) as the National Body organization to be the top level Registration Authority in the U.S. This document is based on the document, Procedures for Registering Organizational Names in the United States of America [1]. That document defines the procedures under which the U.S. Registration Authority operates. The primary purpose of this register is to specify names that uniquely identify Computer Security Objects (CSOs). Unique names can be used to reference objects during the negotiation of security services for a transaction or application. The register is also a repository of parameters associated with the registered object. Some CSOs cannot accommodate the size requirements of hierarchical names. Such CSOs require the use of fixed-length numeric names. To insure the uniqueness of numeric names assigned from such flat numbering space it is necessary to coordinate the assignment of names among the various registration authorities. The CSOR will provide such coordination by serving as the central clearing house for numeric names within shared numbering spaces. 1.2 Scope This document defines the principles of operation for the CSO Registration Authority. It establishes the role and responsibilities of both the Registration Authority and the applicant. Specifically, the procedures outlined in this document: (a) limit the role of this Registration Authority to an administrative role; (b) describe the way in which applications for registration of Computer Security Objects are handled, including mechanisms for assuring the assignment of unique names at this level in the hierarchy; (c) specify the syntax of names assigned by this Registration Authority; (d) provide for the assignment of Computer Security Object names 1.3 Overview The Registration Authority provides unique Computer Security Object (CSO) name values in two forms: numeric and alphanumeric. The Registration Authority generates the unique numeric name value. The unique value in the alphanumeric name form may be requested by the applicant, but is assigned by the Registration Authority. These two values are associated with the same object. 2.0 References [1] ANSI Procedures for Registering Organizational Names in the United States of America, ISSB 989 Rev. 2, 1991. [2] FIPS PUB 1-2 Code for Information Interchange, its Representations, Subsets, and Extensions, 1984. [3] International Organization for Standardization (ISO), "Information Technology - Open Systems Interconnection - Specification of Abstract Syntax Notation One (ASN.1)," ISO/IEC 8824, 1990. [4] ISO/IEC JTC1 N820 Guidelines for Procedure Standards for JTC1 Registration Authorities, 1990. 3.0 Definitions and Abbreviations 3.1 Definitions applicant: An entity (organization or individual) that requests the assignment of a name from a Registration Authority [4]. computer security object: Information object used to maintain a condition of security in computerized environments. Examples are: representations of computer or communications systems resources, security label semantics, modes of operation for cryptographic algorithms, and one-way hashing functions. information object: A well-defined piece of information, definition, or specification that requires a name to identify its use in an instance of communication [3]. name: A unique identifier associated with a registered object. This register assigns two of names, a numeric name and an alpha-numeric name, to each object. object identifier: A value (distinguishable from all other such values) that is associated with an information object [3]. register: A set of records (paper, electronic, or a combination) maintained by a Registration Authority containing assigned names and the associated information [4]. registration: The assignment of a name to an object [4]. Registration Authority: An organization approved by ISO/IEC for performing registration [4]. 3.2 Abbreviations ANSI American National Standards Institute ASN.1 Abstract Syntax Notation One [3] CSO Computer Security Object CSOR Computer Security Objects Register IEC International Electrotechnical Commission ISO International Organization for Standardization JTC1 Joint Technical Committee 1 OSI Open Systems Interconnection 4.0 Registration Authority The Registration Authority (see Appendix A) maintains a register of Computer Security Objects known as the CSO Register. The Registration Authority assures that registration requests conform to the registration procedures. The Registration Authority, however, does not evaluate or make any judgement of the quality of protection provided by the registered object. The Registration Authority performs the following functions: (a) reviews, then accepts or rejects registration requests in accordance with the rules provided, (b) assigns names to CSOs, (c) adds or modifies register entries in accordance with the rules provided, (d) provides copies of the register or information from the register. 5.0 Criteria for Eligibility Any organization or individual (i.e., applicant), U.S. or foreign, may request the Registration Authority to register Computer Security Objects provided that the applicant demonstrates ownership or control of the object. Applicants are required to submit a written statement asserting their ownership or control over the CSO being registered. Ownership or control is obtained either by creating the object or through delegation by the creator or owner. Although commercial products are not eligible for registration, CSOs used by such products may be registered. The CSOR will not register U. S. classified CSOs nor hold any classified information regarding registered objects. 6.0 Processing of Applications This section specifies the Registration Authority's methods for processing registration requests. These processing guidelines are designed to assure openness and due process in the registration of name values. 6.1 Application for Registration To request registration of a CSO, the applicant must submit a Request for Registration application and the appropriate registration fee to the Registration Authority. The content of this request is given in Appendix B. Object dependent information required for registration is outlined in Appendices C and D. The applicant is required to provide a release statement giving the CSOR authorization to reproduce and distribute object information. Only information required for the correct implementation and handling of CSOs is registered; security policy-related procedures and guidelines for the usage of the objects are a local matter. A registration fee must accompany all applications. This fee is used to defray the cost of operating the Registration Authority, and to discourage frivolous registration requests. If an application is rejected, the fee shall be returned minus any funds used for processing the application. (See Section 9) 6.2 Review of Application An application for registration shall be reviewed as follows: (a) The requested alphanumeric CSO name value will be compared against all previously registered or reserved names to assure a unique name value. Note: Names may be reserved for sixty working days according to the procedure in Section 8.1. (b) Because a suggested alphanumeric CSO name value may have a meaning outside the registration process, there may be challenges concerning the rights to the name. Consequently, the registration application must contain a signed statement asserting the applicant's right to the object to be registered and to the requested name. If the statement is missing, the request will be rejected specifying the omission as the reason for rejection. (c) If an application does not contain the minimum information specified in Appendix B, the application shall be rejected. The rejection notice will indicate the omission as the reason for rejection. (d) If the requesting organization does not meet the criteria for eligibility specified in Section 5, the application shall be rejected. The rejection notice will indicate the failure to meet the criteria in Section 5 as the reason for rejection. The contents of the Rejection of Application notice are specified in Appendix B. If the rejection is for reasons other than inability to demonstrate ownership, the applicant has ten working days from the date of rejection to submit any missing or incomplete information. Failure to submit the missing information during this period forfeits all fees and terminates the application process. Each application is considered separately. Applications are reviewed for completeness and a written response regarding completeness shall be issued within ten working days from the date of receipt. This response consists of either a rejection for incompleteness or a statement indicating the status of the request. The Registration Request Acknowledgement described in Appendix B is used for this purpose. Any possible appeals and objections shall be presented to the Registration Authority in writing within ten working days after the issue of the response eliciting the objection. 6.3 Assignment of CSO Names The assignment of CSO Names is the result of the registration process. This action shall be reported to the applicant within thirty working days from the date of receipt of the application. The application process is concluded by issuing the Registration Notice described in Appendix B. The registered CSO name is recorded as two values - numeric and alphanumeric. The numeric value is intended to be easily processed by computers and the alphanumeric value is intended to be easily used by people. The numeric name may, for instance, be used to index a database of objects recognized by a computer system. The alphanumeric name could be used in system specifications for procurement purposes. The applicant shall not submit a numeric name value for registration. The Registration Authority shall assign a number with a unique value that shall not be assigned to any other object. The syntax of the numeric names is one of two types: ISO-defined object identifiers [3], or an unsigned fixed-length integer. The hierarchical syntax of object identifiers guarantees the uniqueness of the name. The use of unsigned integers as numeric names requires coordination among registration authorities to insure their uniqueness. The numeric name is an index to the registration database. The applicant may supply an alphanumeric name value. Applicant- supplied alphanumeric names shall be variable length character strings of not less than one non-blank character, nor more than sixty four characters. The characters within the name strings must be taken from the 95-character graphic subset identified in FIPS PUB 1-2 [2]. For name comparison purposes, multiple spaces are equated to a single space and letter case differences will be ignored. If the alphanumeric CSO name value does not meet the applicable syntax requirements the request shall be rejected specifying this as the reason for rejection. The supplied value shall be compared against all other alphanumeric values recorded in the registration database for that computer security object type. If the value is a duplicate, the request shall be rejected specifying duplication as the reason for rejection. If the application is rejected, for either of the above reasons, the applicant shall be so notified. The contents of the Rejection of Application notice are specified in Appendix B. If the requested name is accepted, it shall be entered into the Register with the appropriate hierarchical identifier prefixed to it. This hierarchical prefix corresponds to the prefix for the numeric name. 7.0 Maintenance of the Register The Registration Authority is responsible for defining its own internal methods. These methods include: (a) mechanisms for maintaining the integrity and confidentiality of the registration database including adequate backup; (b) the design of appropriate forms (paper, electronic or both), containing the data elements specified; (c) a process for auditing the registration database and financial accounts; (d) management of the object name space. Ownership of a CSO name may be transferred. An official of the organization originally requesting registration of an object may request the Registration Authority to transfer ownership of the object and to update the register. Once registered, neither the numeric value nor the alphanumeric name value can be deleted from the register. However, they can be marked as no longer valid upon request of the owner. The process is called de-activation and it requires a written request from the owner of the CSO. De-activation requests shall include a reason for de-activation and an optional pointer to a superseding CSO. 8.0 Supplemental Services The services described below are optional and not an integral part of the Registration Authority Procedures. 8.1 Register Inquiry An inquiry service is available from the Registration Authority that allows potential applicants to determine if a name has already been registered. This saves the cost of submitting an Application for Registration specifying a CSO name that is already registered. If the name is not registered it is reserved for the originator of the inquiry for sixty working days. To make an inquiry, an organization shall submit an Inquiry Request to the Registration Authority containing the data elements specified in Appendix B. The request shall be accompanied by an inquiry fee (see Section 9.2). The Registration Authority shall respond to such an inquiry within ten working days of the receipt of the inquiry (as described in Appendix B). 8.2 Register Publication A publication service is available to provide hard copies of the CSO Register for specific object types. Single copies or one-year subscriptions may be purchased. Every copy contains all registered information on a specific CSO type. Change pages will be issued to all subscription holders as new objects are added. In addition the CSOR shall be available on-line at no cost. 9.0 Fees The fee structure is designed to recover the expenses of operating as a Registration Authority and to discourage frivolous and multiple requests. Information on the types of fees, method of payment and their amounts in United States dollars can be obtained from the Registration Authority (See Appendix A). 9.1 Registration Fee The registration fee shall be submitted along with the Request for Registration. This fee varies according to the object being registered. The Registration Authority reserves the right to change or waive the registration fee. 9.2 Inquiry Fee The inquiry fee is included by the applicant with the inquiry request. The Registration Authority reserves the right to change or waive the inquiry fee. 9.3 Publication Fee The publication fee for one-time copies and yearly subscriptions is established by the Registration Authority according to the size of the volume. The Registration Authority reserves the right to change or waive the publication fee. APPENDIX A - REGISTRATION AUTHORITY Computer Security Objects Register National Institute of Standards and Technology Computer Systems Laboratory Program Coordination and Support Group Building 225, Room B151 Gaithersburg, Maryland 20899 Telephone: (301) 975-2821 Facsimile: (301) 948-1784 APPENDIX B - INFORMATION REQUESTS AND NOTICES This appendix defines the information requests and notices used by the Registration Authority. B.1 Request for Registration Application The Request for Registration shall contain the following information: (a) name of the applicant; (b) address of the applicant; (c) name, title, address, telephone, and facsimile number of the point of contact for the applicant; (d) statement on the releasability of the registered information (if applicable); (e) statement asserting the ownership or control of the CSO for which registration is being requested and the rights over the proposed alpha-numeric name; (f) object-specific registration information (See appendices). B.2 Registration Application Acknowledgement The Registration Application Acknowledgement shall contain the following information: (a) name of the applicant; (b) address of the applicant; (c) name, title, address, telephone, and facsimile number of the point of contact for the applicant; (d) status of the Request for Registration. B.3 Rejection of Application Notice The Rejection of Application Notice shall contain the following information: (a) name of the applicant; (b) address of the applicant; (c) name, title, address, telephone, and facsimile number of the point of contact for the applicant; (d) requested alphanumeric CSO name value - if supplied; (e) stated reason for rejection. B.4 Registration Notice The Registration Notice is used to inform the applicant of the values that have been assigned and registered. This notice must be certifiable as authentic (e.g., a notary seal for paper, use of non-repudiation techniques for electronic messaging). It shall contain the following information: (a) name of the applicant; (b) address of the applicant; (c) name, title, address, telephone, and facsimile number of the point of contact for the applicant; (d) assigned numeric CSO name; (e) assigned alphanumeric CSO name. B.5 Inquiry Request The Inquiry Request will contain the following information: (a) name of the inquiry originator; (b) address of the inquiry originator; (c) name, title, address, telephone, and facsimile number of the point of contact for the inquiry originator; (d) queried alphanumeric CSO name. B.6 Inquiry Response This Inquiry Response will contain the following information: (a) name of the applicant; (b) address of the applicant; (c) name, title, address, telephone, and facsimile number of the point of contact for the applicant; (d) queried alphanumeric CSO name value; (e) status of the queried alphanumeric CSO name (e.g., already in use or not in use). APPENDIX C - REGISTRATION REQUIREMENTS FOR SECURITY LABELS This appendix outlines object-specific registration procedures for security label Named Tag Sets as defined by FIPS 188 - Standard Security Label for Information Transfer (SSL). Object-specific registration procedures indicate details that must be provided to register CSOs of a certain type. The required information is limited to details necessary to implement correctly the objects. The information outlined in this appendix shall be included with the Request for Registration Application specified in Appendix B of this document. Register Fields are associated with local security policy, therefore policy-driven handling instructions and system responses to potential security events should be included in the registration information. The rationale for the handling instructions imposed and the meaning of the security information to the end system are local matters not to be included with the Request for Registration Application. C.1 Required Information C.1.1 Applicant Information Applicant name: Point of contact: Date: C.1.2 General Tag Set Information Tag Set Name Format: [ ] Object Identifier (Layer 7 label syntax) [ ] Unsigned Integer (Layer 3 label encoding) Requested Alpha-Numeric Name: Maximum number of security tags: Minimum number of security tags: Tag combination and ordering rules: C.1.3 Tag-Specific Information For each tag indicate: Tag number: Is order significant? (Yes/No) Tag Type: Is tag Optional or Mandatory? List of valid attribute values: The table format in the following example may be used to describe each tag. TT stands for tag type and TL is the tag length. The types are given in the SSL document. Only the tag values indicated will be accepted by an implementation of the Tag Set. An optional mnemonic may be associated to the each attribute value, bit, or field on the tag. A default value for each tag may be given, if appropriate. An optional tag order indication within the set also may be given. The presence of the tag in the set may be marked mandatory or optional. A Tag Set that does not match the format associated with the Tag Set Name preceding it is in error and shall be treated as such by the implementation. ÚÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ¿ ³ T TL VALUE MNEMONIC DEFAULT ORDER M/O ³ ³ (Optional) VALUE ³ ³ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄij ³o1 01 (Security N/A M ³ ³ Level) ³ ³ 11011011 CRITICAL 00000000 ³ ³ 10101010 RESTRICTED ³ ³ 01010101 PROTECTED ³ ³ 00100100 GENERIC ³ ³ 00000000 unmarked ³ ³ ³ ³ (Bits) ³ ³ B16, 1 FOR-OFFICIAL-USE-ONLY 0 (May be omitted if ³ ³ B15, 1 CERTIFIED-COPIES-ONLY all bits are 0) ³ ³ B14, 1 DO-NOT-COPY ³ ³ B13, 1 TIME-SENSITIVE ³ ³ . ³ ³ . ³ ³ . ³ ³ B01, 1 PROPRIETARY ³ ³ ³ ÀÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÙ C.1.4 Security Object Usage Rules and Handling Instructions This section shall cover object usage rules, handling instructions, and implementation details or restrictions beyond those imposed by the base standard. The text in this section may be used to clarify security tag information appearing in the Format Table. Examples are error conditions and their required system response such as return of an error response and local event auditing. The processing rules in Appendix B of the Standard Security Label FIPS may be referenced in this section. Explicit omissions, additions, or refinements to the processing rules in the SSL document also must appear in this section. C.2 Security Tag Registration Rules C.2.1 Special Rules for Bit Map Tags 1. Bit maps are defined to include integer multiples of eight bits. 2. All bits are numbered starting with one up to some upper bound, U, that follows the previous rule. 3. Bits not included in the bit map tag definition that fall between 1 and U are reserved and should not be used. The value for these bits is set to the default value indicated. C.2.2 Special Rules for Enumerated Tags 1. The registration entry must specify whether the security attributes specified are to be included or excluded from the set of attributes that apply to the data unit. 2. If it were necessary to explicitly single out attributes for both inclusion and exclusion, they must appear in separate tags. To make the distinction, tag order shall be used. C.2.3 Special Rules for Range Tags 1. The registration entry must specify whether the security attributes in the specified range(s) are to be included or excluded from the set of attributes that apply to the data unit. 2. If it were necessary to explicitly single out ranges for both inclusion and exclusion, they must appear in separate tags. To make the distinction, tag order shall be used. C.2.4 Special Rules for Free Form Tags 1. The unspecified nature of this tag requires that both the syntax and semantics be explicitly stated. 2. For this and all tag types, the distinction between tags of the same type with different interpretations is based on the relative order of the tags. APPENDIX D - OBJECT-SPECIFIC REGISTRATION INFORMATION This appendix is a place holder for the Registration Authority to provide additional object-specific registration procedures. Appendices will be added to these general procedures for each CSO family to be registered. Object-specific registration requirements indicate the list of technical details that must be provided in order to register objects of that type. The required information will be limited to details necessary to implement correctly the object.