Internet-Draft David Shaw Expires February 2002 Jabberwocky Tech Updates RFC 2440 August 2001 Key Replacement for Revoked Keys in OpenPGP Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract This document specifies a method in OpenPGP to specify a replacement for an expired or revoked key. Table of Contents Status of this Memo 1 Abstract 1 Table of Contents 1 1. Introduction 1 1.1. Terms 2 2. The Replacement Key Subpacket 2 2.1. Format of the Replacement Key Subpacket 2 2.2. Trust and Validation of the Replacement Key 3 2.3. Placement of the Replacement Key Subpacket 3 3. Security Considerations 3 4. References 3 5. Author's Address 3 1. Introduction The OpenPGP message format [RFC2440] defines two ways to invalidate a key. One way is that the key may be explicitly revoked via a revocation signature. OpenPGP also supports the concept of key expiration, a date after which the key should not be used. Shaw [Page 1] Internet-Draft Key Replacement in OpenPGP August 2001 When a key is revoked or expires, very often there is another key that is intended to replace it. This document is to specify the format of a signature subpacket to be optionally included in the revocation signature or in the self-signature for a key that has an expiration date. This subpacket contains a pointer to the key that is to replace the revoked or expired key. 1.1. Terms This document uses the terms "MUST", "SHOULD" and "MAY" as defined in RFC 2119, along with the negated forms of those terms. 2. The Replacement Key Subpacket The replacement key subpacket is a Signature Subpacket as defined in RFC 2440, section 5.2.3.1, and all general signature subpacket considerations from there apply here as well. The value of the signature subpacket type octet for the replacement key subpacket is (insert this later). A preferred key server subpacket (RFC 2440, section 5.2.3.17) may be included in the revocation or self signature to recommend a location and method to fetch the key. The absence of a replacement key subpacket SHOULD NOT be interpreted as meaning that there is no replacement for a revoked or expired key. The replacement key subpacket is only meaningful in a key revocation or self signature. It SHOULD NOT be present in any other sort of signature. 2.1. Format of the Replacement Key Subpacket The format of the replacement key subpacket is 1 octet of version and 1 octet of class, followed by an optional 1 octet of algid, and 20 octets of fingerprint. The version octet MUST be set to zero. The class octet may have the 0x80 bit set, which indicates there is no replacement for this key. If the class octet does not have the 0x80 bit set, the replacement key subpacket also contains the octet for the algorithm ID of the replacement key and 20 octets of fingerprint for the replacement key. All other bits of the class octet are currently undefined and MUST be set to zero. When the 0x80 bit of the class octet is set, this specifies there is no replacement for the revoked or expired key. This is an affirmative statement that the key has not been replaced. If the intent is to state that the replacement key is unknown, then no replacement key subpacket should be included in the revocation signature. Implementations MAY wish to treat this "no replacement" case as identical to an absent replacement key subpacket. Shaw [Page 2] Internet-Draft Key Replacement in OpenPGP August 2001 An implementation that encounters a version octet with a non-zero value MUST disregard that replacement key subpacket. Note that if the critical bit for the replacement key subpacket is set, this may also mean considering the whole signature to be in error (RFC 2440, section 5.2.3.1). 2.2. Trust and Validation of the Replacement Key No unusual trust in the replacement key should be implied by it being designated as the replacement. Implementations SHOULD validate the replacement key as they would any other key. 2.3. Placement of the Replacement Key Subpacket The replacement key subpacket SHOULD be placed in the hashed section of the signature to prevent a possible key substitution attack. If the replacement key subpacket was allowed in the unhashed section of the signature, an attacker could add a bogus replacement key subpacket to an existing revocation or self signature. 3. Security Considerations The replacement key subpacket provides non-sensitive information only. Nevertheless, as noted above, implementations should not trust a replacement key subpacket that is located in the unhashed area of the signature packet. In addition, as this document is an update of RFC 2440, the security considerations there should be carefully reviewed. 4. References [RFC2440] J. Callas, L. Donnerhacke, H. Finney and R. Thayer, "OpenPGP Message Format", RFC 2440, November 1998. [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate Requirement Level", BCP 14, RFC 2119, March 1997. 5. Author's Address David Shaw Jabberwocky Tech 16 Farina Road Newton, MA 02459 Email: dshaw@jabberwocky.com Tel: +1 (617) 332-8443 Shaw [Page 3]