Internet X.509 Public Key Infrastructure Permanent Identifier
RFC 4043
Document | Type |
RFC - Proposed Standard
(May 2005; Errata)
Was draft-ietf-pkix-pi (pkix WG)
|
|
---|---|---|---|
Last updated | 2015-10-14 | ||
Stream | IETF | ||
Formats | plain text pdf html bibtex | ||
Stream | WG state | (None) | |
Document shepherd | No shepherd assigned | ||
IESG | IESG state | RFC 4043 (Proposed Standard) | |
Consensus Boilerplate | Unknown | ||
Telechat date | |||
Responsible AD | Russ Housley | ||
Send notices to | <wpolk@nist.gov> |
Network Working Group D. Pinkas Request for Comments: 4043 Bull Category: Standards Track T. Gindin IBM May 2005 Internet X.509 Public Key Infrastructure Permanent Identifier Status of This Memo This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. Copyright Notice Copyright (C) The Internet Society (2005). Abstract This document defines a new form of name, called permanent identifier, that may be included in the subjectAltName extension of a public key certificate issued to an entity. The permanent identifier is an optional feature that may be used by a CA to indicate that two or more certificates relate to the same entity, even if they contain different subject name (DNs) or different names in the subjectAltName extension, or if the name or the affiliation of that entity stored in the subject or another name form in the subjectAltName extension has changed. The subject name, carried in the subject field, is only unique for each subject entity certified by the one CA as defined by the issuer name field. However, the new name form can carry a name that is unique for each subject entity certified by a CA. Pinkas & Gindin Standards Track [Page 1] RFC 4043 Permanent Identifier May 2005 Table of Contents 1. Introduction.................................................. 2 2. Definition of a Permanent Identifier.......................... 3 3. IANA Considerations........................................... 6 4. Security Considerations....................................... 6 5. References.................................................... 7 5.1. Normative References.................................... 7 5.2. Informative References.................................. 8 Appendix A. ASN.1 Syntax.......................................... 9 A.1. 1988 ASN.1 Module....................................... 9 A.2. 1993 ASN.1 Module....................................... 10 Appendix B. OID's for organizations............................... 11 B.1. Using IANA (Internet Assigned Numbers Authority)........ 11 B.2. Using an ISO Member Body................................ 12 B.3. Using an ICD (International Code Designator) From British Standards Institution to Specify a New or an Existing Identification Scheme....................... 12 Authors' Addresses................................................ 14 Full Copyright Statement.......................................... 15 1. Introduction The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. This specification is based on [RFC3280], which defines underlying certificate formats and semantics needed for a full implementation of this standard. The subject field of a public key certificate identifies the entity associated with the public key stored in the subject public key field. Names and identities of a subject may be carried in the subject field and/or the subjectAltName extension. Where subject field is non-empty, it MUST contain an X.500 distinguished name (DN). The DN MUST be unique for each subject entity certified by a single CA as defined by the issuer name field. The subject name changes whenever any of the components of that name gets changed. There are several reasons for such a change to happen. For employees of a company or organization, the person may get a different position within the same company and thus will move from one organization unit to another one. Including the organization unit in the name may however be very useful to allow the relying parties (RP's) using that certificate to identify the right individual. Pinkas & Gindin Standards Track [Page 2] RFC 4043 Permanent Identifier May 2005 For citizens, an individual may change their name by legal processes, especially as a result of marriage. Any certificate subject identified by geographical location may relocate and change at least some of the location attributesShow full document text