Re: [openpgp] Issues from a novice reader
Werner Koch <email@example.com> Sat, 26 June 2021 14:40 UTC
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2915B3A167B for <firstname.lastname@example.org>; Sat, 26 Jun 2021 07:40:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=gnupg.org
Received: from mail.ietf.org ([126.96.36.199]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ix3F7NV-Tk81 for <email@example.com>; Sat, 26 Jun 2021 07:40:12 -0700 (PDT)
Received: from kerckhoffs.g10code.com (kerckhoffs.g10code.com [IPv6:2001:aa8:fff1:100::22]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B33403A167A for <firstname.lastname@example.org>; Sat, 26 Jun 2021 07:40:12 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnupg.org; s=20181017; h=Content-Type:MIME-Version:Message-ID:In-Reply-To:Date: References:Subject:Cc:To:From:Sender:Reply-To:Content-Transfer-Encoding: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=macMIhmODqZbI6yVN22FjCpnoHrN3IQP0mkK9BUpaL0=; b=KJeDqNARfXAytwR9skc2/iRPbn a4XvSzwzyVIyjj9VqTQIwdCENy3MJVkv7Ot8WkH4xivvtiyhS0TNOOxKRIGm/zThP5B1aJoV6Ts7a 3QIxz700SD7DQCD5aEz8ky5sayxL8MxLNCqdeE2DsYK3CbgxYIU7M6AMF2N+gYnQQdAo=;
Received: from uucp by kerckhoffs.g10code.com with local-rmail (Exim 4.89 #1 (Debian)) id 1lx9Tc-0008Ae-GK for <email@example.com>; Sat, 26 Jun 2021 16:40:08 +0200
Received: from wk by wheatstone.g10code.de with local (Exim 4.92 #5 (Debian)) id 1lx9Qd-0001aj-HG; Sat, 26 Jun 2021 16:37:03 +0200
From: Werner Koch <firstname.lastname@example.org>
To: Stuart Schechter <email@example.com>
Organisation: GnuPG e.V.
X-message-flag: Mails containing HTML will not be read! Please send only plain text.
Mail-Followup-To: Stuart Schechter <firstname.lastname@example.org>, email@example.com
Date: Sat, 26 Jun 2021 16:37:03 +0200
In-Reply-To: <CAJio-2dhYvL1T9Mv1tz+P5zju+P8k--D1k4QJHnb7GaqB0ahng@mail.gmail.com> (Stuart Schechter's message of "Sat, 26 Jun 2021 11:57:32 +0900")
User-Agent: Gnus/5.13 (Gnus v5.13)
Content-Type: multipart/signed; boundary="=TDYC_Customs_and_Border_Protection_Soros_Spetznaz_Heroin_Red_Cell_CI"; micalg=pgp-sha256; protocol="application/pgp-signature"
Subject: Re: [openpgp] Issues from a novice reader
List-Id: "Ongoing discussion of OpenPGP issues." <openpgp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/openpgp>, <mailto:firstname.lastname@example.org?subject=unsubscribe>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/openpgp>, <mailto:email@example.com?subject=subscribe>
X-List-Received-Date: Sat, 26 Jun 2021 14:40:18 -0000
Hi! Thanks for your comments. I am fine using the bug tracker to track the status of a suggestion/bug/feature. For discussion I still believe that the ML list is a better place. So I took the freedom to copy the content of your five reports below. It refer to the lates git HEAD and proabbly not to the last I-D. In fact, we should soon turn to an I-D based discussion again. Shalom-Salam, Werner Here we go: #32 An inconsistency between the number of stated optional fields (4) and actual optional fields (3). Only for a version 5 packet, a one-octet scalar octet count of the next 4 optional fields. There are only 3 optional fields listed below is line about the next 4 optional fields. Is it 3 or is the composite s2k two fields? Example correct values for different situations would be very helpful since it seems like it might be an all-or-nothing thing where the count is used in anticipation of more fields in the future? Also, I found it unclear what optional means here. They are optional because they MAY be included under the stated conditions, or because they MUST be included under those conditions. #33 Ambiguity about whether checksums are included in a v5 length packet - 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. Does it include the two-byte checksum if the material is not encrypted? Also, there's no references to "AEAD tag" elsewhere in the spec, and it wasn't immediately clear that the other references to AEAD were related to this, so I would appreciate clarification. #34 Challenges for the reader to identify which fields changed in v5 packets Help implementers identify changes between packet versions It would be much easier to update code handling V4 packets for V5 if: 1. All uses of "version 4" were followed by (V4) and all uses of "version 5" were followed by "V5". As is, an implementer has to search for both "V5" and "version 5" to try to identify differences. 2. When listing out the contents of V5 packets that are similar to V4 packets, identify those contents that have changed with Only for a version 5 packet or Only for a version 4 packet as is done for the secret-key packet but not other packets. For example, in 5.2.4 (computing signatures), I missed that the length field has been changed from 4 octets to 8 octets because it's buried pages into that section, nine items down on the second of two long unordered lists. #35 Ambiguity about whether packet headers are included when a secret-key packet starts with the contents of the corresponding public-key packet. Clarify whether Secret-Key packets contain Public-Key packets, or just their bodies The packet contains: - A Public-Key or Public-Subkey packet, as described above. In the reference implementation I'm using in trying to create packets, the Secret-Key packet starts off with content mirroring the Public-Key packet, but it is only the packet body. The public-key packet header is not embedded within the Secret-Key packet following the Secret-Key packets header, as would be the case if a packet (not just the packet body) were to embedded within the Secret-Key packet. #36 Confusion about if/how one SHOULD self-sign secret keys that cannot themselves be used to create signatures (e.g., EC DH keys) Clarify self signatures in the context of private keys that can't be used for signing Implementations SHOULD include self-signatures on any User IDs and subkeys Self signatures are defined as follows: A self-signature is a binding signature made by the key to which the signature refers. There is a category of secret keys that can be used for encryption but not for digital signatures (e.g., EC DH keys) and so, by definition, they cannot be self-signed. If I using PGP keys for on-device encryption, and want to store an EC DH key to a file as a transferable secret key, what would I sign the key with any why should I sign it? What would I sign it with? -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz.