third_party/heimdal/doc/standardisation/rfc4043.txt

   1
   2
   3
   4
   5
   6
   7 Network Working Group                                          D. Pinkas
   8 Request for Comments: 4043                                          Bull
   9 Category: Standards Track                                      T. Gindin
  10                                                                      IBM
  11                                                                 May 2005
  12
  13
  14                 Internet X.509 Public Key Infrastructure
  15                           Permanent Identifier
  16
  17 Status of This Memo
  18
  19    This document specifies an Internet standards track protocol for the
  20    Internet community, and requests discussion and suggestions for
  21    improvements.  Please refer to the current edition of the "Internet
  22    Official Protocol Standards" (STD 1) for the standardization state
  23    and status of this protocol.  Distribution of this memo is unlimited.
  24
  25 Copyright Notice
  26
  27    Copyright (C) The Internet Society (2005).
  28
  29 Abstract
  30
  31    This document defines a new form of name, called permanent
  32    identifier, that may be included in the subjectAltName extension of a
  33    public key certificate issued to an entity.
  34
  35    The permanent identifier is an optional feature that may be used by a
  36    CA to indicate that two or more certificates relate to the same
  37    entity, even if they contain different subject name (DNs) or
  38    different names in the subjectAltName extension, or if the name or
  39    the affiliation of that entity stored in the subject or another name
  40    form in the subjectAltName extension has changed.
  41
  42    The subject name, carried in the subject field, is only unique for
  43    each subject entity certified by the one CA as defined by the issuer
  44    name field.  However, the new name form can carry a name that is
  45    unique for each subject entity certified by a CA.
  46
  47
  48
  49
  50
  51
  52
  53
  54
  55
  56
  57
  58 Pinkas & Gindin             Standards Track                     [Page 1]
  59 \f
  60 RFC 4043                  Permanent Identifier                  May 2005
  61
  62
  63 Table of Contents
  64
  65    1.  Introduction..................................................  2
  66    2.  Definition of a Permanent Identifier..........................  3
  67    3.  IANA Considerations...........................................  6
  68    4.  Security Considerations.......................................  6
  69    5.  References....................................................  7
  70        5.1.  Normative References....................................  7
  71        5.2.  Informative References..................................  8
  72    Appendix A. ASN.1 Syntax..........................................  9
  73        A.1.  1988 ASN.1 Module.......................................  9
  74        A.2.  1993 ASN.1 Module....................................... 10
  75    Appendix B. OID's for organizations............................... 11
  76        B.1.  Using IANA (Internet Assigned Numbers Authority)........ 11
  77        B.2.  Using an ISO Member Body................................ 12
  78        B.3.  Using an ICD (International Code Designator) From
  79              British Standards Institution to Specify a New or
  80              an Existing Identification Scheme....................... 12
  81    Authors' Addresses................................................ 14
  82    Full Copyright Statement.......................................... 15
  83
  84 1.  Introduction
  85
  86    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
  87    "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
  88    document are to be interpreted as described in [RFC2119].
  89
  90    This specification is based on [RFC3280], which defines underlying
  91    certificate formats and semantics needed for a full implementation of
  92    this standard.
  93
  94    The subject field of a public key certificate identifies the entity
  95    associated with the public key stored in the subject public key
  96    field.  Names and identities of a subject may be carried in the
  97    subject field and/or the subjectAltName extension.  Where subject
  98    field is non-empty, it MUST contain an X.500 distinguished name (DN).
  99    The DN MUST be unique for each subject entity certified by a single
 100    CA as defined by the issuer name field.
 101
 102    The subject name changes whenever any of the components of that name
 103    gets changed.  There are several reasons for such a change to happen.
 104
 105       For employees of a company or organization, the person may get a
 106       different position within the same company and thus will move from
 107       one organization unit to another one.  Including the organization
 108       unit in the name may however be very useful to allow the relying
 109       parties (RP's) using that certificate to identify the right
 110       individual.
 111
 112
 113
 114 Pinkas & Gindin             Standards Track                     [Page 2]
 115 \f
 116 RFC 4043                  Permanent Identifier                  May 2005
 117
 118
 119       For citizens, an individual may change their name by legal
 120       processes, especially as a result of marriage.
 121
 122       Any certificate subject identified by geographical location may
 123       relocate and change at least some of the location attributes
 124       (e.g., country name, state or province, locality, or street).
 125
 126    A permanent identifier consists of an identifier value assigned
 127    within a given naming space by the organization which is
 128    authoritative for that naming space.  The organization assigning the
 129    identifier value may be the CA that has issued the certificate or a
 130    different organization called an Assigner Authority.
 131
 132    An Assigner Authority may be a government, a government agency, a
 133    corporation, or any other sort of organization.  It MUST have a
 134    unique identifier to distinguish it from any other such authority.
 135    In this standard, that identifier MUST be an object identifier.
 136
 137    A permanent identifier may be useful in three contexts: access
 138    control, non-repudiation and audit records.
 139
 140       For access control, the permanent identifier may be used in an ACL
 141       (Access Control List) instead of the DN or any other form of name
 142       and would not need to be changed, even if the subject name of the
 143       entity changes.  For non-repudiation, the permanent identifier may
 144       be used to link different transactions to the same entity, even
 145       when the subject name of the entity changes.
 146
 147       For audit records, the permanent identifier may be used to link
 148       different audit records to the same entity, even when the subject
 149       name of the entity changes.
 150
 151    For two certificates which have been both verified to be valid
 152    according to a given validation policy and which contain a permanent
 153    identifier, those certificates relate to the same entity if their
 154    permanent identifiers match, whatever the content of the DN or other
 155    subjectAltName components may be.
 156
 157    Since the use of permanent identifiers may conflict with privacy, CAs
 158    SHOULD advertise to purchasers of certificates the use of permanent
 159    identifiers in certificates.
 160
 161 2.  Definition of a Permanent Identifier
 162
 163    This Permanent Identifier is a name defined as a form of otherName
 164    from the GeneralName structure in SubjectAltName, as defined in
 165    [X.509] and [RFC3280].
 166
 167
 168
 169
 170 Pinkas & Gindin             Standards Track                     [Page 3]
 171 \f
 172 RFC 4043                  Permanent Identifier                  May 2005
 173
 174
 175    A CA which includes a permanent identifier in a certificate is
 176    certifying that any public key certificate containing the same values
 177    for that identifier refers to the same entity.
 178
 179    The use of a permanent identifier is OPTIONAL.  The permanent
 180    identifier is defined as follows:
 181
 182       id-on-permanentIdentifier   OBJECT IDENTIFIER ::= { id-on 3 }
 183         PermanentIdentifier ::=     SEQUENCE {
 184            identifierValue    UTF8String             OPTIONAL,
 185                            -- if absent, use a serialNumber attribute,
 186                            -- if there is such an attribute present
 187                            -- in the subject DN
 188            assigner           OBJECT IDENTIFIER      OPTIONAL
 189                            -- if absent, the assigner is
 190                            -- the certificate issuer
 191    }
 192
 193    The identifierValue field is optional.
 194
 195       When the identifierValue field is present, then the
 196       identifierValue supports one syntax: UTF8String.
 197
 198       When the identifierValue field is absent, then the value of the
 199       serialNumber attribute (as defined in section 5.2.9 of [X.520])
 200       from the deepest RDN of the subject DN is the value to be taken
 201       for the identifierValue.  In such a case, there MUST be at least
 202       one serialNumber attribute in the subject DN, otherwise the
 203       PermanentIdentifier SHALL NOT be used.
 204
 205    The assigner field is optional.
 206
 207       When the assigner field is present, then it is an OID which
 208       identifies a naming space, i.e., both an Assigner Authority and
 209       the type of that field.  Characteristically, the prefix of the OID
 210       identifies the Assigner Authority, and a suffix is used to
 211       identify the type of permanent identifier.
 212
 213       When the assigner field is absent, then the permanent identifier
 214       is locally unique to the CA.
 215
 216    The various combinations are detailed below:
 217
 218    1. Both the assigner and the identifierValue fields are present:
 219
 220       The identifierValue is the value for that type of identifier.  The
 221       assigner field identifies the Assigner Authority and the type of
 222       permanent identifier being identified.
 223
 224
 225
 226 Pinkas & Gindin             Standards Track                     [Page 4]
 227 \f
 228 RFC 4043                  Permanent Identifier                  May 2005
 229
 230
 231       The permanent identifier is globally unique among all CAs.  In
 232       such a case, two permanent identifiers of this type match if and
 233       only if their assigner fields match and the contents of the
 234       identifierValue field in the two permanent identifiers consist of
 235       the same Unicode code points presented in the same order.
 236
 237    2. The assigner field is absent and the identifierValue field is
 238       present:
 239
 240       The Assigner Authority is the CA that has issued the certificate.
 241       The identifierValue is given by the CA and the permanent
 242       identifier is only local to the CA that has issued the
 243       certificate.
 244
 245       In such a case, two permanent identifiers of this type match if
 246       and only if the issuer DN's in the certificates which contain them
 247       match using the distinguishedNameMatch rule, as defined in X.501,
 248       and the two values of the identifierValue field consist of the
 249       same Unicode code points presented in the same order.
 250
 251    3. Both the assigner and the identifierValue fields are absent:
 252
 253       If there are one or more RDNs containing a serialNumber attribute
 254       (alone or accompanied by other attributes), then the value
 255       contained in the serialNumber of the deepest such RDN SHALL be
 256       used as the identifierValue; otherwise, the Permanent Identifier
 257       definition is invalid and the Permanent Identifier SHALL NOT be
 258       used.
 259
 260       The permanent identifier is only local to the CA that has issued
 261       the certificate.  In such a case, two permanent identifiers of
 262       this type match if and only if the issuer DN's in the certificates
 263       which contain them match and the serialNumber attributes within
 264       the subject DN's of those same certificates also match using the
 265       caseIgnoreMatch rule.
 266
 267    4. The assigner field is present and the identifierValue field is
 268       absent:
 269
 270       If there are one or more RDNs containing a serialNumber attribute
 271       (alone or accompanied by other attributes), then the value
 272       contained in the serialNumber of the deepest such RDN SHALL be
 273       used as the identifierValue; otherwise, the Permanent Identifier
 274       definition is invalid and the Permanent Identifier SHALL NOT be
 275       used.
 276
 277       The assigner field identifies the Assigner Authority and the type
 278       of permanent identifier being identified.
 279
 280
 281
 282 Pinkas & Gindin             Standards Track                     [Page 5]
 283 \f
 284 RFC 4043                  Permanent Identifier                  May 2005
 285
 286
 287       The permanent identifier is globally unique among all CAs.  In
 288       such a case, two permanent identifiers of this type match if and
 289       only if their assigner fields match and the contents of the
 290       serialNumber attributes within the subject DN's of those same
 291       certificates match using the caseIgnoreMatch rule.
 292
 293    Note: The full arc of the object identifier used to identify the
 294          permanent identifier name form is derived using:
 295
 296       id-pkix OBJECT IDENTIFIER ::= { iso(1) identified-organization(3)
 297          dod(6) internet(1) security(5) mechanisms(5) pkix(7) }
 298
 299       id-on OBJECT IDENTIFIER ::= { id-pkix 8 }   -- other name forms
 300
 301 3.  IANA Considerations
 302
 303    No IANA actions are necessary.  However, a Private Enterprise Number
 304    may be used to construct an OID for the assigner field (see Annex
 305    B.1.).
 306
 307 4.  Security Considerations
 308
 309    A given entity may have at an instant of time or at different
 310    instants of time multiple forms of identities.  If the permanent
 311    identifier is locally unique to the CA (i.e., the assigner field is
 312    not present), then two certificates from the same CA can be compared.
 313
 314    When two certificates contain identical permanent identifiers, then a
 315    relying party may determine that they refer to the same entity.
 316
 317    If the permanent identifier is globally unique among all CAs (i.e.,
 318    the assigner field is present), then two certificates from different
 319    CAs can be compared.  When they contain two identical permanent
 320    identifiers, then a relying party may determine that they refer to
 321    the same entity.  It is the responsibility of the CA to verify that
 322    the permanent identifier being included in the certificate refers to
 323    the subject being certified.
 324
 325    The permanent identifier identifies the entity, irrespective of any
 326    attribute extension.  When a public key certificate contains
 327    attribute extensions, the permanent identifier, if present, should
 328    not be used for access control purposes but only for audit purposes.
 329    The reason is that since these attributes may change, access could be
 330    granted on attributes that were originally present in a certificate
 331    issued to that entity but are no longer present in the current
 332    certificate.
 333
 334
 335
 336
 337
 338 Pinkas & Gindin             Standards Track                     [Page 6]
 339 \f
 340 RFC 4043                  Permanent Identifier                  May 2005
 341
 342
 343    Subject names in certificates are chosen by the issuing CA and are
 344    mandated to be unique for each CA; so there can be no name collision
 345    between subject names from the same CA.  Such a name may be an end-
 346    entity name when the certificate is a leaf certificate, or a CA name,
 347    when it is a CA certificate.
 348
 349    Since a name is only unique towards its superior CA, unless some
 350    naming constraints are being used, a name would only be guaranteed to
 351    be globally unique when considered to include a sequence of all the
 352    names of the superior CAs.  Thus, two certificates that are issued
 353    under the same issuer DN and which contain the same permanent
 354    identifier extension without an assigner field do not necessarily
 355    refer to the same entity.
 356
 357    Additional checks need to be done, e.g., to check if the public key
 358    values of the two CAs which have issued the certificates to be
 359    compared are identical or if the sequence of CA names in the
 360    certification path from the trust anchor to the CA are identical.
 361
 362    When the above checks fail, the permanent identifiers may still match
 363    if there has been a CA key rollover.  In such a case the checking is
 364    more complicated.
 365
 366    The certification of different CAs with the same DN by different CAs
 367    has other negative consequences in various parts of the PKI, notably
 368    rendering the IssuerAndSerialNumber structure in [RFC3852] section
 369    10.2.4 ambiguous.
 370
 371    The permanent identifier allows organizations to create links between
 372    different certificates associated with an entity issued with or
 373    without overlapping validity periods.  This ability to link different
 374    certificates may conflict with privacy.  It is therefore important
 375    that a CA clearly disclose any plans to issue certificates which
 376    include a permanent identifier to potential subjects of those
 377    certificates.
 378
 379 5.  References
 380
 381 5.1.  Normative References
 382
 383    [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
 384               Requirement Levels", BCP 14, RFC 2119, March 1997.
 385
 386    [RFC3280]  Housley, R., Polk, W., Ford, W., and D. Solo, "Internet
 387               X.509 Public Key Infrastructure Certificate and
 388               Certificate Revocation List (CRL) Profile", RFC 3280,
 389               April 2002.
 390
 391
 392
 393
 394 Pinkas & Gindin             Standards Track                     [Page 7]
 395 \f
 396 RFC 4043                  Permanent Identifier                  May 2005
 397
 398
 399    [UTF-8]    Yergeau, F., "UTF-8, a transformation format of ISO
 400               10646", STD 63, RFC 3629, November 2003.
 401
 402    [X.501]    ITU-T Rec X.501 | ISO 9594-2: 2001: Information technology
 403               - Open Systems Interconnection - The Directory: Models,
 404               February 2001.
 405
 406 5.2.  Informative References
 407
 408    [RFC3852]  Housley, R., "Cryptographic Message Syntax (CMS)", RFC
 409               3852, July 2004.
 410
 411    [X.509]    ITU-T Recommendation X.509 (1997 E): Information
 412               Technology - Open Systems Interconnection - The Directory:
 413               Authentication Framework, June 1997.
 414
 415    [X.520]    ITU-T Recommendation X.520: Information Technology - Open
 416               Systems Interconnection - The Directory: Selected
 417               Attribute Types, June 1997.
 418
 419    [X.660]    ITU-T Recommendation X.660: Information Technology - Open
 420               Systems Interconnection - Procedures for the Operation of
 421               OSI Registration Authorities: General Procedures, 1992.
 422
 423    [X.680]    ITU-T Recommendation X.680: Information Technology -
 424               Abstract Syntax Notation One, 1997.
 425
 426
 427
 428
 429
 430
 431
 432
 433
 434
 435
 436
 437
 438
 439
 440
 441
 442
 443
 444
 445
 446
 447
 448
 449
 450 Pinkas & Gindin             Standards Track                     [Page 8]
 451 \f
 452 RFC 4043                  Permanent Identifier                  May 2005
 453
 454
 455 Appendix A.  ASN.1 Syntax
 456
 457    As in RFC 2459, ASN.1 modules are supplied in two different variants
 458    of the ASN.1 syntax.
 459
 460    This section describes data objects used by conforming PKI components
 461    in an "ASN.1-like" syntax.  This syntax is a hybrid of the 1988 and
 462    1993 ASN.1 syntaxes.  The 1988 ASN.1 syntax is augmented with 1993
 463    the UNIVERSAL Type UTF8String.
 464
 465    The ASN.1 syntax does not permit the inclusion of type statements in
 466    the ASN.1 module, and the 1993 ASN.1 standard does not permit use of
 467    the new UNIVERSAL types in modules using the 1988 syntax.  As a
 468    result, this module does not conform to either version of the ASN.1
 469    standard.
 470
 471    Appendix A.1 may be parsed by an 1988 ASN.1-parser by replacing the
 472    definitions for the UNIVERSAL Types with the 1988 catch-all "ANY".
 473
 474    Appendix A.2 may be parsed "as is" by an 1997-compliant ASN.1 parser.
 475
 476    In case of discrepancies between these modules, the 1988 module is
 477    the normative one.
 478
 479 Appendix A.1.  1988 ASN.1 Module
 480
 481   PKIXpermanentidentifier88 {iso(1) identified-organization(3) dod(6)
 482          internet(1) security(5) mechanisms(5) pkix(7) id-mod(0)
 483          id-mod-perm-id-88(28) }
 484
 485   DEFINITIONS EXPLICIT TAGS ::=
 486
 487      BEGIN
 488
 489      -- EXPORTS ALL --
 490
 491      IMPORTS
 492
 493   -- UTF8String, / move hyphens before slash if UTF8String does not
 494   -- resolve with your compiler
 495   -- The content of this type conforms to [UTF-8].
 496
 497           id-pkix
 498                 FROM PKIX1Explicit88 { iso(1) identified-organization(3)
 499                 dod(6) internet(1) security(5) mechanisms(5) pkix(7)
 500                 id-mod(0) id-pkix1-explicit(18) } ;
 501                 -- from [RFC3280]
 502
 503
 504
 505
 506 Pinkas & Gindin             Standards Track                     [Page 9]
 507 \f
 508 RFC 4043                  Permanent Identifier                  May 2005
 509
 510
 511      -- Permanent identifier Object Identifier and Syntax
 512
 513      id-on   OBJECT IDENTIFIER ::= { id-pkix 8 }
 514
 515      id-on-permanentIdentifier   OBJECT IDENTIFIER ::= { id-on 3 }
 516
 517      PermanentIdentifier ::= SEQUENCE {
 518           identifierValue    UTF8String             OPTIONAL,
 519                           -- if absent, use the serialNumber attribute
 520                           -- if there is a single such attribute present
 521                           -- in the subject DN
 522           assigner           OBJECT IDENTIFIER      OPTIONAL
 523                           -- if absent, the assigner is
 524                           -- the certificate issuer
 525   }
 526
 527   END
 528
 529 Appendix A.2.  1993 ASN.1 Module
 530
 531 PKIXpermanentidentifier93 {iso(1) identified-organization(3) dod(6)
 532        internet(1) security(5) mechanisms(5) pkix(7) id-mod(0)
 533        id-mod-perm-id-93(29) }
 534
 535    DEFINITIONS EXPLICIT TAGS ::=
 536
 537    BEGIN
 538
 539    -- EXPORTS ALL --
 540
 541    IMPORTS
 542
 543         id-pkix
 544               FROM PKIX1Explicit88 { iso(1) identified-organization(3)
 545               dod(6) internet(1) security(5) mechanisms(5) pkix(7)
 546               id-mod(0) id-pkix1-explicit(18) }
 547                -- from [RFC3280]
 548
 549         ATTRIBUTE
 550               FROM InformationFramework {joint-iso-itu-t ds(5) module(1)
 551               informationFramework(1) 4};
 552                -- from [X.501]
 553
 554    -- Permanent identifier Object Identifiers
 555
 556    id-on   OBJECT IDENTIFIER ::= { id-pkix 8 }
 557
 558    id-on-permanentIdentifier   OBJECT IDENTIFIER ::= { id-on 3 }
 559
 560
 561
 562 Pinkas & Gindin             Standards Track                    [Page 10]
 563 \f
 564 RFC 4043                  Permanent Identifier                  May 2005
 565
 566
 567    -- Permanent Identifier
 568
 569    permanentIdentifier ATTRIBUTE ::= {
 570           WITH SYNTAX     PermanentIdentifier
 571           ID              id-on-permanentIdentifier }
 572
 573    PermanentIdentifier ::= SEQUENCE {
 574         identifierValue    UTF8String             OPTIONAL,
 575                         -- if absent, use the serialNumber attribute
 576                         -- if there is a single such attribute present
 577                         -- in the subject DN
 578         assigner           OBJECT IDENTIFIER      OPTIONAL
 579                         -- if absent, the assigner is
 580                         -- the certificate issuer
 581 }
 582
 583 END
 584
 585 Appendix B.  OID's for Organizations
 586
 587    In order to construct an OID for the assigner field, organizations
 588    need first to have a registered OID for themselves.  Such an OID must
 589    be obtained from a registration authority following [X.660].  In some
 590    cases, OID's are provided for free.  In other cases a one-time fee is
 591    required.  The main difference lies in the nature of the information
 592    that is collected at the time of registration and how this
 593    information is verified for its accuracy.
 594
 595 Appendix B.1.  Using IANA (Internet Assigned Numbers Authority)
 596
 597    The application form for a Private Enterprise Number in the IANA's
 598    OID list is: http://www.iana.org/cgi-bin/enterprise.pl.
 599
 600    Currently, IANA assigns numbers for free.  The IANA-registered
 601    Private Enterprises prefix is:
 602    iso.org.dod.internet.private.enterprise (1.3.6.1.4.1)
 603
 604    These numbers are used, among other things, for defining private SNMP
 605    MIBs.
 606
 607    The official assignments under this OID are stored in the IANA file
 608    "enterprise-numbers" available at:
 609    http://www.iana.org/assignments/enterprise-numbers
 610
 611
 612
 613
 614
 615
 616
 617
 618 Pinkas & Gindin             Standards Track                    [Page 11]
 619 \f
 620 RFC 4043                  Permanent Identifier                  May 2005
 621
 622
 623 Appendix B.2.  Using an ISO Member Body
 624
 625    ISO has defined the OID structure in a such a way so that every ISO
 626    member-body has its own unique OID.  Then every ISO member-body is
 627    free to allocate its own arc space below.
 628
 629    Organizations and enterprises may contact the ISO member-body where
 630    their organization or enterprise is established to obtain an
 631    organization/enterprise OID.
 632
 633    Currently, ISO members do not assign organization/enterprise OID's
 634    for free.
 635
 636    Most of them do not publish registries of such OID's which they have
 637    assigned, sometimes restricting the access to registered
 638    organizations or preferring to charge inquirers for the assignee of
 639    an OID on a per-inquiry basis.  The use of OID's from an ISO member
 640    organization which does not publish such a registry may impose extra
 641    costs on the CA that needs to make sure that the OID corresponds to
 642    the registered organization.
 643
 644    As an example, AFNOR (Association Francaise de Normalisation - the
 645    French organization that is a member of ISO) has defined an arc to
 646    allocate OID's for companies:
 647
 648    {iso (1) member-body (2) fr (250) type-org (1) organisation (n)}
 649
 650 Appendix B.3.  Using an ICD (International Code Designator) From British
 651                Standards Institution to Specify a New or an Existing
 652                Identification Scheme
 653
 654    The International Code Designator (ICD) is used to uniquely identify
 655    an ISO 6523 compliant organization identification scheme.  ISO 6523
 656    is a standard that defines the proper structure of an identifier and
 657    the registration procedure for an ICD.  The conjunction of the ICD
 658    with an identifier issued by the registration authority is worldwide
 659    unique.
 660
 661    The basic structure of the code contains the following components:
 662
 663    -  the ICD value: The International Code Designator issued to the
 664       identification scheme makes the identifier worldwide unique (up to
 665       4 digits),
 666
 667    -  the Organization, usually a company or governmental body (up to 35
 668       characters),
 669
 670
 671
 672
 673
 674 Pinkas & Gindin             Standards Track                    [Page 12]
 675 \f
 676 RFC 4043                  Permanent Identifier                  May 2005
 677
 678
 679    -  an Organization Part (OPI - Organization Part Identifier).  An
 680       identifier allocated to a particular Organization Part (optional,
 681       up to 35 characters)
 682
 683    The ICD is also equivalent to an object identifier (OID) under the
 684    arc {1(iso).  3(identified organization)}.
 685
 686    On behalf of ISO, British Standards Institution (BSI) is the
 687    Registration Authority for organizations under the arc {iso (1)
 688    org(3)}.  This means BSI registers code issuing authorities
 689    (organizations) by ICD values which are equivalent to OIDs of the
 690    form {iso (1) org(3) icd(xxxx)}.  The corresponding IdentifierValue
 691    is the code value of the scheme identified by icd(xxxx).
 692
 693    As an example, the ICD 0012 was allocated to European Computer
 694    Manufacturers Association: ECMA.  Thus the OID for ECMA is {iso(1)
 695    org(3) ecma(12)}.
 696
 697    For registration with BSI, a "Sponsoring Authority" has to vouch for
 698    the Applying organization.  Registration is not free.  Recognized
 699    "Sponsoring Authorities" are: ISO Technical Committees or
 700    (Sub)Committees, Member Bodies of ISO or International Organizations
 701    having a liaison status with ISO or with any of its Technical
 702    (Sub)Committees.
 703
 704    An example of a Sponsoring Authority is the EDIRA Association (EDI/EC
 705    Registration Authority, web: http://www.edira.org,
 706    email:info@edira.org).
 707
 708    The numerical list of all ICDs that have been issued is posted on its
 709    webpage: http://www.edira.org/documents.htm#icd-List
 710
 711    Note: IANA owns ICD code 0090, but (presumably) it isn't intending to
 712    use it for the present purpose.
 713
 714
 715
 716
 717
 718
 719
 720
 721
 722
 723
 724
 725
 726
 727
 728
 729
 730 Pinkas & Gindin             Standards Track                    [Page 13]
 731 \f
 732 RFC 4043                  Permanent Identifier                  May 2005
 733
 734
 735 Authors' Addresses
 736
 737    Denis Pinkas
 738    Bull
 739    Rue Jean-Jaures BP 68
 740    78340 Les Clayes-sous-Bois
 741    FRANCE
 742
 743    EMail: Denis.Pinkas@bull.net
 744
 745
 746    Thomas Gindin
 747    IBM Corporation
 748    6710 Rockledge Drive
 749    Bethesda, MD 20817
 750    USA
 751
 752    EMail: tgindin@us.ibm.com
 753
 754
 755
 756
 757
 758
 759
 760
 761
 762
 763
 764
 765
 766
 767
 768
 769
 770
 771
 772
 773
 774
 775
 776
 777
 778
 779
 780
 781
 782
 783
 784
 785
 786 Pinkas & Gindin             Standards Track                    [Page 14]
 787 \f
 788 RFC 4043                  Permanent Identifier                  May 2005
 789
 790
 791 Full Copyright Statement
 792
 793    Copyright (C) The Internet Society (2005).
 794
 795    This document is subject to the rights, licenses and restrictions
 796    contained in BCP 78, and except as set forth therein, the authors
 797    retain all their rights.
 798
 799    This document and the information contained herein are provided on an
 800    "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
 801    OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
 802    ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
 803    INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
 804    INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
 805    WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
 806
 807 Intellectual Property
 808
 809    The IETF takes no position regarding the validity or scope of any
 810    Intellectual Property Rights or other rights that might be claimed to
 811    pertain to the implementation or use of the technology described in
 812    this document or the extent to which any license under such rights
 813    might or might not be available; nor does it represent that it has
 814    made any independent effort to identify any such rights.  Information
 815    on the procedures with respect to rights in RFC documents can be
 816    found in BCP 78 and BCP 79.
 817
 818    Copies of IPR disclosures made to the IETF Secretariat and any
 819    assurances of licenses to be made available, or the result of an
 820    attempt made to obtain a general license or permission for the use of
 821    such proprietary rights by implementers or users of this
 822    specification can be obtained from the IETF on-line IPR repository at
 823    http://www.ietf.org/ipr.
 824
 825    The IETF invites any interested party to bring to its attention any
 826    copyrights, patents or patent applications, or other proprietary
 827    rights that may cover technology that may be required to implement
 828    this standard.  Please address the information to the IETF at ietf-
 829    ipr@ietf.org.
 830
 831 Acknowledgement
 832
 833    Funding for the RFC Editor function is currently provided by the
 834    Internet Society.
 835
 836
 837
 838
 839
 840
 841
 842 Pinkas & Gindin             Standards Track                    [Page 15]
 843 \f