Re: [openpgp] Algorithm-specific data: problems with Simple Octet Strings, and possible alternatives

NIIBE Yutaka <gniibe@fsij.org> Fri, 02 April 2021 03:20 UTC

Return-Path: <gniibe@fsij.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 9C6673A2EF5 for <openpgp@ietfa.amsl.com>; Thu, 1 Apr 2021 20:20:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 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_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fsij.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 BNSlOcvX_2PD for <openpgp@ietfa.amsl.com>; Thu, 1 Apr 2021 20:20:51 -0700 (PDT)
Received: from akagi.fsij.org (akagi.fsij.org [217.70.189.144]) (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 7B6753A2EF4 for <openpgp@ietf.org>; Thu, 1 Apr 2021 20:20:51 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=fsij.org; s=main; h=Content-Type:MIME-Version:Message-ID:Date:References:In-Reply-To: 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=SXhioxe/BamHDatCcQTEJ6EcZvguGCFklowNguGkQSQ=; b=hYhs6DhJF7ecPaOh7JnYWTglvg w8sKdzvyNYFT/MeW7n1BfWwunmqHMEiebK00qPqph6L+lCEVr+ZGCEGedw8K9k/+P6B2WG9yFLls9 vb9YFPA2CnH/FLRL6hIDVvqJiGTESoC5VzEaGHmuXoyWInmJBF4TKFbzwLXVirK6ywHD56gf3ifv/ 4jRoITbwX+lGzzh/aeluz8FHJivFWgqNwrpH8ozaxvIEkqLFgMR6ZbVm5WiEbI5ij177HTqhydTcn sFN/n4TNC68SyPQVby/qcKRby7ysN6Kjn8fytV8a2kiOAaW2kvcePMPtAvxalzohL7VlxgyOF/A8R rOYRd0Eg==;
Received: from m014008080161.v4.enabler.ne.jp ([14.8.80.161] helo=iwagami.gniibe.org) by akagi.fsij.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from <gniibe@fsij.org>) id 1lSAMY-0008CR-Gi; Fri, 02 Apr 2021 05:20:47 +0200
Received: by iwagami.gniibe.org (sSMTP sendmail emulation); Fri, 02 Apr 2021 12:20:41 +0900
From: NIIBE Yutaka <gniibe@fsij.org>
To: Florian Weimer <fw@deneb.enyo.de>
Cc: openpgp@ietf.org
In-Reply-To: <875z1awebr.fsf@mid.deneb.enyo.de>
References: <87eeg42gti.fsf@fifthhorseman.net> <87im5ebfgf.fsf@iwagami.gniibe.org> <87r1jypfbc.fsf@jumper.gniibe.org> <875z1awebr.fsf@mid.deneb.enyo.de>
Date: Fri, 02 Apr 2021 12:20:41 +0900
Message-ID: <87r1jtwewm.fsf@iwagami.gniibe.org>
MIME-Version: 1.0
Content-Type: text/plain
Archived-At: <https://mailarchive.ietf.org/arch/msg/openpgp/O6m1ixeNmFlQsspuq9RXQynSHos>
Subject: Re: [openpgp] Algorithm-specific data: problems with Simple Octet Strings, and possible alternatives
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: Fri, 02 Apr 2021 03:20:57 -0000

Florian Weimer <fw@deneb.enyo.de> wrote:
> Let me note again that zero-stripping for MPIs affects RSA as well and
> makes OpenPGP inconsistent with its normative references.

I think that you mean "Algorithm-Specific Fields for RSA signatures"
in RFC 4880.

"RSA signature value m**d mod n" may be interpreted as "an integer
signature representative s" in "RSA signature" in RFC 3447 (now RFC
8017), I mean, the small "s" (instead of large S = I2OSP (s,k)).

It is a bit difficult interpretation (but not impossible).

Otherwise, I agree that it's inconsistent.
--