idnits 2.17.1 draft-ietf-pkix-pi-11.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == There is 1 instance of lines with non-ascii characters in the document. == The page length should not exceed 58 lines per page, but there was 13 longer pages, the longest (page 10) being 60 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 14 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There is 1 instance of too long lines in the document, the longest one being 8 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- -- The first octets (the first characters of the first line) of this draft are 'PK', which can make Internet Explorer erroneously think that it is a zip file. It is recommended that you change this, for instance by inserting a blank line before the line starting with 'PK'. == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHALL not' in this paragraph: If there are one or more RDNs containing a serialNumber attribute (alone or accompanied by other attributes), then the value contained in the serialNumber of the deepest such RDN SHALL be used as the identifierValue; otherwise, the Permanent Identifier definition is invalid and the Permanent Identifier SHALL not be used. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (September 2004) is 7160 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC 3667' is defined on line 349, but no explicit reference was found in the text == Unused Reference: 'RFC 3668' is defined on line 352, but no explicit reference was found in the text == Unused Reference: 'RFC 2119' is defined on line 355, but no explicit reference was found in the text == Unused Reference: 'Unicode' is defined on line 361, but no explicit reference was found in the text == Unused Reference: 'ISO10646' is defined on line 368, but no explicit reference was found in the text == Unused Reference: 'UTF-8' is defined on line 371, but no explicit reference was found in the text ** Obsolete normative reference: RFC 3667 (Obsoleted by RFC 3978) ** Obsolete normative reference: RFC 3668 (Obsoleted by RFC 3979) ** Obsolete normative reference: RFC 3280 (Obsoleted by RFC 5280) -- Possible downref: Non-RFC (?) normative reference: ref. 'Unicode' -- Possible downref: Non-RFC (?) normative reference: ref. 'ISO10646' ** Obsolete normative reference: RFC 2279 (ref. 'UTF-8') (Obsoleted by RFC 3629) -- Obsolete informational reference (is this intentional?): RFC 3852 (Obsoleted by RFC 5652) Summary: 6 errors (**), 0 flaws (~~), 11 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 PKIX Working Group D. Pinkas (Bull) 2 INTERNET-DRAFT T. Gindin (IBM) 3 Expires: March 2005 September 2004 4 Target category: Standard Track 6 Internet X.509 Public Key Infrastructure 7 Permanent Identifier 8 10 Status of this Memo 12 By submitting this Internet-Draft, each co-editor certifies that 13 he is not aware of any related applicable patent or other IPR 14 claims, and that any of which he may become aware will be disclosed 15 until publication of the draft as an RFC, in accordance with 16 section 6 of BCP 79 [RFC 3668]. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that other 20 groups may also distribute working documents as Internet-Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.html. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 Please send comments on this document to the ietf-pkix@imc.org 34 mailing list. 36 Abstract 38 This document define a new form of name, called permanent 39 identifier, that may be included in the subjectAltName extension 40 of a public key certificate issued to an entity. 42 The permanent identifier is an optional feature that may be used 43 by a CA to indicate that two or more certificates relate to the 44 same entity, even if they contain different subject name (DNs) or 45 different names in the subjectAltName extension, or if the name 46 or the affiliation of that entity stored in the subject or another 47 name form in the subjectAltName extension has changed. 49 The subject name, carried in the subject field, is only unique 50 for each subject entity certified by the one CA as defined by the 51 issuer name field. However, the new name form can carry a 52 name that is unique for each subject entity certified by a CA. 54 Permanent Identifier September 2004 56 Table of Contents 58 1. Introduction...............................................2 59 2. Definition of a Permanent Identifier.......................3 60 3. IANA Considerations........................................5 61 4. Security considerations....................................6 62 5. References.................................................7 63 5.1 Normative...............................................7 64 5.2 Informative.............................................7 65 6. Author's Addresses.........................................8 66 7. Intellectual Property Rights...............................8 67 Appendix A. ASN.1 syntax............................................9 68 A.1 1988 ASN.1 Module.....................................10 69 A.2 1993 ASN.1 Module.....................................11 70 Appendix B. OID's for organizations................................12 71 B.1 Using IANA (Internet Assigned Numbers Authority).......12 72 B.2 Using an ISO member body...............................12 73 B.3 Using an ICD (International Code Designator) from 74 British Standards Institution to specify a new or 75 an existing identification scheme......................13 76 Full Copyright Statement...........................................14 78 1 Introduction 80 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 81 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 82 document are to be interpreted as described in RFC 2119. 84 This specification is based on RFC 3280, which defines underlying 85 certificate formats and semantics needed for a full implementation 86 of this standard. 88 The subject field of a public key certificate identifies the entity 89 associated with the public key stored in the subject public key 90 field. Names and identities of a subject may be carried in the 91 subject field and/or the subjectAltName extension. Where subject 92 field is non-empty, it MUST contain an X.500 distinguished 93 name (DN). The DN MUST be unique for each subject entity certified 94 by a single CA as defined by the issuer name field. 96 The subject name changes whenever any of the components of that 97 name gets changed. There are several reasons for such a change to 98 happen. 100 For employees of a company or organization, the person may get 101 a different position within the same company and thus will 102 move from one organization unit to another one. Including the 103 organization unit in the name may however be very useful to 104 allow the relying parties (RP's) using that certificate to 105 identify the right individual. 107 For citizens, an individual may change their name by legal 108 processes, especially as a result of marriage. 110 Permanent Identifier September 2004 112 Any certificate subject identified by geographical location may 113 relocate and change at least some of the location attributes 114 (e.g. country name, state or province, locality, or street). 116 A permanent identifier consists of an identifier value assigned 117 within a given naming space by the organization which is 118 authoritative for that naming space. The organization assigning 119 the identifier value may be the CA that has issued the certificate 120 or a different organization called an Assigner Authority. 122 An Assigner Authority may be a government, a government agency, a 123 corporation, or any other sort of organization. It MUST have a 124 unique identifier to distinguish it from any other such authority. 125 In this standard, that identifier MUST be an object identifier. 127 A permanent identifier may be useful in three contexts: access 128 control, non-repudiation and audit records. 130 For access control, the permanent identifier may be used in 131 an ACL (Access Control List) instead of the DN or any other 132 form of name and would not need to be changed, even if the 133 subject name of the entity changes. 134 For non-repudiation, the permanent identifier may be used to 135 link different transactions to the same entity, even when 136 the subject name of the entity changes. 138 For audit records, the permanent identifier may be used to 139 link different audit records to the same entity, even when 140 the subject name of the entity changes. 142 For two certificates which have been both verified to be valid 143 according to a given validation policy and which contain a permanent 144 identifier, those certificates relate to the same entity if their 145 permanent identifiers match, whatever the content of the DN or 146 other subjectAltName components may be. 148 Since the use of permanent identifiers may conflict with privacy, 149 CAs SHOULD advertise to purchasers of certificates the use of 150 permanent identifiers in certificates. 152 2. Definition of a Permanent Identifier 154 This Permanent Identifier is a name defined as a form of otherName 155 from the GeneralName structure in SubjectAltName. 157 A CA which includes a permanent identifier in a certificate is 158 certifying that any public key certificate containing the same 159 values for that identifier refers to the same entity. 161 The use of a permanent identifier is OPTIONAL. The permanent 162 identifier is defined as follows: 164 id-on-permanentIdentifier OBJECT IDENTIFIER ::= { id-on 3 } 166 Permanent Identifier September 2004 168 PermanentIdentifier ::= SEQUENCE { 169 identifierValue UTF8String OPTIONAL, 170 -- if absent, use a serialNumber attribute, 171 -- if there is such an attribute present 172 -- in the subject DN 173 assigner OBJECT IDENTIFIER OPTIONAL 174 -- if absent, the assigner is 175 -- the certificate issuer 176 } 178 The identifierValue field is optional. 180 When the identifierValue field is present, then the identifierValue 181 supports one syntax: UTF8String. 183 When the identifierValue field is absent, then the value of the 184 serialNumber attribute from the deepest RDN of the subject DN is 185 the value to be taken for the identifierValue. In such a case, 186 there MUST be at least one serialNumber attribute in the subject DN, 187 otherwise the PermanentIdentifier SHALL NOT be used. 189 The assigner field is optional. 191 When the assigner field is present, then it is an OID which 192 identifies a naming space, i.e. both an Assigner Authority and the 193 type of that field. Characteristically, the prefix of the OID 194 identifies the Assigner Authority, and a suffix is used to identify 195 the type of permanent identifier. 197 When the assigner field is absent, then the permanent identifier is 198 locally unique to the CA. 200 The various combinations are detailed below: 202 1- Both the assigner and the identifierValue fields are present: 204 The identifierValue is the value for that type of identifier. The 205 assigner field identifies the Assigner Authority and the type 206 of permanent identifier being identified. 208 The permanent identifier is globally unique among all CAs. In such 209 a case, two permanent identifiers of this type match if and only if 210 their assigner fields match and the contents of the identifierValue 211 field in the two permanent identifiers consist of the same Unicode 212 code points presented in the same order. 214 2 - The assigner field is absent and the identifierValue field is 215 present: 217 The Assigner Authority is the CA that has issued the certificate. 218 The identifierValue is given by the CA and the permanent identifier 219 is only local to the CA that has issued the certificate. 221 Permanent Identifier September 2004 223 In such a case, two permanent identifiers of this type match if and 224 only if the issuer DN's in the certificates which contain them 225 match using the distinguishedNameMatch rule, as defined in X.501 , 226 and the two values of the identifierValue field consist of the same 227 Unicode code points presented in the same order. 229 3 - Both the assigner and the identifierValue fields are absent: 231 If there are one or more RDNs containing a serialNumber attribute 232 (alone or accompanied by other attributes), then the value 233 contained in the serialNumber of the deepest such RDN SHALL be 234 used as the identifierValue; otherwise, the Permanent Identifier 235 definition is invalid and the Permanent Identifier SHALL NOT be 236 used. 238 The permanent identifier is only local to the CA that has issued 239 the certificate. In such a case, two permanent identifiers of this 240 type match if and only if the issuer DN's in the certificates which 241 contain them match and the serialNumber attributes within the 242 subject DN's of those same certificates also match using the 243 caseIgnoreMatch rule. 245 4 - The assigner field is present and the identifierValue field is 246 absent: 248 If there are one or more RDNs containing a serialNumber attribute 249 (alone or accompanied by other attributes), then the value 250 contained in the serialNumber of the deepest such RDN SHALL be 251 used as the identifierValue; otherwise, the Permanent Identifier 252 definition is invalid and the Permanent Identifier SHALL not be 253 used. 255 The assigner field identifies the Assigner Authority and the type 256 of permanent identifier being identified. 258 The permanent identifier is globally unique among all CAs. In such 259 a case, two permanent identifiers of this type match if and only if 260 their assigner fields match and the contents the serialNumber 261 attributes within the subject DN's of those same certificates match 262 using the caseIgnoreMatch rule. 264 Note: the full arc of the object identifier used to identify the 265 permanent identifier name form is derived using: 267 id-pkix OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) 268 dod(6) internet(1) security(5) mechanisms(5) pkix(7) } 270 id-on OBJECT IDENTIFIER ::= { id-pkix 8 } -- other name forms 272 3. IANA Considerations 274 No IANA actions are necessary. However, a Private Enterprise Number may be used 275 to construct an OID for the assigner field (see Annex B1). 277 Permanent Identifier September 2004 279 4. Security considerations 281 A given entity may have at an instant of time or at different 282 instants of time multiple forms of identities. If the permanent 283 identifier is locally unique to the CA (i.e. the assigner field is 284 not present), then two certificates from the same CA can be 285 compared. 287 When they contain two identical permanent identifiers, then a 288 relying party may determine that they refer to the same entity. 290 If the permanent identifier is globally unique among all CAs (i.e. 291 the assigner field is present), then two certificates from different 292 CAs can be compared. When they contain two identical permanent 293 identifiers, then a relying party may determine that they refer to 294 the same entity. It is the responsibility of the CA to verify that 295 the permanent identifier being included in the certificate refers 296 to the subject being certified. 298 The permanent identifier identifies the entity, irrespective of any 299 attribute extension. When a public key certificate contains 300 attribute extensions, the permanent identifier, if present, should 301 not be used for access control purposes but only for audit purposes. 302 The reason is that since these attributes may change, access could 303 be granted on attributes that were originally present in a 304 certificate issued to that entity but are no longer present in the 305 current certificate. 307 Subject names in certificates are chosen by the issuing CA and are 308 mandated to be unique for each CA; so there can be no name collision 309 between subject names from the same CA. These names may be an 310 end-entity name when the certificate is a leaf certificate, or a 311 CA name, when it is a CA certificate. 313 Since a name is only unique towards its superior CA, unless some 314 naming constraints are being used, a name would only be guaranteed 315 to be globally unique when considered to include a sequence of all 316 the names of the superior CAs. Thus, two certificates that are 317 issued under the same issuer DN and which contain the same 318 permanent identifier extension without an assigner field do not 319 necessarily refer to the same entity. 321 Additional checks need to be done, e.g. to check if the public key 322 values of the two CAs which have issued the certificates to be 323 compared are identical or if the sequence of CA names in the 324 certification path from the trust anchor to the CA are identical. 326 When the above checks fail, the permanents identifiers may still 327 match if there has been a CA key rollover. In such a case the 328 checking is more complicated. 330 Permanent Identifier September 2004 332 The certification of different CAs with the same DN by different 333 CAs has other negative consequences in various parts of the PKI, 334 notably rendering the IssuerAndSerialNumber structure in [RFC 3852] 335 section 10.2.4 ambiguous. 337 The permanent identifier allows organizations to create links 338 between different certificates associated with an entity issued 339 with or without overlapping validity periods. This ability to link 340 different certificates may conflict with privacy. It is therefore 341 important that a CA clearly disclose any plans to issue certificates 342 which include a permanent identifier to potential subjects of those 343 certificates. 345 5. References 347 5.1. Normative 349 [RFC 3667] S. Bradner. BCP 78. IETF Rights in Contributions, 350 February 2004. 352 [RFC 3668]. S. Bradner. BCP 79. Intellectual Property Rights in 353 IETF Technology, February 2004. 355 [RFC 2119] S. Bradner, "Key words for use in RFCs to Indicate 356 Requirement Levels", March 1997. 358 [RFC 3280] R. Housley, W. Ford, W. Polk, and D. Solo, "Internet X.509 359 Public Key Infrastructure: Certificate and CRL Profile", April 2002. 361 [Unicode] The Unicode Consortium, "The Unicode Standard, Version 362 3.2.0" is defined by "The Unicode Standard, Version 3.0" 363 (Reading, MA, Addison-Wesley, 2000. ISBN 0-201-61633-5), as amended 364 by the "Unicode Standard Annex #27: Unicode 3.1" 365 (http://www.unicode.org/reports/tr27/) and by the "Unicode Standard 366 Annex #28: Unicode 3.2" (http://www.unicode.org/reports/tr28/). 368 [ISO10646] Universal Multiple-Octet Coded Character Set (UCS) - 369 Architecture and Basic Multilingual Plane, ISO/IEC 10646-1: 1993. 371 [UTF-8] RFC 2279. F. Yergeau. UTF-8, a transformation format of 372 ISO 10646, January 1998. 374 [X.501] ITU-T Rec X.501 | ISO 9594-2: 2001 Information technology. 375 Open Systems Interconnection. The Directory: Models 377 5.2. Informative 379 [RFC 3852] R.Housley. Cryptographic Message Syntax (CMS), July 2004. 381 [X.509] ITU-T Recommendation X.509 (1997 E): Information Technology 382 - Open Systems Interconnection - The Directory: Authentication 383 Framework, June 1997. 385 Permanent Identifier September 2004 387 [X.520] ITU-T Recommendation X.520: Information Technology - Open 388 Systems Interconnection - The Directory: Selected Attribute Types, 389 June 1997. 391 [X.660] ITU-T Recommendation X.660: Information Technology - 392 Open Systems Interconnection - Procedures for the Operation of 393 OSI Registration Authorities: General Procedures, 1992. 395 [X.680] ITU-T Recommendation X.680: Information Technology - 396 Abstract Syntax Notation One, 1997. 398 6. Author's Addresses 400 Denis Pinkas 401 Bull 402 Rue Jean-Jaur�s. BP 68 403 78340 Les Clayes-sous-Bois 404 FRANCE 405 Email: Denis.Pinkas@bull.net 407 Thomas Gindin 408 IBM Corporation 409 6710 Rockledge Drive 410 Bethesda, MD 20817 411 USA 412 Email: tgindin@us.ibm.com 414 7. Intellectual Property Rights 416 The IETF takes no position regarding the validity or scope of any 417 intellectual property or other rights that might be claimed to 418 pertain to the implementation or use of the technology described in 419 this document or the extent to which any license under such rights 420 might or might not be available; neither does it represent that it 421 has made any effort to identify any such rights. Information on the 422 IETF's procedures with respect to rights in standards-track and 423 standards related documentation can be found in BCP-11. Copies of 424 claims of rights made available for publication and any assurances of 425 licenses to be made available, or the result of an attempt made to 426 obtain a general license or permission for the use of such 427 proprietary rights by implementors or users of this specification 428 can be obtained from the IETF Secretariat. 430 The IETF invites any interested party to bring to its attention any 431 copyrights, patents or patent applications, or other proprietary 432 rights which may cover technology that may be required to practice 433 this standard. Please address the information to the IETF Executive 434 Director. 436 Permanent Identifier September 2004 438 APPENDIX A. ASN.1 syntax 440 As in RFC 2459, ASN.1 modules are supplied in two different variants 441 of the ASN.1 syntax. 443 This section describes data objects used by conforming PKI components 444 in an "ASN.1-like" syntax. This syntax is a hybrid of the 1988 and 445 1993 ASN.1 syntaxes. The 1988 ASN.1 syntax is augmented with 1993 446 the UNIVERSAL Type UTF8String. 448 The ASN.1 syntax does not permit the inclusion of type statements in 449 the ASN.1 module, and the 1993 ASN.1 standard does not permit use of 450 the new UNIVERSAL types in modules using the 1988 syntax. As a 451 result, this module does not conform to either version of the ASN.1 452 standard. 454 Appendix A.1 may be parsed by an 1988 ASN.1-parser by replacing the 455 definitions for the UNIVERSAL Types with the 1988 catch-all "ANY". 457 Appendix A.2 may be parsed by an 1993 ASN.1-parser by removing the 458 UTF8String choice from the definition of IdentifierValue in the 459 module. Appendix A.2 may be parsed "as is" by an 1997-compliant 460 ASN.1 parser. 462 In case of discrepancies between these modules, the 1988 module is 463 the normative one. 465 Permanent Identifier September 2004 467 APPENDIX A.1. 1988 ASN.1 Module 469 PKIXpermanentidentifier88 {iso(1) identified-organization(3) dod(6) 470 internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) 471 id-mod-perm-id-88(28) } 473 DEFINITIONS EXPLICIT TAGS ::= 475 BEGIN 477 -- EXPORTS ALL -- 479 IMPORTS 481 -- UTF8String, / move hyphens before slash if UTF8String does not 482 -- resolve with your compiler 483 -- The content of this type conforms to RFC 2279. 485 id-pkix 486 FROM PKIX1Explicit88 { iso(1) identified-organization(3) 487 dod(6) internet(1) security(5) mechanisms(5) pkix(7) 488 id-mod(0) id-pkix1-explicit(18) } ; 489 -- from [RFC 3280] 491 -- Permanent identifier Object Identifier and Syntax 493 id-on OBJECT IDENTIFIER ::= { id-pkix 8 } 495 id-on-permanentIdentifier OBJECT IDENTIFIER ::= { id-on 3 } 497 PermanentIdentifier ::= SEQUENCE { 498 identifierValue UTF8String OPTIONAL, 499 -- if absent, use the serialNumber attribute 500 -- if there is a single such attribute present 501 -- in the subject DN 502 assigner OBJECT IDENTIFIER OPTIONAL 503 -- if absent, the assigner is 504 -- the certificate issuer 505 } 507 END 509 Permanent Identifier September 2004 511 APPENDIX A.2. 1993 ASN.1 Module 513 PKIXpermanentidentifier93 {iso(1) identified-organization(3) dod(6) 514 internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) 515 id-mod-perm-id-93(29) } 517 DEFINITIONS EXPLICIT TAGS ::= 519 BEGIN 521 -- EXPORTS ALL -- 523 IMPORTS 525 id-pkix 526 FROM PKIX1Explicit88 { iso(1) identified-organization(3) 527 dod(6) internet(1) security(5) mechanisms(5) pkix(7) 528 id-mod(0) id-pkix1-explicit(18) } 529 -- from [RFC 3280] 531 ATTRIBUTE 532 FROM InformationFramework {joint-iso-itu-t ds(5) module(1) 533 informationFramework(1) 4}; 534 -- from [X.501] 536 -- Permanent identifier Object Identifiers 538 id-on OBJECT IDENTIFIER ::= { id-pkix 8 } 540 id-on-permanentIdentifier OBJECT IDENTIFIER ::= { id-on 3 } 542 -- Permanent Identifier 544 permanentIdentifier ATTRIBUTE ::= { 545 WITH SYNTAX PermanentIdentifier 546 ID id-on-permanentIdentifier } 548 PermanentIdentifier ::= SEQUENCE { 549 identifierValue UTF8String OPTIONAL, 550 -- if absent, use the serialNumber attribute 551 -- if there is a single such attribute present 552 -- in the subject DN 553 assigner OBJECT IDENTIFIER OPTIONAL 554 -- if absent, the assigner is 555 -- the certificate issuer 556 } 558 END 560 Permanent Identifier September 2004 562 APPENDIX B. OID's for organizations 564 In order to construct an OID for the assigner field, organizations need 565 first to have a registered OID for themselves. In some cases, OID's are 566 provided for free. In other cases a one-time fee is required. The main 567 difference lies in the nature of the information that is collected at 568 the time of registration and how this information is verified for its 569 accuracy. 571 B.1. Using IANA (Internet Assigned Numbers Authority) 573 The application form for a Private Enterprise Number in the IANA's 574 OID list is: http://www.iana.org/cgi-bin/enterprise.pl. 576 Currently IANA assigns numbers for free. The IANA-registered Private 577 Enterprises prefix is: iso.org.dod.internet.private.enterprise 578 (1.3.6.1.4.1) 580 These numbers are used, among other things, for defining private 581 SNMP MIBs. 583 The official assignments under this OID are stored in the IANA file 584 "enterprise-numbers" available at: 585 http://www.iana.org/assignments/enterprise-numbers 587 B.2. Using an ISO member body 589 ISO has defined the OID structure in a such a way so that every ISO 590 member-body has its own unique OID. Then every ISO member-body is free 591 to allocate its own arc space below. 593 Organizations and enterprises may contact the ISO member-body where 594 their organization or enterprise is established to obtain an 595 organization/enterprise OID. 597 Currently, ISO members do not assign organization/enterprise OID's for 598 free. 600 Most of them do not publish registries of such OID's which they have 601 assigned, sometimes restricting the access to registered organizations 602 or preferring to charge inquirers for the assignee of an OID on a 603 per-inquiry basis. The use of OID's from an ISO member organization 604 which does not publish such a registry may impose extra costs on the 605 CA that needs to make sure that the OID corresponds to the registered 606 organization. 608 As an example, AFNOR (Association Francaise de Normalisation - the 609 French organization that is a member of ISO) has defined an arc to 610 allocate OID's for companies: 612 {iso (1) member-body (2) fr (250) type-org (1) organisation (n)} 614 Permanent Identifier September 2004 616 B.3. Using an ICD (International Code Designator) from British Standards 617 Institution to specify a new or an existing identification scheme 619 The International Code Designator (ICD) is used to uniquely identify an 620 ISO 6523 compliant organization identification scheme. ISO 6523 is a 621 standard that defines the proper structure of an identifier and the 622 registration procedure for an ICD. The conjunction of the ICD with an 623 identifier issued by the registration authority is worldwide unique. 625 The basic structure of the code contains the following components: 627 - the ICD value: The International Code Designator issued to the 628 identification scheme makes the identifier worldwide unique 629 (up to 4 digits), 631 - the Organization, usually a company or governmental body 632 (up to 35 characters), 634 - an Organization Part (OPI - Organization Part Identifier). 635 An identifier allocated to a particular Organization Part 636 (optional, up to 35 characters) 638 The ICD is also equivalent to an object identifier (OID) under the arc 639 {1(iso). 3(identified organization)}. 641 On behalf of ISO, British Standards Institution (BSI) is the 642 Registration Authority for organizations under the arc {iso (1) org(3)}. 643 This means BSI registers code issuing authorities (organizations) by 644 ICD values which are equivalent to OIDs of the form {iso (1) org(3) 645 icd(xxxx)}. The corresponding IdentifierValue is the code value of the 646 scheme identified by icd(xxxx). 648 As an example, the ICD 0012 was allocated to European Computer 649 Manufacturers Association: ECMA. Thus the OID for ECMA is 650 {iso(1) org(3) ecma(12)}. 652 For registration with BSI, a "Sponsoring Authority" has to vouch for the 653 Applying organization. Registration is not free. Recognized "Sponsoring 654 Authorities" are: ISO Technical Committees or (Sub)Committees, Member 655 Bodies of ISO or International Organizations having a liaison status 656 with ISO or with any of its Technical (Sub)Committees. 658 An example of a Sponsoring Authority is the EDIRA Association 659 (EDI/EC Registration Authority, web: http://www.edira.org, 660 email:info@edira.org). 662 The numerical list of all ICDs that have been issued is posted on its 663 webpage: http://www.edira.org/documents.htm#icd-List 665 Note: IANA owns ICD code 0090, but that (presumably) it isn't intending 666 to use it for the present purpose. 668 Permanent Identifier September 2004 670 Full Copyright Statement 672 Copyright (C) The Internet Society (2004). All Rights Reserved. 674 This document and translations of it may be copied and furnished to 675 others, and derivative works that comment on or otherwise explain it 676 or assist in its implementation may be prepared, copied, published 677 and distributed, in whole or in part, without restriction of any 678 kind, provided that the above copyright notice and this paragraph are 679 included on all such copies and derivative works. In addition, the 680 ASN.1 modules presented in Appendices A and B may be used in whole or 681 in part without inclusion of the copyright notice. However, this 682 document itself may not be modified in any way, such as by removing 683 the copyright notice or references to the Internet Society or other 684 Internet organizations, except as needed for the purpose of 685 developing Internet standards in which case the procedures for 686 copyrights defined in the Internet Standards process shall be 687 followed, or as required to translate it into languages other than 688 English. 690 The limited permissions granted above are perpetual and will not be 691 revoked by the Internet Society or its successors or assigns. 693 This document is subject to the rights, licenses and restrictions 694 contained in BCP 78 [RFC 3667], and except as set forth therein, 695 the authors retain all their rights." 697 This document and the information contained herein are provided 698 on an"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 699 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND 700 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, 701 EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT 702 THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR 703 ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A 704 PARTICULAR PURPOSE.