IETF Logo Mail Archive

Re: [openpgp] Clarifiction on v5 signatures

Werner Koch <wk@gnupg.org> Thu, 25 October 2018 09: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 858CB130DD3 for <openpgp@ietfa.amsl.com>; Thu, 25 Oct 2018 02:50:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7
X-Spam-Level:
X-Spam-Status: No, score=-7 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, 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 5r77-_tWXThr for <openpgp@ietfa.amsl.com>; Thu, 25 Oct 2018 02: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 17DAD12870E for <openpgp@ietf.org>; Thu, 25 Oct 2018 02:50:10 -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=iKm5FLD3YcS7G04C6+aT11vP31jjtEJcD4O5AGxPUVg=; b=hlv5S3TbLBfj/RF4je2WYGijnf eoaY2hfurMsCBm9hzEmyEhlVjHsUS+UmSq39IuJIlFkSBJ5XdS9Opk6YUDhIe0H8JxDNtMQ0PuuoO pHawxFKnnEVhDLaRAlhDmLT34/g+RE1pK41/jM/mnnFA9Wx/1o+AXkHfJ1A1IyBjwHLk=;
Received: from uucp by kerckhoffs.g10code.com with local-rmail (Exim 4.89 #1 (Debian)) id 1gFcHJ-0008Qa-4G for <openpgp@ietf.org>; Thu, 25 Oct 2018 11:50:09 +0200
Received: from wk by wheatstone.g10code.de with local (Exim 4.84 #3 (Debian)) id 1gFcE6-0007Dm-U2; Thu, 25 Oct 2018 11:46:50 +0200
From: Werner Koch <wk@gnupg.org>
To: Heiko Stamer <HeikoStamer@gmx.net>
Cc: openpgp@ietf.org
References: <877ei9szyc.fsf@wheatstone.g10code.de> <dda2d47e-b06e-cd6c-9bab-d8f30149c2ad@gmx.net>
Organisation: GnuPG e.V.
X-message-flag: Mails containing HTML will not be read! Please send only plain text.
Mail-Followup-To: Heiko Stamer <HeikoStamer@gmx.net>, openpgp@ietf.org
Date: Thu, 25 Oct 2018 11:46:45 +0200
In-Reply-To: <dda2d47e-b06e-cd6c-9bab-d8f30149c2ad@gmx.net> (Heiko Stamer's message of "Wed, 24 Oct 2018 20:12:35 +0200")
Message-ID: <87mur2nyt6.fsf@wheatstone.g10code.de>
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=pipeline_Ft._Bragg_data_haven_JFK_Tony_Blair_bce_Panama_interception"; micalg="pgp-sha256"; protocol="application/pgp-signature"
Archived-At: <https://mailarchive.ietf.org/arch/msg/openpgp/Rz1gOx6SNi4faGksmh8tR_26miw>
Subject: Re: [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: Thu, 25 Oct 2018 09:50:14 -0000

On Wed, 24 Oct 2018 20:12, HeikoStamer@gmx.net said:

> https://gitlab.com/openpgp-wg/rfc4880bis/merge_requests/12

Thanks.  For reference, here is the patch:

--8<---------------cut here---------------start------------->8---
--- a/middle.mkd
+++ b/middle.mkd
@@ -1504,8 +1504,6 @@ assume a fixed size.  This is so it can grow over time.  If a list is
 shorter than an implementation expects, the unstated flags are
 considered to be zero.  The defined flags are as follows:
 
-Defined features are as follows:
-
 First octet:
 
     0x01 - This key may be used to certify other keys.
@@ -1527,6 +1525,8 @@ First octet:
 Second octet:
 
     0x04 - This key may be used as an additional decryption subkey (ADSK).
+    
+    0x08 - This key may be used for timestamping.
 
 
 Usage notes:
@@ -1822,7 +1822,7 @@ A version 4 Symmetric-Key Encrypted Session Key packet consists of:
 If the encrypted session key is not present (which can be detected on
 the basis of packet length and S2K specifier size), then the S2K
 algorithm applied to the passphrase produces the session key for
-decrypting the file, using the symmetric cipher algorithm from the
+decrypting the message, using the symmetric cipher algorithm from the
 Symmetric-Key Encrypted Session Key packet.
 
 If the encrypted session key is present, the result of applying the
@@ -3676,8 +3676,8 @@ maintained on the proper User Attribute or User ID packet.
 
 After the User ID packet or Attribute packet, there may be zero or
 more Subkey packets.  In general, subkeys are provided in cases where
-the top-level public key is a signature-only key.  However, any V4 key
-may have subkeys, and the subkeys may be encryption-only keys,
+the top-level public key is a signature-only key.  However, any V4 or
+V5 key may have subkeys, and the subkeys may be encryption-only keys,
 signature-only keys, or general-purpose keys. V3 keys MUST NOT have
 subkeys.
--8<---------------cut here---------------end--------------->8---


Salam-Shalom,

   Werner

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

v2.23.0 | Report a Bug | By Email