Hello OpenPGP ML,
As the diff tool on IETF Tools includes whitespace and editorial changes
I compiled a list of "semantic" changes between 4880 and bis. You may
find this interesting especially for parties that look to implement bis.
If something is mentioned then it's new (in bis). If there is a
difference I listed old (4880) and new (bis) values.
Here it goes:
5.1. Public-Key Encrypted Session Key Packets (Tag 1)
Algorithm-Specific Fields for ECDH encryption:
- MPI of an EC point representing an ephemeral public key.
- a one-octet size, followed by a symmetric key encoded using the
method described in Section 13.5.
5.2. Signature Packet (Tag 2)
Implementations MUST generate version 5 signatures when using a
version 5 key. Implementations SHOULD generate V4 signatures with
version 4 keys. Implementations MUST NOT create version 3
signatures; they MAY accept version 3 signatures.
5.2.1. Signature Types
0x16 Attested Key Signature.
5.2.3. Version 4 and 5 Signature Packet Formats
Version 5 Signature Packet Format:
The difference between a V4 and V5 signature is that the latter
includes additional meta data.
5.2.3.1. Signature Subpacket Specification
| Type | Description |
-------------------------------------------------------
| 33 | Issuer Fingerprint |
| 34 | Preferred AEAD Algorithms |
| 35 | Intended Recipient Fingerprint |
| 37 | Attested Certifications |
4880:
Implementations SHOULD implement the three preferred algorithm
subpackets (11, 21, and 22),
bis:
Implementations SHOULD implement the four preferred algorithm
subpackets (11, 21, 22, and 34),
5.2.3.17. Notation Data
New notations: charset, manu, make, model, prodid, pvers, lot, qty, loc,
dest, hash.
5.2.3.22. Key Flags
Second octet:
0x04 - This key may be used as an additional decryption subkey (ADSK).
0x08 - This key may be used for timestamping.
5.2.3.25. Features
0x02 - AEAD Encrypted Data Packet (packet 20) and version 5
Symmetric-Key Encrypted Session Key Packets (packet 3)
0x04 - Version 5 Public-Key Packet format and corresponding new
fingerprint format
5.2.3.28. Issuer Fingerprint
Note that the length N of the fingerprint for a version 4 key is 20
octets; for a version 5 key N is 32.
5.2.3.29. Intended Recipient Fingerprint
5.3. Symmetric-Key Encrypted Session Key Packets (Tag 3)
New: version 5 Symmetric-Key Encrypted Session Key
5.5.2. Public-Key Packet Formats
A version 5 packet contains:
* A one-octet version number (5).
* A four-octet number denoting the time that the key was created.
* A one-octet number denoting the public-key algorithm of this key.
* A four-octet scalar octet count for the following public key
material.
* A series of values comprising the public key material. This is
algorithm-specific and described in Section 5.6.
5.5.3. Secret-Key Packet Formats
New: value "253" (a one-octet AEAD algorithm).
Version 4 Signature Packet Format becomes "Version 4 and 5 Signature
Packet Formats".
The packet contains:
(...)
* Only for a version 5 packet, a one-octet scalar octet count of the
next 4 optional fields.
(...)
* Only for a version 5 packet, a four-octet scalar octet count for
the following secret key material. This includes the encrypted
SHA-1 hash or AEAD tag if the string-to-key usage octet is 254 or
253.
Note that the version 5 packet format adds two count values to help
parsing packets with unknown S2K or public key algorithms.
5.6. Algorithm-specific Parts of Keys
Improved and added ECDSA, EdDSA, ECDH.
5.13. User Attribute Packet (Tag 17)
| Type | Attribute Subpacket |
-----------------------------------------
| [TBD1] | User ID Attribute Subpacket |
5.8. Symmetrically Encrypted Data Packet (Tag 9)
bis: Deprecates it.
5.10. Literal Data Packet (Tag 11)
* A one-octet field that describes how the data is formatted.
...
If it is a 'm' (0x6d), then it contains a MIME message body part
Note that V3 and V4 signatures do not include the formatting octet,
the file name, and the date field of the literal packet in a
signature hash and thus are not protected against tampering in a
signed document. In contrast V5 signatures include them.
5.16. AEAD Encrypted Data Packet (Tag 20)
Implementations SHOULD NOT create data with a chunk size
octet value larger than 21 (128 MiB chunks) to facilitate buffering
of not yet authenticated plaintext.
5.16.1. EAX Mode
5.16.2. OCB Mode
8. Regular Expressions
4880:
A piece is an atom possibly followed by '*', '+', or '?'.
bis:
A piece is an atom possibly followed by '_', '+', or '?'.
9. Constants
9.1. Public-Key Algorithms
| ID | Algorithm |
---------------------------------------------------------------
| 22 | EdDSA [RFC8032] |
| 23 | Reserved for AEDH |
| 24 | Reserved for AEDSA |
9.2. ECC Curve OID
9.3. Symmetric-Key Algorithms
| ID | Algorithm |
--------------------------------------------------
| 11 | Camellia with 128-bit key [RFC3713] |
| 12 | Camellia with 192-bit key |
| 13 | Camellia with 256-bit key |
4880:
Implementations MUST implement TripleDES. Implementations SHOULD
implement AES-128 and CAST5.
bis:
Implementations MUST implement AES-128. Implementations SHOULD
implement AES-256. Implementations that interoperate with RFC-4880
implementations need to support TripleDES and CAST5.
9.5. Hash Algorithms
| ID | Algorithm | Text Name |
----------------------------------------------------------
| 12 | SHA3-256 [FIPS202] | "SHA3-256" |
| 13 | Reserved | |
| 14 | SHA3-512 [FIPS202] | "SHA3-512" |
Note:
The ID 13 has been reserved so that the SHA3 algorithm IDs align
nicely with their SHA2 counterparts
4880:
Implementations MUST implement SHA-1. Implementations MAY implement
other algorithms. MD5 is deprecated.
bis:
Implementations MUST implement SHA2-256. Implementations MAY
implement other algorithms. Implementations SHOULD NOT create messages
which require the use of SHA-1 with the exception of computing version4
key fingerprints and for purposes of the MDC packet. Implementations
SHOULD NOT use MD5 or RIPE-MD/160.
10.2. New Packets
4880:
Adding a new packet type MUST be done through the IETF CONSENSUS method
bis:
Adding a new packet type MUST be done through the RFC REQUIRED method
10.2.1. User Attribute Types
IETF CONSENSUS -> SPECIFICATION REQUIRED
10.2.2. Image Format Subpacket Types
IETF CONSENSUS -> SPECIFICATION REQUIRED
10.2.3. New Signature Subpackets
IETF CONSENSUS -> SPECIFICATION REQUIRED
11.1. Transferable Public Keys
4880:
- One or more User ID packets
bis:
* Zero or more User ID packets
12.2. Key IDs and Fingerprints
V5 fingerprint is the 256-bit SHA2-256 hash (...)
13. Elliptic Curve Cryptography
16.1. OpenPGP ECC Profile
A compliant application MUST implement NIST curve P-256, SHOULD
implement NIST curve P-521, SHOULD implemend Ed25519, SHOULD
implement Curve25519, MAY implement NIST curve P-384, MAY implement
brainpoolP256r1, and MAY implement brainpoolP512r1, as defined in
Section 9.2. A compliant application MUST implement SHA2-256 and
SHOULD implement SHA2-384 and SHA2-512. A compliant application MUST
implement AES-128 and SHOULD implement AES-256.
---------
I've compiled the list from the Appendix [0], grepping for "version 5"
and notes from Justus Winter (whom I greatly thank for help).
[0]: https://tools.ietf.org/html/draft-ietf-openpgp-rfc4880bis-10#appendix-C
If anyone sees some omissions I've made but which are significant please
bring it up.
Kind regards,
Wiktor
--
https://metacode.biz/@wiktor
signature.asc
Description: OpenPGP digital signature
_______________________________________________
openpgp mailing list
openpgp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/openpgp