draft-ietf-openpgp-rfc2440bis-00.txt | draft-ietf-openpgp-rfc2440bis-01.txt | |||
---|---|---|---|---|

Network Working Group Jon Callas | Network Working Group Jon Callas | |||

Category: INTERNET-DRAFT Counterpane Internet Security | Category: INTERNET-DRAFT Counterpane Internet Security | |||

draft-ietf-openpgp-rfc2440bis-00.txt | draft-ietf-openpgp-rfc2440bis-01.txt | |||

Expires Jun 2000 Lutz Donnerhacke | Expires Apr 2001 Lutz Donnerhacke | |||

December 1999 IN-Root-CA Individual Network e.V. | October 2000 IN-Root-CA Individual Network e.V. | |||

Hal Finney | Hal Finney | |||

Network Associates | Network Associates | |||

Rodney Thayer | Rodney Thayer | |||

SSH Communications Security, Inc. | ||||

OpenPGP Message Format | OpenPGP Message Format | |||

draft-ietf-openpgp-rfc2440bis-00.txt | draft-ietf-openpgp-rfc2440bis-01.txt | |||

Copyright 1999 by The Internet Society. All Rights Reserved. | Copyright 2000 by The Internet Society. All Rights Reserved. | |||

Status of this Memo | Status of this Memo | |||

This document is an Internet-Draft and is in full conformance with | This document is an Internet-Draft and is in full conformance with | |||

all provisions of Section 10 of RFC2026. | all provisions of Section 10 of RFC2026. | |||

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 | |||

other groups may also distribute working documents as | other groups may also distribute working documents as | |||

Internet-Drafts. | Internet-Drafts. | |||

skipping to change at page 6, line 10 | skipping to change at page 6, line 10 | |||

14. Implementation Nits 59 | 14. Implementation Nits 59 | |||

15. Authors and Working Group Chair 60 | 15. Authors and Working Group Chair 60 | |||

16. References 61 | 16. References 61 | |||

17. Full Copyright Statement 63 | 17. Full Copyright Statement 63 | |||

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 RFC2440, "OpenPGP | and key management functions. It is a revision of RFC2440, "OpenPGP | |||

Message Format", and replaces RFC 1991, "PGP Message Exchange | Message Format", which itself replaces RFC 1991, "PGP Message | |||

Formats." | Exchange Formats." | |||

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 12, line 31 | skipping to change at page 12, line 31 | |||

possibilities: | possibilities: | |||

0: secret data is unencrypted (no pass phrase) | 0: secret data is unencrypted (no pass phrase) | |||

255: followed by algorithm octet and S2K specifier | 255: followed by algorithm octet and S2K specifier | |||

Cipher alg: use Simple S2K algorithm using MD5 hash | Cipher alg: use Simple S2K algorithm using MD5 hash | |||

This last possibility, the cipher algorithm number with an implicit | This last possibility, the cipher algorithm number with an implicit | |||

use of MD5 and IDEA, is provided for backward compatibility; it MAY | use of MD5 and IDEA, is provided for backward compatibility; it MAY | |||

be understood, but SHOULD NOT be generated, and is deprecated. | be understood, but SHOULD NOT be generated, and is deprecated. | |||

These are followed by an 8-octet Initial Vector for the decryption | These are followed by an Initial Vector of the same length as the | |||

of the secret values, if they are encrypted, and then the secret key | block size of the cipher for the decryption of the secret values, if | |||

values themselves. | they are encrypted, and then the secret key values themselves. | |||

3.6.2.2. Symmetric-key message encryption | 3.6.2.2. Symmetric-key message encryption | |||

OpenPGP can create a Symmetric-key Encrypted Session Key (ESK) | OpenPGP can create a Symmetric-key Encrypted Session Key (ESK) | |||

packet at the front of a message. This is used to allow S2K | packet at the front of a message. This is used to allow S2K | |||

specifiers to be used for the passphrase conversion or to create | specifiers to be used for the passphrase conversion or to create | |||

messages with a mix of symmetric-key ESKs and public-key ESKs. This | messages with a mix of symmetric-key ESKs and public-key ESKs. This | |||

allows a message to be decrypted either with a passphrase or a | allows a message to be decrypted either with a passphrase or a | |||

public key. | public key. | |||

skipping to change at page 20, line 27 | skipping to change at page 20, line 27 | |||

The data being signed is hashed, and then the signature type and | The data being signed is hashed, and then the signature type and | |||

creation time from the signature packet are hashed (5 additional | creation time from the signature packet are hashed (5 additional | |||

octets). The resulting hash value is used in the signature | octets). The resulting hash value is used in the signature | |||

algorithm. The high 16 bits (first two octets) of the hash are | algorithm. The high 16 bits (first two octets) of the hash are | |||

included in the signature packet to provide a quick test to reject | included in the signature packet to provide a quick test to reject | |||

some invalid signatures. | some invalid signatures. | |||

Algorithm Specific Fields for RSA signatures: | Algorithm Specific Fields for RSA signatures: | |||

- multiprecision integer (MPI) of RSA signature value m**d. | - multiprecision integer (MPI) of RSA signature value m**d mod n. | |||

Algorithm Specific Fields for DSA signatures: | Algorithm Specific Fields for DSA signatures: | |||

- MPI of DSA value r. | - MPI of DSA value r. | |||

- MPI of DSA value s. | - MPI of DSA value s. | |||

The signature calculation is based on a hash of the signed data, as | The signature calculation is based on a hash of the signed data, as | |||

described above. The details of the calculation are different for | described above. The details of the calculation are different for | |||

DSA signature than for RSA signatures. | DSA signature than for RSA signatures. | |||

skipping to change at page 21, line 52 | skipping to change at page 21, line 52 | |||

- One-octet public key algorithm. | - One-octet public key algorithm. | |||

- One-octet hash algorithm. | - One-octet hash algorithm. | |||

- Two-octet scalar octet count for following hashed subpacket | - Two-octet scalar octet count for following hashed subpacket | |||

data. Note that this is the length in octets of all of the | data. Note that this is the length in octets of all of the | |||

hashed subpackets; a pointer incremented by this number will | hashed subpackets; a pointer incremented by this number will | |||

skip over the hashed subpackets. | skip over the hashed subpackets. | |||

- Hashed subpacket data. (zero or more subpackets) | - Hashed subpacket data. (two or more subpackets) | |||

- Two-octet scalar octet count for following unhashed subpacket | - Two-octet scalar octet count for following unhashed subpacket | |||

data. Note that this is the length in octets of all of the | data. Note that this is the length in octets of all of the | |||

unhashed subpackets; a pointer incremented by this number will | unhashed subpackets; a pointer incremented by this number will | |||

skip over the unhashed subpackets. | skip over the unhashed subpackets. | |||

- Unhashed subpacket data. (zero or more subpackets) | - Unhashed subpacket data. (zero or more subpackets) | |||

- Two-octet field holding left 16 bits of signed hash value. | - Two-octet field holding left 16 bits of signed hash value. | |||

- One or more multi-precision integers comprising the signature. | - One or more multi-precision integers comprising the signature. | |||

skipping to change at page 36, line 19 | skipping to change at page 36, line 19 | |||

- MPI of RSA public encryption exponent e. | - MPI of RSA public encryption exponent e. | |||

Algorithm Specific Fields for DSA public keys: | Algorithm Specific Fields for DSA public keys: | |||

- MPI of DSA prime p; | - MPI of DSA prime p; | |||

- MPI of DSA group order q (q is a prime divisor of p-1); | - MPI of DSA group order q (q is a prime divisor of p-1); | |||

- MPI of DSA group generator g; | - MPI of DSA group generator g; | |||

- MPI of DSA public key value y (= g**x where x is secret). | - MPI of DSA public key value y (= g**x mod p where x is | |||

secret). | ||||

Algorithm Specific Fields for Elgamal public keys: | Algorithm Specific Fields for Elgamal public keys: | |||

- MPI of Elgamal prime p; | - MPI of Elgamal prime p; | |||

- MPI of Elgamal group generator g; | - MPI of Elgamal group generator g; | |||

- MPI of Elgamal public key value y (= g**x where x is | - MPI of Elgamal public key value y (= g**x mod p where x is | |||

secret). | secret). | |||

5.5.3. Secret Key Packet Formats | 5.5.3. Secret Key Packet Formats | |||

The Secret Key and Secret Subkey packets contain all the data of the | The Secret Key and Secret Subkey packets contain all the data of the | |||

Public Key and Public Subkey packets, with additional | Public Key and Public Subkey packets, with additional | |||

algorithm-specific secret key data appended, in encrypted form. | algorithm-specific secret key data appended, in encrypted form. | |||

The packet contains: | The packet contains: | |||

skipping to change at page 36, line 52 | skipping to change at page 36, line 53 | |||

indicates that a string-to-key specifier is being given. Any | indicates that a string-to-key specifier is being given. Any | |||

other value is a symmetric-key encryption algorithm specifier. | other value is a symmetric-key encryption algorithm specifier. | |||

- [Optional] If string-to-key usage octet was 255, a one-octet | - [Optional] If string-to-key usage octet was 255, a one-octet | |||

symmetric encryption algorithm. | symmetric encryption algorithm. | |||

- [Optional] If string-to-key usage octet was 255, a string-to-key | - [Optional] If string-to-key usage octet was 255, a string-to-key | |||

specifier. The length of the string-to-key specifier is implied | specifier. The length of the string-to-key specifier is implied | |||

by its type, as described above. | by its type, as described above. | |||

- [Optional] If secret data is encrypted, eight-octet Initial | - [Optional] If secret data is encrypted, Initial Vector (IV) of | |||

Vector (IV). | the same length as the cipher's block size. | |||

- Encrypted multi-precision integers comprising the secret key | - Encrypted multi-precision integers comprising the secret key | |||

data. These algorithm-specific fields are as described below. | data. These algorithm-specific fields are as described below. | |||

- Two-octet checksum of the plaintext of the algorithm-specific | - Two-octet checksum of the plaintext of the algorithm-specific | |||

portion (sum of all octets, mod 65536). | portion (sum of all octets, mod 65536). | |||

Algorithm Specific Fields for RSA secret keys: | Algorithm Specific Fields for RSA secret keys: | |||

- multiprecision integer (MPI) of RSA secret exponent d. | - multiprecision integer (MPI) of RSA secret exponent d. | |||

skipping to change at page 48, line 37 | skipping to change at page 48, line 37 | |||

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. | |||

Implementations MAY implement any other algorithm. | 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 - Triple-DES (DES-EDE, as per spec - | 2 - Triple-DES (DES-EDE, [SCHNEIER] - | |||

168 bit key derived from 192) | 168 bit key derived from 192) | |||

3 - CAST5 (128 bit key, as per RFC2144) | 3 - CAST5 (128 bit key, as per RFC2144) | |||

4 - Blowfish (128 bit key, 16 rounds) [BLOWFISH] | 4 - Blowfish (128 bit key, 16 rounds) [BLOWFISH] | |||

5 - SAFER-SK128 (13 rounds) [SAFER] | 5 - SAFER-SK128 (13 rounds) [SAFER] | |||

6 - Reserved for DES/SK | 6 - Reserved for DES/SK | |||

7 - Reserved for AES with 128-bit key | 7 - Reserved for AES with 128-bit key | |||

8 - Reserved for AES with 192-bit key | 8 - Reserved for AES with 192-bit key | |||

9 - Reserved for AES with 256-bit key | 9 - Reserved for AES with 256-bit key | |||

10 - Twofish with 256-bit key [TWOFISH] | 10 - Twofish with 256-bit key [TWOFISH] | |||

100 to 110 - Private/Experimental algorithm. | 100 to 110 - Private/Experimental algorithm. | |||

skipping to change at page 53, line 11 | skipping to change at page 53, line 11 | |||

e) Algorithm specific fields. | e) Algorithm specific fields. | |||

Algorithm Specific Fields for DSA keys (example): | Algorithm Specific Fields for DSA keys (example): | |||

e.1) MPI of DSA prime p; | e.1) MPI of DSA prime p; | |||

e.2) MPI of DSA group order q (q is a prime divisor of p-1); | e.2) MPI of DSA group order q (q is a prime divisor of p-1); | |||

e.3) MPI of DSA group generator g; | e.3) MPI of DSA group generator g; | |||

e.4) MPI of DSA public key value y (= g**x where x is secret). | e.4) MPI of DSA public key value y (= g**x mod p where x is secret). | |||

Note that it is possible for there to be collisions of key IDs -- | Note that it is possible for there to be collisions of key IDs -- | |||

two different keys with the same key ID. Note that there is a much | two different keys with the same key ID. Note that there is a much | |||

smaller, but still non-zero probability that two different keys have | smaller, but still non-zero probability that two different keys have | |||

the same fingerprint. | the same fingerprint. | |||

Also note that if V3 and V4 format keys share the same RSA key | Also note that if V3 and V4 format keys share the same RSA key | |||

material, they will have different key ids as well as different | material, they will have different key ids as well as different | |||

fingerprints. | fingerprints. | |||

skipping to change at page 58, line 5 | skipping to change at page 58, line 5 | |||

7. (The resync step) FR is loaded with C[3] through C[BS+2]. | 7. (The resync step) FR is loaded with C[3] through C[BS+2]. | |||

8. FR is encrypted to produce FRE. | 8. FR is encrypted to produce FRE. | |||

9. FRE is xored with the first BS octets of the given plaintext, | 9. FRE is xored with the first BS octets of the given plaintext, | |||

now that we have finished encrypting the BS+2 octets of prefixed | now that we have finished encrypting the BS+2 octets of prefixed | |||

data. This produces C[BS+3] through C[BS+(BS+2)], the next BS | data. This produces C[BS+3] through C[BS+(BS+2)], the next BS | |||

octets of ciphertext. | octets of ciphertext. | |||

10. FR is loaded with C11-C18 | 10. FR is loaded with C[BS+3] to C[BS + (BS+2)] (which is C11-C18 | |||

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. | |||

13. Security Considerations | 13. Security Considerations | |||

As with any technology involving cryptography, you should check the | As with any technology involving cryptography, you should check the | |||

skipping to change at page 59, line 15 | skipping to change at page 59, line 16 | |||

Some technologies mentioned here may be subject to government | Some technologies mentioned here may be subject to government | |||

control in some countries. | control in some countries. | |||

14. 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 list of potential problems | vexing than large differences. Thus, this is a non-comprehensive | |||

and gotchas for a developer who is trying to be backward-compatible. | list of potential problems and gotchas for a developer who is trying | |||

to be backward-compatible. | ||||

* PGP 5.x does not accept V4 signatures for anything other than | * PGP 5.x does not accept V4 signatures for anything other than | |||

key material. | key material. | |||

* PGP 5.x does not recognize the "five-octet" lengths in | * PGP 5.x does not recognize the "five-octet" lengths in | |||

new-format headers or in signature subpacket lengths. | new-format headers or in signature subpacket lengths. | |||

* PGP 5.0 rejects an encrypted session key if the keylength | * PGP 5.0 rejects an encrypted session key if the keylength | |||

differs from the S2K symmetric algorithm. This is a bug in its | differs from the S2K symmetric algorithm. This is a bug in its | |||

validation function. | validation function. | |||

skipping to change at page 60, line 14 | skipping to change at page 60, line 18 | |||

V4 format, but since a V4 fingerprint is constructed by hashing | V4 format, but since a V4 fingerprint is constructed by hashing | |||

the key creation time along with other things, two V4 keys | the key creation time along with other things, two V4 keys | |||

created at different times, yet with the same key material will | created at different times, yet with the same key material will | |||

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. | |||

* PGP 2.6.X and 5.0 do not trim trailing whitespace from a | * PGP 2.6.X and 5.0 do not trim trailing whitespace from a | |||

"canonical text" signature. They only remove it from cleartext | "canonical text" signature. They only remove it from cleartext | |||

signatures. | signatures. These signatures are not OpenPGP compliant -- | |||

OpenPGP requires trimming the whitespace. If you wish to | ||||

interoperate with PGP 2.6.X or PGP 5, you may wish to accept | ||||

these non-compliant signatures. | ||||

* PGP 6.0 introduced a photographic user id and represents this id | * PGP 6.0 introduced a photographic user id and represents this id | |||

in packet number 17. The format of this packet is proprietary to | in packet number 17. The format of this packet is proprietary to | |||

its authors. Strictly speaking, an OpenPGP key that contains | its authors. Strictly speaking, an OpenPGP key that contains | |||

such a packet is not compliant to this document, and that packet | such a packet is not compliant to this document, and that packet | |||

number is reserved by this document for future use. However, if | number is reserved by this document for future use. However, if | |||

an implementation wishes to be compatible with such keys, the | an implementation wishes to be compatible with such keys, the | |||

packet may be considered to be a user id packet with opaque | packet may be considered to be a user id packet with opaque | |||

contents. | contents. | |||

15. Authors and Working Group Chair | 15. Authors and Working Group Chair | |||

The working group can be contacted via the current chair: | The working group can be contacted via the current chair: | |||

John W. Noerenberg, II | John W. Noerenberg, II | |||

Qualcomm, Inc | Qualcomm, Inc | |||

6455 Lusk Blvd | 6455 Lusk Blvd | |||

San Diego, CA 92131 USA | San Diego, CA 92131 USA | |||

Email: jwn2@qualcomm.com | Email: jwn2@qualcomm.com | |||

Tel: +1 619-658-3510 | Tel: +1 (619) 658-3510 | |||

The principal authors of this draft are: | The principal authors of this draft are: | |||

Jon Callas | Jon Callas | |||

Counterpane Internet Security, Inc. | Counterpane Internet Security, Inc. | |||

3031 Tisch Way, suite 100 East Plaza | 3031 Tisch Way, suite 100 East Plaza | |||

San Jose, CA 95128, USA | San Jose, CA 95128, USA | |||

Email: jon@callas.org, callas@counterpane.com | Email: jon@callas.org, jon@counterpane.com | |||

Tel: +1 408-556-0328 | Tel: +1 (408) 556-2445 | |||

Lutz Donnerhacke | Lutz Donnerhacke | |||

IKS GmbH | IKS GmbH | |||

Wildenbruchstr. 15 | Wildenbruchstr. 15 | |||

07745 Jena, Germany | 07745 Jena, Germany | |||

EMail: lutz@iks-jena.de | EMail: lutz@iks-jena.de | |||

Tel: +49-3641-675642 | Tel: +49-3641-675642 | |||

Hal Finney | Hal Finney | |||

Network Associates, Inc. | Network Associates, Inc. | |||

3965 Freedom Circle | 3965 Freedom Circle | |||

Santa Clara, CA 95054, USA | Santa Clara, CA 95054, USA | |||

Email: hal@pgp.com | Email: hal@pgp.com | |||

Rodney Thayer | Rodney Thayer | |||

SSH Communications Security, Inc. | ||||

650 Castro Street Suite 220 | ||||

Mountain View, CA 94041, USA | ||||

Email: rodney@ipsec.com | Email: rodney@tillerman.to | |||

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, Raph | Marc Dyksterhouse, Gail Haspert, Gene Hoffman, Paul Hoffman, Raph | |||

Levien, Colin Plumb, Will Price, William Stallings, Mark Weaver, and | Levien, Colin Plumb, Will Price, William Stallings, Mark Weaver, and | |||

Philip R. Zimmermann. | Philip R. Zimmermann. | |||

16. References | 16. References | |||

[BLEICHENBACHER] Bleichenbacher, Daniel, "Generating ElGamal | [BLEICHENBACHER] Bleichenbacher, Daniel, "Generating ElGamal | |||

skipping to change at page 63, line 19 | skipping to change at page 63, line 19 | |||

[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. Full Copyright Statement | 17. Full Copyright Statement | |||

Copyright 1999 by The Internet Society. All Rights Reserved. | Copyright 2000 by The Internet Society. All Rights Reserved. | |||

This document and translations of it may be copied and furnished to | This document and translations of it may be copied and furnished to | |||

others, and derivative works that comment on or otherwise explain it | others, and derivative works that comment on or otherwise explain it | |||

or assist in its implementation may be prepared, copied, published | or assist in its implementation may be prepared, copied, published | |||

and distributed, in whole or in part, without restriction of any | and distributed, in whole or in part, without restriction of any | |||

kind, provided that the above copyright notice and this paragraph | kind, provided that the above copyright notice and this paragraph | |||

are included on all such copies and derivative works. However, this | are included on all such copies and derivative works. However, this | |||

document itself may not be modified in any way, such as by removing | document itself may not be modified in any way, such as by removing | |||

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 | |||

End of changes. | ||||

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/ |