draft-ietf-openpgp-rfc2440bis-20.txt   draft-ietf-openpgp-rfc2440bis-21.txt 
Network Working Group Jon Callas Network Working Group Jon Callas
Internet-Draft PGP Corporation Internet-Draft PGP Corporation
Intended status: Standards Track Intended status: Standards Track
Expires September 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-20 draft-ietf-openpgp-rfc2440bis-21
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 4, line 5 skipping to change at page 4, line 5
5.2.1. Signature Types 20 5.2.1. Signature Types 20
5.2.2. Version 3 Signature Packet Format 22 5.2.2. Version 3 Signature Packet Format 22
5.2.3. Version 4 Signature Packet Format 24 5.2.3. Version 4 Signature Packet Format 24
5.2.3.1. Signature Subpacket Specification 25 5.2.3.1. Signature Subpacket Specification 25
5.2.3.2. Signature Subpacket Types 27 5.2.3.2. Signature Subpacket Types 27
5.2.3.3. Notes on Self-Signatures 27 5.2.3.3. Notes on Self-Signatures 27
5.2.3.4. Signature creation time 28 5.2.3.4. Signature creation time 28
5.2.3.5. Issuer 28 5.2.3.5. Issuer 28
5.2.3.6. Key expiration time 28 5.2.3.6. Key expiration time 28
5.2.3.7. Preferred symmetric algorithms 28 5.2.3.7. Preferred symmetric algorithms 28
5.2.3.8. Preferred hash algorithms 28 5.2.3.8. Preferred hash algorithms 29
5.2.3.9. Preferred compression algorithms 29 5.2.3.9. Preferred compression algorithms 29
5.2.3.10.Signature expiration time 29 5.2.3.10.Signature expiration time 29
5.2.3.11.Exportable Certification 29 5.2.3.11.Exportable Certification 29
5.2.3.12.Revocable 30 5.2.3.12.Revocable 30
5.2.3.13.Trust signature 30 5.2.3.13.Trust signature 30
5.2.3.14.Regular expression 30 5.2.3.14.Regular expression 30
5.2.3.15.Revocation key 30 5.2.3.15.Revocation key 31
5.2.3.16.Notation Data 31 5.2.3.16.Notation Data 31
5.2.3.17.Key server preferences 32 5.2.3.17.Key server preferences 32
5.2.3.18.Preferred key server 32 5.2.3.18.Preferred key server 32
5.2.3.19.Primary User ID 32 5.2.3.19.Primary User ID 32
5.2.3.20.Policy URI 32 5.2.3.20.Policy URI 33
5.2.3.21.Key Flags 33 5.2.3.21.Key Flags 33
5.2.3.22.Signer's User ID 34 5.2.3.22.Signer's User ID 34
5.2.3.23.Reason for Revocation 34 5.2.3.23.Reason for Revocation 34
5.2.3.24.Features 35 5.2.3.24.Features 35
5.2.3.25.Signature Target 35 5.2.3.25.Signature Target 35
5.2.3.26.Embedded Signature 35 5.2.3.26.Embedded Signature 36
5.2.4. Computing Signatures 36 5.2.4. Computing Signatures 36
5.2.4.1. Subpacket Hints 37 5.2.4.1. Subpacket Hints 37
5.3. Symmetric-Key Encrypted Session Key Packets (Tag 3) 37 5.3. Symmetric-Key Encrypted Session Key Packets (Tag 3) 37
5.4. One-Pass Signature Packets (Tag 4) 38 5.4. One-Pass Signature Packets (Tag 4) 38
5.5. Key Material Packet 39 5.5. Key Material Packet 39
5.5.1. Key Packet Variants 39 5.5.1. Key Packet Variants 39
5.5.1.1. Public Key Packet (Tag 6) 39 5.5.1.1. Public Key Packet (Tag 6) 39
5.5.1.2. Public Subkey Packet (Tag 14) 39 5.5.1.2. Public Subkey Packet (Tag 14) 39
5.5.1.3. Secret Key Packet (Tag 5) 39 5.5.1.3. Secret Key Packet (Tag 5) 39
5.5.1.4. Secret Subkey Packet (Tag 7) 39 5.5.1.4. Secret Subkey Packet (Tag 7) 40
5.5.2. Public Key Packet Formats 39 5.5.2. Public Key Packet Formats 40
5.5.3. Secret Key Packet Formats 41 5.5.3. Secret Key Packet Formats 41
5.6. Compressed Data Packet (Tag 8) 43 5.6. Compressed Data Packet (Tag 8) 43
5.7. Symmetrically Encrypted Data Packet (Tag 9) 43 5.7. Symmetrically Encrypted Data Packet (Tag 9) 44
5.8. Marker Packet (Obsolete Literal Packet) (Tag 10) 44 5.8. Marker Packet (Obsolete Literal Packet) (Tag 10) 44
5.9. Literal Data Packet (Tag 11) 44 5.9. Literal Data Packet (Tag 11) 45
5.10. Trust Packet (Tag 12) 45 5.10. Trust Packet (Tag 12) 46
5.11. User ID Packet (Tag 13) 46 5.11. User ID Packet (Tag 13) 46
5.12. User Attribute Packet (Tag 17) 46 5.12. User Attribute Packet (Tag 17) 46
5.12.1. The Image Attribute Subpacket 46 5.12.1. The Image Attribute Subpacket 47
5.13. Sym. Encrypted Integrity Protected Data Packet (Tag 18) 47 5.13. Sym. Encrypted Integrity Protected Data Packet (Tag 18) 47
5.14. Modification Detection Code Packet (Tag 19) 50 5.14. Modification Detection Code Packet (Tag 19) 50
6. Radix-64 Conversions 50 6. Radix-64 Conversions 51
6.1. An Implementation of the CRC-24 in "C" 51 6.1. An Implementation of the CRC-24 in "C" 51
6.2. Forming ASCII Armor 51 6.2. Forming ASCII Armor 52
6.3. Encoding Binary in Radix-64 54 6.3. Encoding Binary in Radix-64 54
6.4. Decoding Radix-64 55 6.4. Decoding Radix-64 55
6.5. Examples of Radix-64 55 6.5. Examples of Radix-64 56
6.6. Example of an ASCII Armored Message 56 6.6. Example of an ASCII Armored Message 56
7. Cleartext signature framework 56 7. Cleartext signature framework 56
7.1. Dash-Escaped Text 57 7.1. Dash-Escaped Text 57
8. Regular Expressions 57 8. Regular Expressions 58
9. Constants 58 9. Constants 58
9.1. Public Key Algorithms 58 9.1. Public Key Algorithms 59
9.2. Symmetric Key Algorithms 59 9.2. Symmetric Key Algorithms 59
9.3. Compression Algorithms 59 9.3. Compression Algorithms 60
9.4. Hash Algorithms 59 9.4. Hash Algorithms 60
10. IANA Considerations 60 10. IANA Considerations 60
10.1. New String-to-Key specifier types 60 10.1. New String-to-Key specifier types 60
10.2. New Packets 60 10.2. New Packets 61
10.2.1. User Attribute Types 60 10.2.1. User Attribute Types 61
10.2.1.1.Image Format Subpacket Types 60 10.2.1.1.Image Format Subpacket Types 61
10.2.2. New Signature Subpackets 61 10.2.2. New Signature Subpackets 61
10.2.2.1.Signature Notation Data Subpackets 61 10.2.2.1.Signature Notation Data Subpackets 61
10.2.2.2.Key Server Preference Extensions 61 10.2.2.2.Key Server Preference Extensions 62
10.2.2.3.Key Flags Extensions 61 10.2.2.3.Key Flags Extensions 62
10.2.2.4.Reason For Revocation Extensions 62 10.2.2.4.Reason For Revocation Extensions 62
10.2.2.5.Implementation Features 62 10.2.2.5.Implementation Features 62
10.2.3. New Packet Versions 62 10.2.3. New Packet Versions 62
10.3. New Algorithms 62 10.3. New Algorithms 63
10.3.1. Public Key Algorithms 63 10.3.1. Public Key Algorithms 63
10.3.2. Symmetric Key Algorithms 63 10.3.2. Symmetric Key Algorithms 63
10.3.3. Hash Algorithms 63 10.3.3. Hash Algorithms 63
10.3.4. Compression Algorithms 63 10.3.4. Compression Algorithms 64
10.4. Private or Experimental Parameters 63 11. Packet Composition 64
10.5. Extension of the MDC System 64 11.1. Transferable Public Keys 64
10.6. Meta-Considerations 64 11.2. Transferable Secret Keys 65
11. Packet Composition 65 11.3. OpenPGP Messages 65
11.1. Transferable Public Keys 65 11.4. Detached Signatures 66
11.2. Transferable Secret Keys 66 12. Enhanced Key Formats 66
11.3. OpenPGP Messages 66 12.1. Key Structures 66
11.4. Detached Signatures 67 12.2. Key IDs and Fingerprints 67
12. Enhanced Key Formats 67 13. Notes on Algorithms 68
12.1. Key Structures 67 13.1. PKCS#1 Encoding In OpenPGP 68
12.2. Key IDs and Fingerprints 68 13.1.1. EME-PKCS1-v1_5-ENCODE 69
13. Notes on Algorithms 69 13.1.2. EME-PKCS1-v1_5-DECODE 69
13.1. PKCS#1 Encoding In OpenPGP 69 13.1.3. EMSA-PKCS1-v1_5 70
13.1.1. EME-PKCS1-v1_5-ENCODE 70 13.2. Symmetric Algorithm Preferences 71
13.1.2. EME-PKCS1-v1_5-DECODE 70 13.3. Other Algorithm Preferences 71
13.1.3. EMSA-PKCS1-v1_5 71 13.3.1. Compression Preferences 71
13.2. Symmetric Algorithm Preferences 72 13.3.2. Hash Algorithm Preferences 72
13.3. Other Algorithm Preferences 72 13.4. Plaintext 72
13.3.1. Compression Preferences 72 13.5. RSA 72
13.3.2. Hash Algorithm Preferences 73 13.6. DSA 73
13.4. Plaintext 73 13.7. Elgamal 73
13.5. RSA 73 13.8. Reserved Algorithm Numbers 73
13.6. DSA 74 13.9. OpenPGP CFB mode 74
13.7. Elgamal 74 13.10. Private or Experimental Parameters 75
13.8. Reserved Algorithm Numbers 74 13.11. Extension of the MDC System 75
13.9. OpenPGP CFB mode 75 13.12. Meta-Considerations for Expansion 76
14. Security Considerations 76 14. Implementation Nits 79
15. Implementation Nits 79 15. Authors' Addresses 80
16. Authors' Addresses 80 16. References (Normative) 81
17. References (Normative) 81 17. References (Informative) 83
18. References (Informative) 82 18. Full Copyright Statement 84
19. Full Copyright Statement 83 19. Intellectual Property 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." Exchange Formats." [RFC1991] [RFC2440]
1.1. Terms 1.1. Terms
* OpenPGP - This is a definition for security software that uses * OpenPGP - This is a definition for security software that uses
PGP 5.x as a basis, formalized in RFC 2440 and this document. PGP 5.x as a basis, formalized in RFC 2440 and this document.
* PGP - Pretty Good Privacy. PGP is a family of software systems * PGP - Pretty Good Privacy. PGP is a family of software systems
developed by Philip R. Zimmermann from which OpenPGP is based. developed by Philip R. Zimmermann from which OpenPGP is based.
* PGP 2.6.x - This version of PGP has many variants, hence the * PGP 2.6.x - This version of PGP has many variants, hence the
skipping to change at page 26, line 10 skipping to change at page 26, line 10
if the 1st octet >= 192 and < 255, then if the 1st octet >= 192 and < 255, then
lengthOfLength = 2 lengthOfLength = 2
subpacketLen = ((1st_octet - 192) << 8) + (2nd_octet) + 192 subpacketLen = ((1st_octet - 192) << 8) + (2nd_octet) + 192
if the 1st octet = 255, then if the 1st octet = 255, then
lengthOfLength = 5 lengthOfLength = 5
subpacket length = [four-octet scalar starting at 2nd_octet] subpacket length = [four-octet scalar starting at 2nd_octet]
The value of the subpacket type octet may be: The value of the subpacket type octet may be:
0 = reserved
1 = reserved
2 = signature creation time 2 = signature creation time
3 = signature expiration time 3 = signature expiration time
4 = exportable certification 4 = exportable certification
5 = trust signature 5 = trust signature
6 = regular expression 6 = regular expression
7 = revocable 7 = revocable
8 = reserved
9 = key expiration time 9 = key expiration time
10 = placeholder for backward compatibility 10 = placeholder for backward compatibility
11 = preferred symmetric algorithms 11 = preferred symmetric algorithms
12 = revocation key 12 = revocation key
13 = reserved
14 = reserved
15 = reserved
16 = issuer key ID 16 = issuer key ID
17 = reserved
18 = reserved
19 = reserved
20 = notation data 20 = notation data
21 = preferred hash algorithms 21 = preferred hash algorithms
22 = preferred compression algorithms 22 = preferred compression algorithms
23 = key server preferences 23 = key server preferences
24 = preferred key server 24 = preferred key server
25 = primary User ID 25 = primary User ID
26 = policy URI 26 = policy URI
27 = key flags 27 = key flags
28 = signer's User ID 28 = signer's User ID
29 = reason for revocation 29 = reason for revocation
skipping to change at page 34, line 29 skipping to change at page 34, line 39
(1 octet of revocation code, N octets of reason string) (1 octet of revocation code, N octets of reason string)
This subpacket is used only in key revocation and certification This subpacket is used only in key revocation and certification
revocation signatures. It describes the reason why the key or revocation signatures. It describes the reason why the key or
certificate was revoked. certificate was revoked.
The first octet contains a machine-readable code that denotes the The first octet contains a machine-readable code that denotes the
reason for the revocation: reason for the revocation:
0x00 - No reason specified (key revocations or cert revocations) 0 - No reason specified (key revocations or cert revocations)
0x01 - Key is superseded (key revocations) 1 - Key is superseded (key revocations)
0x02 - Key material has been compromised (key revocations) 2 - Key material has been compromised (key revocations)
0x03 - Key is retired and no longer used (key revocations) 3 - Key is retired and no longer used (key revocations)
0x20 - User ID information is no longer valid (cert revocations) 32 - User ID information is no longer valid (cert revocations)
Following the revocation code is a string of octets which gives Following the revocation code is a string of octets which gives
information about the reason for revocation in human-readable form information about the reason for revocation in human-readable form
(UTF-8). The string may be null, that is, of zero length. The length (UTF-8). The string may be null, that is, of zero length. The length
of the subpacket is the length of the reason string plus one. of the subpacket is the length of the reason string plus one.
An implementation SHOULD implement this subpacket, include it in all An implementation SHOULD implement this subpacket, include it in all
revocation signatures, and interpret revocations appropriately. revocation signatures, and interpret revocations appropriately.
There are important semantic differences between the reasons, and There are important semantic differences between the reasons, and
there are thus important reasons for revoking signatures. there are thus important reasons for revoking signatures.
skipping to change at page 58, line 49 skipping to change at page 59, line 13
algorithm range. algorithm range.
See the section "Notes on Algorithms" below for more discussion of See the section "Notes on Algorithms" below for more discussion of
the algorithms. the algorithms.
9.1. Public Key Algorithms 9.1. Public Key Algorithms
ID Algorithm ID Algorithm
-- --------- -- ---------
1 - RSA (Encrypt or Sign) [HAC] 1 - RSA (Encrypt or Sign) [HAC]
2 - RSA Encrypt-Only 2 - RSA Encrypt-Only [HAC]
3 - RSA Sign-Only 3 - RSA Sign-Only [HAC]
16 - Elgamal (Encrypt-Only), see [ELGAMAL] [HAC] 16 - Elgamal (Encrypt-Only), see [ELGAMAL] [HAC]
17 - DSA (Digital Signature Algorithm) [FIPS186] [HAC] 17 - DSA (Digital Signature Algorithm) [FIPS186] [HAC]
18 - Reserved for Elliptic Curve 18 - Reserved for Elliptic Curve
19 - Reserved for ECDSA 19 - Reserved for ECDSA
20 - Reserved (formerly Elgamal Encrypt or Sign) 20 - Reserved (formerly Elgamal Encrypt or Sign)
21 - Reserved for Diffie-Hellman (X9.42, 21 - Reserved for Diffie-Hellman (X9.42,
as defined for IETF-S/MIME) as defined for IETF-S/MIME)
100 to 110 - Private/Experimental algorithm. 100 to 110 - Private/Experimental algorithm.
Implementations MUST implement DSA for signatures, and Elgamal for Implementations MUST implement DSA for signatures, and Elgamal for
encryption. Implementations SHOULD implement RSA keys. encryption. Implementations SHOULD implement RSA keys (1). RSA
Implementations MAY implement any other algorithm. Encrypt-Only (2) and RSA Sign-Only are deprecated and SHOULD NOT be
generated, but may be interpreted. See Section 13.5. See Section
13.8 for notes on Elliptic Curve (18), ECDSA (19), Elgamal Encrypt
or Sign (20), and X9.42 (21). Implementations MAY implement any
other algorithm.
9.2. Symmetric Key Algorithms 9.2. Symmetric Key Algorithms
ID Algorithm ID Algorithm
-- --------- -- ---------
0 - Plaintext or unencrypted data 0 - Plaintext or unencrypted data
1 - IDEA [IDEA] 1 - IDEA [IDEA]
2 - TripleDES (DES-EDE, [SCHNEIER] [HAC] - 2 - TripleDES (DES-EDE, [SCHNEIER] [HAC] -
168 bit key derived from 192) 168 bit key derived from 192)
3 - CAST5 (128 bit key, as per RFC 2144) 3 - CAST5 (128 bit key, as per RFC 2144)
skipping to change at page 63, line 47 skipping to change at page 64, line 15
10.3.4. Compression Algorithms 10.3.4. Compression Algorithms
OpenPGP specifies a number of compression algorithms. This OpenPGP specifies a number of compression algorithms. This
specification creates a registry of compression algorithm specification creates a registry of compression algorithm
identifiers. The registry includes the algorithm name, and a identifiers. The registry includes the algorithm name, and a
reference to the defining specification. The initial values for this reference to the defining specification. The initial values for this
registry can be found in section 9.3. Adding a new compression key registry can be found in section 9.3. Adding a new compression key
algorithm MUST be done through the IETF CONSENSUS method, as algorithm MUST be done through the IETF CONSENSUS method, as
described in [RFC2434]. described in [RFC2434].
10.4. Private or Experimental Parameters
S2K specifiers, Signature subpacket types, user attribute types,
image format types, and algorithms described in Section 9 all
reserve the range 100 to 110 for private and experimental use.
Packet types reserve the range 60 to 63 for private and experimental
use. These are intentionally managed with the PRIVATE USE method, as
described in [RFC2434].
However, implementations need to be careful with these and promote
them to full IANA-managed parameters when they grow beyond the
original, limited system.
10.5. Extension of the MDC System
As described in the non-normative explanation in section 5.13, the
MDC system is uniquely unparameterized in OpenPGP, and that this was
an intentional decision to avoid cross-grade attacks. If the MDC
system is extended to a stronger hash function, there must be care
given to avoiding downgrade and cross-grade attacks.
One simple way to do this is to create new packets for a new MDC.
For example, instead of the MDC system using packets 18 and 19, a
new MDC could use 20 and 21. This has obvious drawbacks (it uses two
packet numbers for each new hash function in a space that is limited
to a maximum of 60).
Another simple way to extend the MDC system is to create new
versions of packet 18, and reflect this in packet 19. For example,
suppose that V2 of packet 18 implicitly used SHA-256. This would
require packet 19 to have a length of 32 octets. The change in the
version in packet 18 and the size of packet 19 prevent a downgrade
attack.
There are two drawbacks to this latter approach. The first is that
using the version number of a packet to carry algorithm information
is not tidy from a protocol-design standpoint. it is possible that
there might be several versions of the MDC system in common use, but
this untidiness would reflect untidiness in cryptographic consensus
about hash function security. The second is that different versions
of packet 19 would have to have unique sizes. If there were two
versions each with 256-bit hashes, they could not both have 32-octet
packet 19s without admitting the chance of a cross-grade attack.
Yet another, complex approach to extend the MDC system would be a
hybrid of the two above -- create a new pair of MDC packets that are
fully parameterized, and yet protected from downgrade and
cross-grade.
Any change to the MDC system MUST be done through the IETF CONSENSUS
method, as described in [RFC2434].
10.6. Meta-Considerations
If OpenPGP is extended in a way that is not upwards-compatible,
meaning that old implementations will not gracefully handle their
absence of a new feature, the extension proposal can be declared in
the key holder's self-signature as part of the Features signature
subpacket.
We cannot state definitively what extensions will not be
upwards-compatible, but typically new algorithms are
upwards-compatible, but new packets are not.
If an extension proposal does not update the Features system, it
SHOULD include an explanation of why this is unnecessary. If the
proposal contains neither an extension to the Features system nor an
explanation of why such an extension is unnecessary, the proposal
SHOULD be rejected.
11. Packet Composition 11. Packet Composition
OpenPGP packets are assembled into sequences in order to create OpenPGP packets are assembled into sequences in order to create
messages and to transfer keys. Not all possible packet sequences are messages and to transfer keys. Not all possible packet sequences are
meaningful and correct. This section describes the rules for how meaningful and correct. This section describes the rules for how
packets should be placed into sequences. packets should be placed into sequences.
11.1. Transferable Public Keys 11.1. Transferable Public Keys
OpenPGP users may transfer public keys. The essential elements of a OpenPGP users may transfer public keys. The essential elements of a
skipping to change at page 73, line 52 skipping to change at page 72, line 52
13.4. Plaintext 13.4. Plaintext
Algorithm 0, "plaintext," may only be used to denote secret keys Algorithm 0, "plaintext," may only be used to denote secret keys
that are stored in the clear. Implementations MUST NOT use plaintext that are stored in the clear. Implementations MUST NOT use plaintext
in Symmetrically Encrypted Data Packets; they must use Literal Data in Symmetrically Encrypted Data Packets; they must use Literal Data
Packets to encode unencrypted or literal data. Packets to encode unencrypted or literal data.
13.5. RSA 13.5. RSA
There are algorithm types for RSA-signature-only, and There are algorithm types for RSA Sign-Only, and RSA Encrypt-Only
RSA-encrypt-only keys. These types are deprecated. The "key flags" keys. These types are deprecated. The "key flags" subpacket in a
subpacket in a signature is a much better way to express the same signature is a much better way to express the same idea, and
idea, and generalizes it to all algorithms. An implementation SHOULD generalizes it to all algorithms. An implementation SHOULD NOT
NOT create such a key, but MAY interpret it. create such a key, but MAY interpret it.
An implementation SHOULD NOT implement RSA keys of size less than An implementation SHOULD NOT implement RSA keys of size less than
1024 bits. 1024 bits.
13.6. DSA 13.6. DSA
An implementation SHOULD NOT implement DSA keys of size less than An implementation SHOULD NOT implement DSA keys of size less than
1024 bits. It MUST NOT implement a DSA key with a q size of less 1024 bits. It MUST NOT implement a DSA key with a q size of less
than 160 bits. DSA keys MUST also be a multiple of 64 bits, and the than 160 bits. DSA keys MUST also be a multiple of 64 bits, and the
q size MUST be a multiple of 8 bits. The Digital Signature Standard q size MUST be a multiple of 8 bits. The Digital Signature Standard
skipping to change at page 76, line 24 skipping to change at page 75, line 24
10. FR is loaded with C[BS+3] to C[BS + (BS+2)] (which is C11-C18 10. FR is loaded with C[BS+3] to C[BS + (BS+2)] (which is C11-C18
for an 8-octet block). for an 8-octet block).
11. FR is encrypted to produce FRE. 11. FR is encrypted to produce FRE.
12. FRE is xored with the next BS octets of plaintext, to produce 12. FRE is xored with the next BS octets of plaintext, to produce
the next BS octets of ciphertext. These are loaded into FR and the next BS octets of ciphertext. These are loaded into FR and
the process is repeated until the plaintext is used up. the process is repeated until the plaintext is used up.
14. Security Considerations 13.10. Private or Experimental Parameters
S2K specifiers, Signature subpacket types, user attribute types,
image format types, and algorithms described in Section 9 all
reserve the range 100 to 110 for private and experimental use.
Packet types reserve the range 60 to 63 for private and experimental
use. These are intentionally managed with the PRIVATE USE method, as
described in [RFC2434].
However, implementations need to be careful with these and promote
them to full IANA-managed parameters when they grow beyond the
original, limited system.
13.11. Extension of the MDC System
As described in the non-normative explanation in section 5.13, the
MDC system is uniquely unparameterized in OpenPGP, and that this was
an intentional decision to avoid cross-grade attacks. If the MDC
system is extended to a stronger hash function, there must be care
given to avoiding downgrade and cross-grade attacks.
One simple way to do this is to create new packets for a new MDC.
For example, instead of the MDC system using packets 18 and 19, a
new MDC could use 20 and 21. This has obvious drawbacks (it uses two
packet numbers for each new hash function in a space that is limited
to a maximum of 60).
Another simple way to extend the MDC system is to create new
versions of packet 18, and reflect this in packet 19. For example,
suppose that V2 of packet 18 implicitly used SHA-256. This would
require packet 19 to have a length of 32 octets. The change in the
version in packet 18 and the size of packet 19 prevent a downgrade
attack.
There are two drawbacks to this latter approach. The first is that
using the version number of a packet to carry algorithm information
is not tidy from a protocol-design standpoint. it is possible that
there might be several versions of the MDC system in common use, but
this untidiness would reflect untidiness in cryptographic consensus
about hash function security. The second is that different versions
of packet 19 would have to have unique sizes. If there were two
versions each with 256-bit hashes, they could not both have 32-octet
packet 19s without admitting the chance of a cross-grade attack.
Yet another, complex approach to extend the MDC system would be a
hybrid of the two above -- create a new pair of MDC packets that are
fully parameterized, and yet protected from downgrade and
cross-grade.
Any change to the MDC system MUST be done through the IETF CONSENSUS
method, as described in [RFC2434].
13.12. Meta-Considerations for Expansion
If OpenPGP is extended in a way that is not backwards-compatible,
meaning that old implementations will not gracefully handle their
absence of a new feature, the extension proposal can be declared in
the key holder's self-signature as part of the Features signature
subpacket.
We cannot state definitively what extensions will not be
upwards-compatible, but typically new algorithms are
upwards-compatible, but new packets are not.
If an extension proposal does not update the Features system, it
SHOULD include an explanation of why this is unnecessary. If the
proposal contains neither an extension to the Features system nor an
explanation of why such an extension is unnecessary, the proposal
SHOULD be rejected. .head 1 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 31 skipping to change at page 79, line 45
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.
15. Implementation Nits 14. 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 25 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.
16. Authors' Addresses 15. 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 4 skipping to change at page 81, line 20
Wildenbruchstr. 15 Wildenbruchstr. 15
07745 Jena, Germany 07745 Jena, Germany
EMail: lutz@iks-jena.de EMail: lutz@iks-jena.de
Hal Finney Hal Finney
Email: hal@finney.org Email: hal@finney.org
David Shaw David Shaw
Email: dshaw@jabberwocky.com Email: dshaw@jabberwocky.com
Rodney Thayer Rodney Thayer
Email: rodney@tillerman.to 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.
17. References (Normative) 16. References (Normative)
[AES] Advanced Encryption Standards Questions and Answers [AES] Advanced Encryption Standards Questions and Answers
<http://csrc.nist.gov/encryption/aes/round2/ <http://csrc.nist.gov/encryption/aes/round2/
aesfact.html> aesfact.html>
<http://csrc.nist.gov/encryption/aes/round2/ <http://csrc.nist.gov/encryption/aes/round2/
r2algs.html#Rijndael> r2algs.html#Rijndael>
[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
skipping to change at page 82, line 49 skipping to change at page 83, line 12
"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.
18. References (Informative) 17. 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 39 skipping to change at page 83, line 52
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 [RFC1991] Atkins, D., Stallings, W. and P. Zimmermann, "PGP
Message Exchange Formats", RFC 1991, August 1996. Message Exchange Formats", RFC 1991, August 1996.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Level", BCP 14, RFC 2119, March 1997. Requirement Level", BCP 14, RFC 2119, March 1997.
[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for
Writing an IANA Considerations Section in RFCs", Writing an IANA Considerations Section in RFCs",
BCP 26, RFC 2434, October 1998. BCP 26, RFC 2434, October 1998.
[RFC2440] Callas, J., Donnerhacke, L., Finney, H., and
Thayer, R. "OpenPGP Message Format", RFC 2440,
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>
19. Full Copyright Statement 18. 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 31 skipping to change at page 84, line 47
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.
20. Intellectual Property 19. 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. 41 change blocks. 
152 lines changed or deleted 167 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/