[openpgp] Clarifiction on v5 signatures
Werner Koch <wk@gnupg.org> Tue, 23 October 2018 10:50 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 3B482130E27 for <openpgp@ietfa.amsl.com>; Tue, 23 Oct 2018 03:50:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.001
X-Spam-Level:
X-Spam-Status: No, score=-7.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-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 NZZ_Gl3mUTRE for <openpgp@ietfa.amsl.com>; Tue, 23 Oct 2018 03:50:11 -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 5E0D3127598 for <openpgp@ietf.org>; Tue, 23 Oct 2018 03:50:11 -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:Date:Subject:To:From: Sender:Reply-To:Cc:Content-Transfer-Encoding:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: In-Reply-To:References:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=oiSCPkULl6oPm8o0tHA42c0fTswQlcBcc+c8XT4sfi8=; b=isdI/JtpVWTSOhl48gyvxnazo1 bMBYvpL7bO/fWExL2XzVR8NIyrKE9zlUaViTXghn8meRU5bxTuVM+ikxWzmEDtdnnWWc13Z+MlQHh AVJq0pe+phd3mHxOZU09qp4VbLyqybKWz7sUdsbq5fNnKYn8iUrDpq/KTCzgPQbPArb0=;
Received: from uucp by kerckhoffs.g10code.com with local-rmail (Exim 4.89 #1 (Debian)) id 1gEuGH-0006eL-Ha for <openpgp@ietf.org>; Tue, 23 Oct 2018 12:50:09 +0200
Received: from wk by wheatstone.g10code.de with local (Exim 4.84 #3 (Debian)) id 1gEuCf-0007uh-E6 for <openpgp@ietf.org>; Tue, 23 Oct 2018 12:46:25 +0200
From: Werner Koch <wk@gnupg.org>
To: openpgp@ietf.org
Organisation: GnuPG e.V.
X-message-flag: Mails containing HTML will not be read! Please send only plain text.
Mail-Followup-To: openpgp@ietf.org
Date: Tue, 23 Oct 2018 12:46:19 +0200
Message-ID: <877ei9szyc.fsf@wheatstone.g10code.de>
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=bce_JSOFC3IP_strategic_TWA_Project_Monarch_number_key_ammunition=sat"; micalg="pgp-sha256"; protocol="application/pgp-signature"
Archived-At: <https://mailarchive.ietf.org/arch/msg/openpgp/B6cRBt6w-Hf1VdzjFuGnvHw_6BY>
Subject: [openpgp] Clarifiction on v5 signatures
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: Tue, 23 Oct 2018 10:50:14 -0000
Hi! The current draft mentions v5 signatures but did not specify them. Below and in the repo is a fix for that. The Literal Data packet never included the filename etc into the signature which is a bit surprising to the user and implementor. Given that we specified a new v5 key format we have an easy way to solve this by requirung that a v5 key must use a v5 signature. That v5 signature now includes the meta data from the Literal Data packet. This patchalso deprecates the creation of v3 signatures. Any comments? Can we start to change the existing rfc4880bis code accordingly? Shalom-Salam, Werner ============ diff --git a/middle.mkd b/middle.mkd index 9e5bb58..8bbdf3a 100644 --- a/middle.mkd +++ b/middle.mkd @@ -671,17 +671,16 @@ ## {5.2} Signature Packet (Tag 2) some data. The most common signatures are a signature of a file or a block of text, and a signature that is a certification of a User ID. -Two versions of Signature packets are defined. Version 3 provides -basic signature information, while version 4 provides an expandable +Three versions of Signature packets are defined. Version 3 provides +basic signature information, while versions 4 and 5 provide an expandable format with subpackets that can specify more information about the signature. PGP 2.6.x only accepts version 3 signatures. -Implementations SHOULD accept V3 signatures. Implementations SHOULD -generate V4 signatures. +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. -Note that if an implementation is creating an encrypted and signed -message that is encrypted to a V3 key, it is reasonable to create a V3 -signature. ### {5.2.1} Signature Types @@ -924,11 +923,12 @@ ### {5.2.2} Version 3 Signature Packet Format truncated) hash function result is treated as a number and used directly in the DSA signature algorithm. -### {5.2.3} Version 4 Signature Packet Format +### {5.2.3} Version 4 and 5 Signature Packet Formats -The body of a version 4 Signature packet contains: +The body of a V4 or V5 Signature packet contains: - * One-octet version number (4). + * One-octet version number. This is 4 for V4 signatures and + 5 for V5 signatures. * One-octet signature type. @@ -973,8 +973,8 @@ ### {5.2.3} Version 4 Signature Packet Format * MPI of EdDSA compressed value s. The compressed version of R and S for use with EdDSA is described in -[](#I-D.irtf-cfrg-eddsa). The version 3 signature format MUST NOT be -used with EdDSA. +[](#I-D.irtf-cfrg-eddsa). A version 3 signature MUST NOT be created +and MUST NOT be used with EdDSA. The concatenation of the data being signed and the signature data from the version number through the hashed subpacket data (inclusive) is @@ -988,6 +988,9 @@ ### {5.2.3} Version 4 Signature Packet Format protected by the signature and should include only advisory information. +The difference between a V4 and V5 signature is that the latter +creates signatures which include additional meta data. + The algorithms for converting the hash function result to a signature are described in a section below. @@ -1102,7 +1105,7 @@ #### {5.2.3.3} Notes on Self-Signatures (type 0x1F), and the subkey binding signature (type 0x18). For certification self-signatures, each User ID may have a self- signature, and thus different subpackets in those self-signatures. For -subkey binding signatures, each subkey in fact has a self- signature. +subkey binding signatures, each subkey in fact has a self-signature. Subpackets that appear in a certification self-signature apply to the user name, and subpackets that appear in the subkey self-signature apply to the subkey. Lastly, subpackets on the direct-key signature @@ -1714,7 +1717,8 @@ ### {5.2.4} Computing Signatures of the Signature packet, i.e., 0x04; 0xFF; and a four-octet, big-endian number that is the length of the hashed data from the Signature packet (note that this number does not include these final -six octets). {FIXME: truncated or wrap that number on overflow} +six octets). The four-octet big-endian number is considered to be an +unsigned integer modulo 2^32. V5 signatures instead hash in a ten-octet trailer: the version of the Signature packet, i.e., 0x05; 0xFF; and an eight-octet, big-endian @@ -2351,9 +2355,10 @@ ## {5.9} Literal Data Packet (Tag 11) network-normal line endings). These should be converted to native line endings by the receiving software. -Note that the formatting octet, the file name, and the date field of -the literal packet are not included in a signature hash and thus are -not protected against tampering in a signed document. +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.10} Trust Packet (Tag 12) -- 2.11.0 -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz.
- [openpgp] Clarifiction on v5 signatures Werner Koch
- Re: [openpgp] Clarifiction on v5 signatures Werner Koch
- Re: [openpgp] Clarifiction on v5 signatures Heiko Stamer
- Re: [openpgp] Clarifiction on v5 signatures Werner Koch
- Re: [openpgp] Clarifiction on v5 signatures Wiktor Kwapisiewicz
- Re: [openpgp] Clarifiction on v5 signatures Werner Koch
- Re: [openpgp] Clarifiction on v5 signatures Wiktor Kwapisiewicz
- Re: [openpgp] Clarifiction on v5 signatures Heiko Stamer
- Re: [openpgp] Clarifiction on v5 signatures Wiktor Kwapisiewicz
- Re: [openpgp] Clarifiction on v5 signatures Werner Koch
- Re: [openpgp] Clarifiction on v5 signatures Wiktor Kwapisiewicz
- Re: [openpgp] Clarifiction on v5 signatures Werner Koch
- Re: [openpgp] Clarifiction on v5 signatures Paul Fawkesley
- Re: [openpgp] Clarifiction on v5 signatures Vincent Breitmoser
- Re: [openpgp] Clarifiction on v5 signatures Heiko Stamer
- Re: [openpgp] Clarifiction on v5 signatures Wiktor Kwapisiewicz
- Re: [openpgp] Clarifiction on v5 signatures Werner Koch