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]
Show full document text