idnits 2.17.00 (12 Aug 2021) /tmp/idnits63848/draft-ietf-pkix-pi-03.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 are 16 instances of lines with non-ascii characters in the document. == The page length should not exceed 58 lines per page, but there was 8 longer pages, the longest (page 2) being 61 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 9 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There is 1 instance of too long lines in the document, the longest one being 1 character 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 == The "Author's Address" (or "Authors' Addresses") section title is misspelled. == Line 194 has weird spacing: '...g party may d...' -- 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.) -- Couldn't find a document date in the document -- date freshness check skipped. 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 2119' is defined on line 217, but no explicit reference was found in the text == Unused Reference: 'RFC 2459' is defined on line 220, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2459 (Obsoleted by RFC 3280) Summary: 5 errors (**), 0 flaws (~~), 8 warnings (==), 3 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: August, 2002 February, 2002 4 Target category: Standard Track 6 Internet X.509 Public Key Infrastructure 8 Permanent Identifier 10 12 Status of this Memo 14 This document is an Internet-Draft and is in full conformance with 15 all provisions of Section 10 of [RFC 2026]. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that other 19 groups may also distribute working documents as Internet-Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 Copyright (C) The Internet Society (2002). All Rights Reserved. 34 Abstract 36 This document define a new form of name, called permanent 37 identifier, that may be included in the subjectAltName extension 38 of a public key certificate issued to an entity. 40 The permanent identifier is an optional feature that may be used 41 by a CA to indicate that the certificate relates to the same 42 entity even if the name or the affiliation of that entity has 43 changed. 45 The subject name when carried in the subject field is only unique 46 for each subject entity certified by the one CA as defined by the 47 issuer name field. This new form of name also can carry a 48 name that is unique for each subject entity certified by any CA. 50 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 51 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 52 document are to be interpreted as described in RFC 2119. 54 Please send comments on this document to the ietf-pkix@imc.org 55 mailing list. 57 Permanent Identifier Document Expiration: August 2002 59 1 Introduction 61 This specification is one part of a family of standards for the 62 X.509 Public Key Infrastructure (PKI) for the Internet. It is based 63 on RFC 2459, which defines underlying certificate formats and 64 semantics needed for a full implementation of this standard. 66 The subject field of a public key certificate identifies the entity 67 associated with the public key stored in the subject public key 68 field. Names and identities of a subject may be carried in the 69 subject field and/or the subjectAltName extension. Where it is 70 non-empty, the subject field MUST contain an X.500 distinguished 71 name (DN). The DN MUST be unique for each subject entity certified 72 by a single CA as defined by the issuer name field. 74 The subject name changes whenever any of the components of that 75 name gets changed. There are several reasons for such a change to 76 happen. 78 For employees of a company or organization, the person may get 79 a different position within the same company and thus will 80 move from one organization unit to another one. Including the 81 organization unit in the name may however be very useful to 82 allow the relying parties (RPÆs) using that certificate to 83 identify the right individual. 85 For citizens, an individual may change their name by legal 86 processes, especially women as a result of marriage. 88 Any certificate subject identified by geographical location may 89 relocate and change at least some of the location attributes 91 (e.g. country name, state or province, locality, or street). 93 A permanent identifier may be useful both in the context of access 94 control and of non repudiation. 96 For access control, the permanent identifier may be used in 97 an ACL (Access Control List) instead of the DN or any other 98 form of name and would not need to be changed, even if the 99 subject name of the entity changes. 101 For non-repudiation, the permanent identifier may be used to 102 link different transactions to the same entity, even when 103 the subject name of the entity changes. 105 When two certificates from the same CA contain the same permanent 106 identifier value, then these certificates relate to the same 107 entity, whatever the content of the DN or other subjectAltName 108 components may be. 110 When two certificates from different CAÆs contain both the same 111 permanent identifier value and the same type of permanent 112 identifier from a given Assigner Authority, then these 114 Permanent Identifier Document Expiration: August 2002 116 certificates relate to the same entity, whatever the content of 117 the DN or other subjectAltName components may be. 119 2. Definition of a Permanent Identifier 121 A CA which includes a permanent identifier in a certificate is 122 certifying that any public key certificate containing that 123 identifier refers to the same entity, whatever the content of 124 the DN or other subjectAltName components may be. 126 The use of a permanent identifier is optional. This name is 127 defined as a form of otherName from the GeneralName structure in 128 SubjectAltName. The permanent identifier is defined as follows: 130 id-on-permanentIdentifier AttributeType ::= { id-on 2 } 132 PermanentIdentifier ::= SEQUENCE { 133 identifierValue IdentifierValue, 134 identifierType IdentifierType OPTIONAL 135 } 137 IdentifierValue ::= CHOICE { 138 iA5String IA5String, 139 uTF8String UTF8String 140 } 142 IdentifierType ::= CHOICE { 143 registeredOID OBJECT IDENTIFIER, 144 uniformResourceIdentifier IA5String, 145 intluniformResourceIdentifier UTF8String 146 } 148 The IdentifierType field, when present, identifies both the 149 organization responsible for assigning the content of the 150 identifier field and the type of that field. 152 When the IdentifierType field is missing, then it is assumed that 153 the organization responsible for assigning the content of the 154 identifier field is the CA itself and that there is only one type 155 of such identifier for the CA. 157 Two forms of values are supported for the IdentifierValue: 158 IA5String or UTF8String. 160 The IdentifierType field may contain a registeredOID in the form of : 162 a) an Object Identifier (i.e. an OID), or 163 b) a permanent URI using IA5String, or 164 c) a permanent URI using UTF8String. 166 Characteristically, when an OID is used, the prefix of the OID 167 identifies the organization, and a suffix is used to identify the 168 type of permanent identifier being identified. Essentially the 169 same thing is true of URIÆs. 171 Permanent Identifier Document Expiration: August 2002 173 If identifierType is missing, then the permanent identifier is 174 locally unique to the CA. 176 If identifierType is present, then the permanent identifier is 177 globally unique among all CAÆs. 179 Note: the full arc of the object identifier is derived using: 181 id-pkix OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) 182 dod(6) internet(1) security(5) mechanisms(5) pkix(7) } 184 id-on OBJECT IDENTIFIER ::= { id-pkix 8 } -- other name forms 186 3. Security considerations 188 A given entity may have at an instant of time or at different 189 instants of time multiple forms of identities. 191 If the permanent identifier is locally unique to the CA (i.e. 192 identifierType is not present), then two certificates from the 193 same CA can be compared. When they contain two identical permanent 194 identifiers, then a relying party may determine that they refer to 195 the same entity. 197 If the permanent identifier is globally unique among all CAÆs (i.e. 198 identifierType is present), then two certificates from different 199 CAÆs can be compared. When they contain two identical permanent 200 identifiers, then a relying party may determine that they refer to 201 the same entity. 203 The permanent identifier identifies the entity, irrespective of any 204 attribute extension. When a public key certificate contains 205 attribute extensions, the permanent identifier, if present, should 206 not be used for access control purposes but only for audit purposes. 207 The reason is that since these attributes may change, access could 208 be granted on attributes that were originally present in a 209 certificate issued to that entity but are no more present in the 210 current certificate. 212 4. References 214 [RFC 2026] S. Bradner, ôThe Internet Standards Process û 215 Revision 3 ©, November 1996. 217 [RFC 2119] S. Bradner, "Key words for use in RFCs to Indicate 218 Requirement Levels", March 1997. 220 [RFC 2459] R. Housley, W. Ford, W. Polk, and D. Solo, "Internet X.509 221 Public Key Infrastructure: Certificate and CRL Profile", January 222 1999. 224 [X.501] ITU-T Recommendation X.501 (1997 E): Information Technology 225 - Open Systems Interconnection - The Directory: Models, June 1997. 227 Permanent Identifier Document Expiration: August 2002 229 [X.509] ITU-T Recommendation X.509 (1997 E): Information Technology 230 - Open Systems Interconnection - The Directory: Authentication 231 Framework, June 1997. 233 [X.520] ITU-T Recommendation X.520: Information Technology - Open 234 Systems Interconnection - The Directory: Selected Attribute Types, 235 June 1997. 237 [X.660] ITU-T Recommendation X.660: Information Technology - 238 Open Systems Interconnection û Procedures for the Operation of 239 OSI Registration Authorities: General Procedures, 1992. 241 [X.680] ITU-T Recommendation X.680: Information Technology - 242 Abstract Syntax Notation One, 1997. 244 5. AuthorÆs Addresses 246 Denis Pinkas 247 Bull, 248 68, Route de Versailles 249 78434 Louveciennes Cedex 250 FRANCE 251 Email: Denis.Pinkas@bull.net 253 Thomas Gindin 254 IBM Corporation 255 6710 Rockledge Drive 256 Bethesda, MD 20817 257 USA 258 Email: tgindin@us.ibm.com 260 6 Intellectual Property Rights 262 The IETF takes no position regarding the validity or scope of any 263 intellectual property or other rights that might be claimed to 264 pertain to the implementation or use of the technology described in 265 this document or the extent to which any license under such rights 266 might or might not be available; neither does it represent that it 267 has made any effort to identify any such rights. Information on the 268 IETF's procedures with respect to rights in standards-track and 269 standards related documentation can be found in BCP-11. Copies of 270 claims of rights made available for publication and any assurances of 271 licenses to be made available, or the result of an attempt made to 272 obtain a general license or permission for the use of such proprietary 273 rights by implementors or users of this specification can be obtained 274 from the IETF Secretariat. 276 The IETF invites any interested party to bring to its attention any 277 copyrights, patents or patent applications, or other proprietary 278 rights which may cover technology that may be required to practice 279 this standard. Please address the information to the IETF Executive 280 Director. 282 Permanent Identifier Document Expiration: August 2002 284 APPENDIX 286 ASN.1 definitions 288 A.1. 1988 ASN.1 Module 290 PKIXpermanentidentifier88 {iso(1) identified-organization(3) dod(6) 291 internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) 292 id-mod-permanent-identifier-88(14) } 294 DEFINITIONS EXPLICIT TAGS ::= 296 BEGIN 298 -- EXPORTS ALL -- 300 IMPORTS 302 id-pkix, AttributeType, 303 FROM PKIX1Explicit88 {iso(1) identified-organization(3) 304 dod(6) internet(1) security(5) mechanisms(5) pkix(7) 305 id-mod(0) id-pkix1-explicit-88(1)} 307 -- Object Identifiers 309 -- Externally defined OIDs 311 -- Arc for other name forms 312 id-on OBJECT IDENTIFIER ::= { id-pkix 8 } 314 -- permanent identifier 316 id-on-permanentIdentifier AttributeType ::= { id-on 2 } 318 PermanentIdentifier ::= SEQUENCE { 319 identifierValue IdentifierValue, 320 identifierType IdentifierType OPTIONAL 321 } 323 IdentifierValue ::= CHOICE { 324 iA5String IA5String, 325 uTF8String UTF8String 326 } 328 IdentifierType ::= CHOICE { 329 registeredOID OBJECT IDENTIFIER, 330 uniformResourceIdentifier IA5String, 331 intluniformResourceIdentifier UTF8String 332 } 334 END 336 Permanent Identifier Document Expiration: August 2002 338 A.2. 1993 ASN.1 Module 340 PKIXpermanentidentifier93 {iso(1) identified-organization(3) dod(6) 341 internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) 342 id-mod-permanent-identifier-93(15) } 344 DEFINITIONS EXPLICIT TAGS ::= 346 BEGIN 348 -- EXPORTS ALL -- 350 IMPORTS 352 id-pkix, ATTRIBUTE 353 FROM PKIX1Explicit93 {iso(1) identified-organization(3) dod(6) 354 internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) 355 id-pkix1-explicit-93(3)}; 357 -- Object Identifiers 359 -- Externally defined OIDs 361 -- Arc for other name forms 362 id-on OBJECT IDENTIFIER ::= { id-pkix 8 } 364 -- Locally defined OIDs 366 id-on-permanentIdentifier OBJECT IDENTIFIER ::= { id-on 2 } 368 -- permanent identifier 370 permanentIdentifier ATTRIBUTE ::= { 371 WITH SYNTAX PermanentIdentifier, 372 ID id-on-permanentIdentifier } 374 PermanentIdentifier ::= SEQUENCE { 375 identifierValue IdentifierValue, 376 identifierType IdentifierType OPTIONAL 377 } 379 IdentifierValue ::= CHOICE { 380 iA5String IA5String, 381 uTF8String UTF8String 382 } 384 IdentifierType ::= CHOICE { 385 registeredOID OBJECT IDENTIFIER, 386 uniformResourceIdentifier IA5String, 387 intluniformResourceIdentifier UTF8String 388 } 390 END 392 Permanent Identifier Document Expiration: August 2002 394 B. OIDÆs for organizations 396 In order to obtain an OID for an identifier type, organizations need 397 first to have a registered OID for themselves (or must use a permanent 398 URI). In some cases, OIDÆs are provided for free. In other cases a 399 one-time fee is required. The main difference lies in the nature of 400 the information that is collected at the time of registration and how 401 this information is verified for its accuracy. 403 B.1. Using IANA (Internet Assigned Numbers Authority) 405 The application form for a Private Enterprise Number in the IANA's 406 OID list is: http://www.iana.org/cgi-bin/enterprise.pl. 408 Currently IANA assigns numbers for free. The IANA-registered Private 409 Enterprises prefix is: iso.org.dod.internet.private.enterprise 410 (1.3.6.1.4.1) 412 These numbers are used, among other things, for defining private 413 SNMP MIBs. 415 The official assignments under this OID are stored in the IANA file 416 "enterprise-numbers" available at: 417 ftp://ftp.isi.edu/in-notes/iana/assignments/enterprise-numbers 419 B.2. Using an ISO member body 421 ISO has defined the OID structure in a such a way so that every ISO 422 member-body has its own unique OID. Then every ISO member-body is free 423 to allocate its own arc space below. 425 Organizations and enterprises may contact the ISO member-body where 426 their organization or enterprise is established to obtain an 427 organization/enterprise OID. 429 Currently, ISO members do not assign organization/enterprise OIDÆs for 430 free. 432 Most of them do not publish registries of such OIDÆs which they have 433 assigned, sometimes restricting the access to registered organizations 434 or preferring to charge inquirers for the assignee of an OID on a 435 per-inquiry basis. The use of OIDÆs from an ISO member organization 436 which does not publish such a registry may impose extra costs on the 437 CA that needs to make sure that the OID corresponds to the registered 438 organization. 440 As an example, AFNOR (Association Francaise de Normalisation - the 441 French organization that is a member of ISO) has defined an arc to 442 allocate OIDÆs for companies: 444 {iso (1) member-body (2) fr (250) type-org (1) organisation (n)} 446 Permanent Identifier Document Expiration: August 2002 448 C. Full Copyright Statement 450 Copyright (C) The Internet Society (2002). All Rights Reserved. 452 This document and translations of it may be copied and furnished to 453 others, and derivative works that comment on or otherwise explain it 454 or assist in its implementation may be prepared, copied, published 455 and distributed, in whole or in part, without restriction of any 456 kind, provided that the above copyright notice and this paragraph are 457 included on all such copies and derivative works. In addition, the 458 ASN.1 modules presented in Appendices A and B may be used in whole or 459 in part without inclusion of the copyright notice. However, this 460 document itself may not be modified in any way, such as by removing 461 the copyright notice or references to the Internet Society or other 462 Internet organizations, except as needed for the purpose of 463 developing Internet standards in which case the procedures for 464 copyrights defined in the Internet Standards process shall be 465 followed, or as required to translate it into languages other than 466 English. 468 The limited permissions granted above are perpetual and will not be 469 revoked by the Internet Society or its successors or assigns. This 470 document and the information contained herein is provided on an "AS 471 IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK 472 FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT 473 LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL 474 NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY 475 OR FITNESS FOR A PARTICULAR PURPOSE.