Re: [openpgp] Issues from a novice reader

Werner Koch <wk@gnupg.org> Sat, 26 June 2021 14:40 UTC

Return-Path: <wk@gnupg.org>
X-Original-To: openpgp@ietfa.amsl.com
Delivered-To: openpgp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2915B3A167B for <openpgp@ietfa.amsl.com>; Sat, 26 Jun 2021 07:40:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level:
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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ix3F7NV-Tk81 for <openpgp@ietfa.amsl.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 <openpgp@ietf.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 <openpgp@ietf.org>; 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 <wk@gnupg.org>
To: Stuart Schechter <stuart.schechter@gmail.com>
Cc: openpgp@ietf.org
References: <CAJio-2dhYvL1T9Mv1tz+P5zju+P8k--D1k4QJHnb7GaqB0ahng@mail.gmail.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 <stuart.schechter@gmail.com>, openpgp@ietf.org
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")
Message-ID: <87sg14k7zk.fsf@wheatstone.g10code.de>
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=TDYC_Customs_and_Border_Protection_Soros_Spetznaz_Heroin_Red_Cell_CI"; micalg=pgp-sha256; protocol="application/pgp-signature"
Archived-At: <https://mailarchive.ietf.org/arch/msg/openpgp/Of4vQQNRz5V7oYhIgzDVYYdv7ow>
Subject: Re: [openpgp] Issues from a novice reader
X-BeenThere: openpgp@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Ongoing discussion of OpenPGP issues." <openpgp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/openpgp>, <mailto:openpgp-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/openpgp/>
List-Post: <mailto:openpgp@ietf.org>
List-Help: <mailto:openpgp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/openpgp>, <mailto:openpgp-request@ietf.org?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.