Re: [openpgp] I-D Action: draft-ietf-openpgp-crypto-refresh-02.txt (fwd)

Derek Atkins <derek@ihtfp.com> Tue, 23 February 2021 13:15 UTC

Return-Path: <derek@ihtfp.com>
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 CD10E3A2B2F for <openpgp@ietfa.amsl.com>; Tue, 23 Feb 2021 05:15:36 -0800 (PST)
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=ihtfp.com
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 QPth30oKkibl for <openpgp@ietfa.amsl.com>; Tue, 23 Feb 2021 05:15:34 -0800 (PST)
Received: from mail2.ihtfp.org (MAIL2.IHTFP.ORG [204.107.200.7]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7E4F73A2B97 for <openpgp@ietf.org>; Tue, 23 Feb 2021 05:15:09 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mail2.ihtfp.org (Postfix) with ESMTP id D0376E2040; Tue, 23 Feb 2021 08:15:07 -0500 (EST)
Received: from mail2.ihtfp.org ([127.0.0.1]) by localhost (mail2.ihtfp.org [127.0.0.1]) (amavisd-maia, port 10024) with ESMTP id 10851-10; Tue, 23 Feb 2021 08:15:06 -0500 (EST)
Received: by mail2.ihtfp.org (Postfix, from userid 48) id 73B2EE2042; Tue, 23 Feb 2021 08:15:06 -0500 (EST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ihtfp.com; s=default; t=1614086106; bh=8od0f9SAmnQeCdQ4+rEm9bLHfOWFeiK9ymDxnJj0Rus=; h=In-Reply-To:References:Date:Subject:From:To:Cc; b=PJvcFdjrCLaUifYWuAi+9v9slmuo26X3gh9zrMcguaSOeg728m4z1irt1yur5wnWt 21R1RiR97A1IIweixJIViFs1QDNLWYiwRya/7t6jh91An3PGdUCZFHbb0HHefqGEcO WpF8ocH3w00OG2UCTP7kOVOgvi6BV48nKDXB8aCc=
Received: from 192.168.248.239 (SquirrelMail authenticated user warlord) by mail2.ihtfp.org with HTTP; Tue, 23 Feb 2021 08:15:06 -0500
Message-ID: <4f3d66b74b46b5b8bf27b5e1589bf80e.squirrel@mail2.ihtfp.org>
In-Reply-To: <7d8bdda1-4e5c-6c10-f3cd-1d191fad595c@nohats.ca>
References: <7d8bdda1-4e5c-6c10-f3cd-1d191fad595c@nohats.ca>
Date: Tue, 23 Feb 2021 08:15:06 -0500
From: "Derek Atkins" <derek@ihtfp.com>
To: "Paul Wouters" <paul@nohats.ca>
Cc: openpgp@ietf.org
User-Agent: SquirrelMail/1.4.22-14.fc20
MIME-Version: 1.0
Content-Type: text/plain;charset=utf-8
Content-Transfer-Encoding: 8bit
X-Priority: 3 (Normal)
Importance: Normal
X-Virus-Scanned: Maia Mailguard 1.0.2a
Archived-At: <https://mailarchive.ietf.org/arch/msg/openpgp/6KrTJw1U-u9N8MJ5LIcCbSc-PVY>
Subject: Re: [openpgp] I-D Action: draft-ietf-openpgp-crypto-refresh-02.txt (fwd)
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 Feb 2021 13:15:37 -0000

Hi,

Current text says:

   Implementations SHOULD generate V4 signatures.  Implementations MUST
   NOT create version 3 signatures; they MAY accept version 3
   signatures.

There is no MUST create version.  Is this intended to change?

Later (5.8):

   This packet is obsolete.  An implementation MUST NOT create this
   packet.  An implementation MAY process such a packet but it MUST
   return a clear diagnostic that a non-integrity protected packet has
   been processed.  The implementation SHOULD also return an error in
   this case and stop processing.

I'm confused by this text.  If an implementation chooses to process this
packet type (e.g. I have 20-year-old PGP-encrypted messages that I'd still
like to be able to read without re-encrypting them), why are you saying
that it should return an error and stop processing?  So it MAY process but
SHOULD stop processing?  I'm confused.

Those were the only issues I noticed reading through this version.

Thank you for your hard work!

-derek

On Mon, February 22, 2021 9:19 pm, Paul Wouters wrote:
>
> Hi,
>
> I pushed an updated version of the crypto refresh document:
>
> https://www.ietf.org/rfcdiff?url2=draft-ietf-openpgp-crypto-refresh-02
>
> I've also pushed the git changes to
> https://gitlab.com/openpgp-wg/rfc4880bis
>
>
> The commit on white space changes was reverted, as the WG will be
> re-opening that discussion later once we have all the consensus
> items from the previous 4880bis discussion re-published in this
> document.
>
> The following items were merged in:
>
> - Produce 4-level-deep ToC
> - Reserve codepoints in the registries
> - reorganize signature and asymmetric key value fields
> - Re-flow the v3 and v4 signature descriptions
> - Incorporated RFC 6637 (ECDSA and ECDH, using NIST curves)
> - textual cleanup (no substantive changes)
> - Update most registries to be SPECIFICATION REQUIRED
> - Deprecate v3 signatures
> - Deprecate non-integrity-protected encryption
> - Include SHA3
> - Incorporate Curve25519 for ECDH
> - Add ECC Point compression flag bytes appendix section
> - update reference RFC2434 to RFC8126
>
> Please review the changes and let the WG know of any issues you see.
> This includes if you think something was merged that did not have WG
> consensus.
>
> Paul
>
> _______________________________________________
> openpgp mailing list
> openpgp@ietf.org
> https://www.ietf.org/mailman/listinfo/openpgp
>


-- 
       Derek Atkins                 617-623-3745
       derek@ihtfp.com             www.ihtfp.com
       Computer and Internet Security Consultant