Subject: [openpgp] List of "semantic" changes between 4880 and bis

From: Wiktor Kwapisiewicz <[email-masked]>
Date: Fri, 2 Oct 2020 15:37:44 +0200

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

---

From: Werner Koch <[email-masked]>
Date: Sat, 03 Oct 2020 20:20:53 +0200

>> A piece is an atom possibly followed by '_', '+', or '?'.

Good catch.  That seems to be a bug introduced with the change to the
new Ruby tool.  In the soruce it is correct:

  A piece is an atom possibly followed by '*', '+', or '?'.  An atom
  followed by '*' matches a sequence of 0 or more matches of the

Has anyone more experience with that new tool?

Shalom-Salam,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Tue, 06 Oct 2020 01:03:21 -0400

> Has anyone more experience with that new tool?

I've posted several minor cleanup edits here:

https://gitlab.com/openpgp-wg/rfc4880bis/-/merge_requests/29

I think that commit 756d8b6a9ba6f3f1e20637a2b628b6984697f022 addresses
the concern discussed above, but the whole series is probably worth applying.

Regards,

     --dkg