draft-ietf-openpgp-rfc2440bis-21.txt   draft-ietf-openpgp-rfc2440bis-22.txt 
skipping to change at page 1, line 15 skipping to change at page 1, line 15
Expires October 2007 Lutz Donnerhacke Expires October 2007 Lutz Donnerhacke
Obsoletes: 1991, 2440 Hal Finney Obsoletes: 1991, 2440 Hal Finney
PGP Corporation PGP Corporation
David Shaw David Shaw
Rodney Thayer Rodney Thayer
OpenPGP Message Format OpenPGP Message Format
draft-ietf-openpgp-rfc2440bis-21 draft-ietf-openpgp-rfc2440bis-22
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 5, line 52 skipping to change at page 5, line 52
13.3.2. Hash Algorithm Preferences 72 13.3.2. Hash Algorithm Preferences 72
13.4. Plaintext 72 13.4. Plaintext 72
13.5. RSA 72 13.5. RSA 72
13.6. DSA 73 13.6. DSA 73
13.7. Elgamal 73 13.7. Elgamal 73
13.8. Reserved Algorithm Numbers 73 13.8. Reserved Algorithm Numbers 73
13.9. OpenPGP CFB mode 74 13.9. OpenPGP CFB mode 74
13.10. Private or Experimental Parameters 75 13.10. Private or Experimental Parameters 75
13.11. Extension of the MDC System 75 13.11. Extension of the MDC System 75
13.12. Meta-Considerations for Expansion 76 13.12. Meta-Considerations for Expansion 76
14. Implementation Nits 79 14. Security Considerations 76
15. Authors' Addresses 80 15. Implementation Nits 79
16. References (Normative) 81 16. Authors' Addresses 80
17. References (Informative) 83 17. References (Normative) 81
18. Full Copyright Statement 84 18. References (Informative) 83
19. Intellectual Property 84 19. Full Copyright Statement 84
20. Intellectual Property 84
1. Introduction 1. Introduction
This document provides information on the message-exchange packet This document provides information on the message-exchange packet
formats used by OpenPGP to provide encryption, decryption, signing, formats used by OpenPGP to provide encryption, decryption, signing,
and key management functions. It is a revision of RFC 2440, "OpenPGP and key management functions. It is a revision of RFC 2440, "OpenPGP
Message Format", which itself replaces RFC 1991, "PGP Message Message Format", which itself replaces RFC 1991, "PGP Message
Exchange Formats." [RFC1991] [RFC2440] Exchange Formats." [RFC1991] [RFC2440]
1.1. Terms 1.1. Terms
skipping to change at page 15, line 17 skipping to change at page 15, line 17
+---------------+ +---------------+
PTag |7 6 5 4 3 2 1 0| PTag |7 6 5 4 3 2 1 0|
+---------------+ +---------------+
Bit 7 -- Always one Bit 7 -- Always one
Bit 6 -- New packet format if set Bit 6 -- New packet format if set
PGP 2.6.x only uses old format packets. Thus, software that PGP 2.6.x only uses old format packets. Thus, software that
interoperates with those versions of PGP must only use old format interoperates with those versions of PGP must only use old format
packets. If interoperability is not an issue, the new packet format packets. If interoperability is not an issue, the new packet format
is preferred. Note that old format packets have four bits of packet is RECOMMENDED. Note that old format packets have four bits of
tags, and new format packets have six; some features cannot be used packet tags, and new format packets have six; some features cannot
and still be backward-compatible. be used and still be backward-compatible.
Also note that packets with a tag greater than or equal to 16 MUST Also note that packets with a tag greater than or equal to 16 MUST
use new format packets. The old format packets can only express tags use new format packets. The old format packets can only express tags
less than or equal to 15. less than or equal to 15.
Old format packets contain: Old format packets contain:
Bits 5-2 -- packet tag Bits 5-2 -- packet tag
Bits 1-0 - length-type Bits 1-0 - length-type
skipping to change at page 76, line 39 skipping to change at page 76, line 39
subpacket. subpacket.
We cannot state definitively what extensions will not be We cannot state definitively what extensions will not be
upwards-compatible, but typically new algorithms are upwards-compatible, but typically new algorithms are
upwards-compatible, but new packets are not. upwards-compatible, but new packets are not.
If an extension proposal does not update the Features system, it If an extension proposal does not update the Features system, it
SHOULD include an explanation of why this is unnecessary. If the SHOULD include an explanation of why this is unnecessary. If the
proposal contains neither an extension to the Features system nor an proposal contains neither an extension to the Features system nor an
explanation of why such an extension is unnecessary, the proposal explanation of why such an extension is unnecessary, the proposal
SHOULD be rejected. .head 1 Security Considerations SHOULD be rejected.
14. Security Considerations
* As with any technology involving cryptography, you should check * As with any technology involving cryptography, you should check
the current literature to determine if any algorithms used here the current literature to determine if any algorithms used here
have been found to be vulnerable to attack. have been found to be vulnerable to attack.
* This specification uses Public Key Cryptography technologies. It * This specification uses Public Key Cryptography technologies. It
is assumed that the private key portion of a public-private key is assumed that the private key portion of a public-private key
pair is controlled and secured by the proper party or parties. pair is controlled and secured by the proper party or parties.
* Certain operations in this specification involve the use of * Certain operations in this specification involve the use of
skipping to change at page 79, line 45 skipping to change at page 79, line 48
timing information about the check can be exposed to an timing information about the check can be exposed to an
attacker, particularly via an automated service that allows attacker, particularly via an automated service that allows
rapidly repeated queries. rapidly repeated queries.
On the other hand, it is inconvenient to the user to be informed On the other hand, it is inconvenient to the user to be informed
that they typed in the wrong passphrase only after a petabyte of that they typed in the wrong passphrase only after a petabyte of
data is decrypted. There are many cases in cryptographic data is decrypted. There are many cases in cryptographic
engineering where the implementer must use care and wisdom, and engineering where the implementer must use care and wisdom, and
this is one. this is one.
14. Implementation Nits 15. Implementation Nits
This section is a collection of comments to help an implementer, This section is a collection of comments to help an implementer,
particularly with an eye to backward compatibility. Previous particularly with an eye to backward compatibility. Previous
implementations of PGP are not OpenPGP-compliant. Often the implementations of PGP are not OpenPGP-compliant. Often the
differences are small, but small differences are frequently more differences are small, but small differences are frequently more
vexing than large differences. Thus, this is a non-comprehensive vexing than large differences. Thus, this is a non-comprehensive
list of potential problems and gotchas for a developer who is trying list of potential problems and gotchas for a developer who is trying
to be backward-compatible. to be backward-compatible.
* The IDEA algorithm is patented, and yet it is required for PGP * The IDEA algorithm is patented, and yet it is required for PGP
skipping to change at page 80, line 42 skipping to change at page 80, line 42
have different fingerprints. have different fingerprints.
* If an implementation is using zlib to interoperate with PGP 2.x, * If an implementation is using zlib to interoperate with PGP 2.x,
then the "windowBits" parameter should be set to -13. then the "windowBits" parameter should be set to -13.
* The 0x19 back signatures were not required for signing subkeys * The 0x19 back signatures were not required for signing subkeys
until relatively recently. Consquently, there may be keys in the until relatively recently. Consquently, there may be keys in the
wild that do not have these back signatures. Implementing wild that do not have these back signatures. Implementing
software may handle these keys as it sees fit. software may handle these keys as it sees fit.
15. Authors' Addresses 16. Authors' Addresses
The working group can be contacted via the current chair: The working group can be contacted via the current chair:
Derek Atkins Derek Atkins
IHTFP Consulting, Inc. IHTFP Consulting, Inc.
6 Farragut Ave 6 Farragut Ave
Somerville, MA 02144 USA Somerville, MA 02144 USA
Email: derek@ihtfp.com Email: derek@ihtfp.com
Tel: +1 617 623 3745 Tel: +1 617 623 3745
skipping to change at page 81, line 30 skipping to change at page 81, line 30
Rodney Thayer Rodney Thayer
Email: rodney@canola-jones.com Email: rodney@canola-jones.com
This memo also draws on much previous work from a number of other This memo also draws on much previous work from a number of other
authors who include: Derek Atkins, Charles Breed, Dave Del Torto, authors who include: Derek Atkins, Charles Breed, Dave Del Torto,
Marc Dyksterhouse, Gail Haspert, Gene Hoffman, Paul Hoffman, Ben Marc Dyksterhouse, Gail Haspert, Gene Hoffman, Paul Hoffman, Ben
Laurie, Raph Levien, Colin Plumb, Will Price, David Shaw, William Laurie, Raph Levien, Colin Plumb, Will Price, David Shaw, William
Stallings, Mark Weaver, and Philip R. Zimmermann. Stallings, Mark Weaver, and Philip R. Zimmermann.
16. References (Normative) 17. References (Normative)
[AES] Advanced Encryption Standards Questions and Answers [AES] NIST, FIPS PUB 197, "Advanced Encryption Standard
<http://csrc.nist.gov/encryption/aes/round2/ (AES)," November 2001.
aesfact.html>
<http://csrc.nist.gov/encryption/aes/round2/ http://csrc.nist.gov/publications/fips/fips197/
r2algs.html#Rijndael> fips-197.{ps,pdf}
[BLOWFISH] Schneier, B. "Description of a New Variable-Length [BLOWFISH] Schneier, B. "Description of a New Variable-Length
Key, 64-Bit Block Cipher (Blowfish)" Fast Software Key, 64-Bit Block Cipher (Blowfish)" Fast Software
Encryption, Cambridge Security Workshop Proceedings Encryption, Cambridge Security Workshop Proceedings
(December 1993), Springer-Verlag, 1994, pp191-204 (December 1993), Springer-Verlag, 1994, pp191-204
<http://www.counterpane.com/bfsverlag.html> <http://www.counterpane.com/bfsverlag.html>
[BZ2] J. Seward, jseward@acm.org, "The Bzip2 and libbzip2 [BZ2] J. Seward, jseward@acm.org, "The Bzip2 and libbzip2
home page" <http://www.bzip.org/> home page" <http://www.bzip.org/>
skipping to change at page 82, line 33 skipping to change at page 82, line 31
[ISO10646] ISO/IEC 10646-1:1993. International Standard -- [ISO10646] ISO/IEC 10646-1:1993. International Standard --
Information technology -- Universal Multiple-Octet Information technology -- Universal Multiple-Octet
Coded Character Set (UCS) -- Part 1: Architecture Coded Character Set (UCS) -- Part 1: Architecture
and Basic Multilingual Plane. and Basic Multilingual Plane.
[JFIF] JPEG File Interchange Format (Version 1.02). [JFIF] JPEG File Interchange Format (Version 1.02).
Eric Hamilton, C-Cube Microsystems, Milpitas, CA, Eric Hamilton, C-Cube Microsystems, Milpitas, CA,
September 1, 1992. September 1, 1992.
[RFC1991] Atkins, D., Stallings, W. and P. Zimmermann, "PGP
Message Exchange Formats", RFC 1991, August 1996.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Level", BCP 14, RFC 2119, March 1997.
[RFC2045] Borenstein, N. and N. Freed, "Multipurpose Internet [RFC2045] Borenstein, N. and N. Freed, "Multipurpose Internet
Mail Extensions (MIME) Part One: Format of Internet Mail Extensions (MIME) Part One: Format of Internet
Message Bodies.", RFC 2045, November 1996. Message Bodies.", RFC 2045, November 1996.
[RFC2144] Adams, C., "The CAST-128 Encryption Algorithm", RFC [RFC2144] Adams, C., "The CAST-128 Encryption Algorithm", RFC
2144, May 1997. 2144, May 1997.
[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for
Writing an IANA Considerations Section in RFCs",
BCP 26, RFC 2434, October 1998.
[RFC2822] Resnick, P., "Internet Message Format", RFC 2822. [RFC2822] Resnick, P., "Internet Message Format", RFC 2822.
[RFC3156] M. Elkins, D. Del Torto, R. Levien, T. Roessler, [RFC3156] M. Elkins, D. Del Torto, R. Levien, T. Roessler,
"MIME Security with OpenPGP", RFC 3156, "MIME Security with OpenPGP", RFC 3156,
August 2001. August 2001.
[RFC3447] B. Kaliski and J. Staddon, "PKCS #1: RSA [RFC3447] B. Kaliski and J. Staddon, "PKCS #1: RSA
Cryptography Specifications Version 2.1", Cryptography Specifications Version 2.1",
RFC 3447, February 2003. RFC 3447, February 2003.
skipping to change at page 83, line 12 skipping to change at page 83, line 19
"Randomness Recommendations for Security", RFC "Randomness Recommendations for Security", RFC
4086, June 2005. 4086, June 2005.
[SCHNEIER] Schneier, B., "Applied Cryptography Second Edition: [SCHNEIER] Schneier, B., "Applied Cryptography Second Edition:
protocols, algorithms, and source code in C", 1996. protocols, algorithms, and source code in C", 1996.
[TWOFISH] B. Schneier, J. Kelsey, D. Whiting, D. Wagner, C. [TWOFISH] B. Schneier, J. Kelsey, D. Whiting, D. Wagner, C.
Hall, and N. Ferguson, "The Twofish Encryption Hall, and N. Ferguson, "The Twofish Encryption
Algorithm", John Wiley & Sons, 1999. Algorithm", John Wiley & Sons, 1999.
17. References (Informative) 18. References (Informative)
[BLEICHENBACHER] Bleichenbacher, Daniel, "Generating Elgamal [BLEICHENBACHER] Bleichenbacher, Daniel, "Generating Elgamal
signatures without knowing the secret key," signatures without knowing the secret key,"
Eurocrypt 96. Note that the version in the Eurocrypt 96. Note that the version in the
proceedings has an error. A revised version is proceedings has an error. A revised version is
available at the time of writing from available at the time of writing from
<ftp://ftp.inf.ethz.ch/pub/publications/papers/ti <ftp://ftp.inf.ethz.ch/pub/publications/papers/ti
/isc/ElGamal.ps> /isc/ElGamal.ps>
[JKS02] Kahil Jallad, Jonathan Katz, Bruce Schneier [JKS02] Kahil Jallad, Jonathan Katz, Bruce Schneier
skipping to change at page 83, line 44 skipping to change at page 83, line 51
CFB Mode Encryption As Used By OpenPGP," IACR CFB Mode Encryption As Used By OpenPGP," IACR
http://eprint.iacr.org/2005/033 http://eprint.iacr.org/2005/033
[RFC1423] Balenson, D., "Privacy Enhancement for Internet [RFC1423] Balenson, D., "Privacy Enhancement for Internet
Electronic Mail: Part III: Algorithms, Modes, and Electronic Mail: Part III: Algorithms, Modes, and
Identifiers", RFC 1423, October 1993. Identifiers", RFC 1423, October 1993.
[RFC1951] Deutsch, P., "DEFLATE Compressed Data Format [RFC1951] Deutsch, P., "DEFLATE Compressed Data Format
Specification version 1.3.", RFC 1951, May 1996. Specification version 1.3.", RFC 1951, May 1996.
[RFC1991] Atkins, D., Stallings, W. and P. Zimmermann, "PGP
Message Exchange Formats", RFC 1991, August 1996.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Level", BCP 14, RFC 2119, March 1997.
[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for
Writing an IANA Considerations Section in RFCs",
BCP 26, RFC 2434, October 1998.
[RFC2440] Callas, J., Donnerhacke, L., Finney, H., and [RFC2440] Callas, J., Donnerhacke, L., Finney, H., and
Thayer, R. "OpenPGP Message Format", RFC 2440, Thayer, R. "OpenPGP Message Format", RFC 2440,
November, 1998. November, 1998.
[SP800-57] NIST Special Publication 800-57, Recommendation on [SP800-57] NIST Special Publication 800-57, Recommendation on
Key Management Key Management
<http://csrc.nist.gov/publications/nistpubs/ <http://csrc.nist.gov/publications/nistpubs/
800-57/SP800-57-Part1.pdf> 800-57/SP800-57-Part1.pdf>
<http://csrc.nist.gov/publications/nistpubs/ <http://csrc.nist.gov/publications/nistpubs/
800-57/SP800-57-Part2.pdf> 800-57/SP800-57-Part2.pdf>
18. Full Copyright Statement 19. Full Copyright Statement
Copyright (C) 2007 by The IETF Trust. Copyright (C) 2007 by The IETF Trust.
This document is subject to the rights, licenses and restrictions This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors contained in BCP 78, and except as set forth therein, the authors
retain all their rights. retain all their rights.
This document and the information contained herein are provided on This document and the information contained herein are provided on
an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE
skipping to change at page 84, line 47 skipping to change at page 84, line 46
the copyright notice or references to the Internet Society or other the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than followed, or as required to translate it into languages other than
English. English.
The limited permissions granted above are perpetual and will not be The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns. revoked by the Internet Society or its successors or assigns.
19. Intellectual Property 20. Intellectual Property
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed Intellectual Property Rights or other rights that might be claimed
to pertain to the implementation or use of the technology described to pertain to the implementation or use of the technology described
in this document or the extent to which any license under such in this document or the extent to which any license under such
rights might or might not be available; nor does it represent that rights might or might not be available; nor does it represent that
it has made any independent effort to identify any such rights. it has made any independent effort to identify any such rights.
Information on the procedures with respect to rights in RFC Information on the procedures with respect to rights in RFC
documents can be found in BCP 78 and BCP 79. documents can be found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use attempt made to obtain a general license or permission for the use
of such proprietary rights by implementers or users of this of such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository specification can be obtained from the IETF on-line IPR repository
at http://www.ietf.org/ipr. at http://www.ietf.org/ipr.
 End of changes. 16 change blocks. 
31 lines changed or deleted 32 lines changed or added

This html diff was produced by rfcdiff 1.33. The latest version is available from http://tools.ietf.org/tools/rfcdiff/