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

NIIBE Yutaka <gniibe@fsij.org> Fri, 26 March 2021 06:24 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 024AD3A1201 for <openpgp@ietfa.amsl.com>; Thu, 25 Mar 2021 23:24:20 -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 aZ1hzs5Bylvj for <openpgp@ietfa.amsl.com>; Thu, 25 Mar 2021 23:24:15 -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 DF0C33A11D9 for <openpgp@ietf.org>; Thu, 25 Mar 2021 23:24:14 -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=Y/8aGM57Yi7h6WOtCkJZZFusicN7uRpT5f0q/B2t7W8=; b=YgGXrHrlrGbFMIm5CiLJkHKLLN RHa2ryrX9AkCtGElBNILmdm3WTSaZLsofhI+mmJuTToAnnxqLhJYyAR5Z7EevswiOM6b85lTbPv59 dAcvyiCpt4OjUrS0XWXh1l8VeC7ai4TGarx4k/KkcIKvgLiWwDcwEWskJ0mKvw9BNYG5ZaZ66yERJ 2h8pUAj07GKXz/CZD1HG67bIuaUq3b0B2qCTHsMIoY4yQkRqMAr3jxA5ECUDy/iKBvQ7eu0a8RAw4 VlGB4yKdYRDf1Q9ThKpqtjEjQRGxZ/8OIP2cMhkfZzwnb8fXfD9AGcYCvXq4D5lyCOEGvxbtrWl3i 6sX1tBRQ==;
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 1lPft7-00045M-CR; Fri, 26 Mar 2021 07:24:06 +0100
Received: by iwagami.gniibe.org (sSMTP sendmail emulation); Fri, 26 Mar 2021 15:24:00 +0900
From: NIIBE Yutaka <gniibe@fsij.org>
To: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
Cc: openpgp@ietf.org
In-Reply-To: <87eeg42gti.fsf@fifthhorseman.net>
References: <87eeg42gti.fsf@fifthhorseman.net>
Date: Fri, 26 Mar 2021 15:24:00 +0900
Message-ID: <87im5ebfgf.fsf@iwagami.gniibe.org>
MIME-Version: 1.0
Content-Type: text/plain
Archived-At: <https://mailarchive.ietf.org/arch/msg/openpgp/nF55-PpZsYmRugwTJnvq6ey2DTU>
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, 26 Mar 2021 06:24:20 -0000

Hello,

Daniel Kahn Gillmor <dkg@fifthhorseman.net> wrote:
> IIUC, SOS is basically intended as a genericization of MPI; it
> represents its length in a two-vector scalar as (8*octet-count) instead
> of as (bit-count).  It "fits" where MPI fits, but doesn't require
> leading-zero removal, or require interpretation as an integer at all.

Sorry, I was not able to describe SOS accurately, in detail.

In the implementation of SOS in GnuPG 2.3-beta, it is mixture of two;
One case is with bit-count and another case is with 8*octet-count.
Former is used when there is no problem of leading-zero removal.  Latter
is used to ensure no removal of leading zeros.

>  a) Introduce SOS and apply it to existing ECC pubkeys.

My (not-so-strong) proposal is to introduce SOS data type, and apply it
for ECC (pubkey or ephemeral key, signature, and secret), so that we can
explicitly require no removal of leading zeros to allow fixed-size data.

Implementations will have to handle new representation with leading
zeros (when interpreted as an MPI).  Actually, many already do when
reading data.

I think that we cannot remove the existing mess from implementations,
when we need to support existing data.

What I pursued was to clarify the mess with possible improvement by the
specification.

The benefit of this approach is:

    Minimum impact to the specification and implementations.

    Compatibility, possibly encouraging better interoperability for
    existing corner-cases (of Ed25519 and ECDH with Curve25519).

    Flexibility, for new curves, no extra definition will be needed.

But, I know that describing existing data of Ed25519 as weird MPI
representation acculately ... would be difficult in a specification.

So, I don't insist much for applying SOS idea in the specification.  For
some implementers, it would work as a technical guidance for
interoperability to interpret existing OpenPGP data with Ed25519.


Well, nevertheless, I believe that it's good to introduce a new distinct
data type (if not SOS) for opaque octet string, if possible.  It will be
useful to be friendly to not-yet-standardized things.
--