Re: [Openpgp-dt] v5 keys and hardware tokens (issue #63)

NIIBE Yutaka <gniibe@fsij.org> Wed, 16 March 2022 12:18 UTC

Return-Path: <gniibe@fsij.org>
X-Original-To: openpgp-dt@ietfa.amsl.com
Delivered-To: openpgp-dt@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A845D3A1833 for <openpgp-dt@ietfa.amsl.com>; Wed, 16 Mar 2022 05:18:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.108
X-Spam-Level:
X-Spam-Status: No, score=-2.108 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, T_SCC_BODY_TEXT_LINE=-0.01] 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 AUcGSwuLbaRK for <openpgp-dt@ietfa.amsl.com>; Wed, 16 Mar 2022 05:18:23 -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 E92DF3A182E for <openpgp-dt@ietf.org>; Wed, 16 Mar 2022 05:18:22 -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:In-reply-to:Subject:Cc: To:From:References: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=PDqOHkpCcDkwiGX+iV2PpvKQ9WWi1IU8lV/CbnSioZY=; b=bQ/qOul9iuoIXxNIE1RJZ+N9GP 7ulk2XJCkgOXSGcnrRGsVMBNKwo87VvMkj6dkGoLWFvzq5+usfO+O03pXeNpgXoXgYLgqE75mB91d tbPMo226dYxor+zlPZNEcfJLopaFX8+k9FOCq9Ji3KAzNZc/5MS3WFM3GseKPlLOE3nERl1ePLR+a TGCczMrKMvvnfpblGQdw63EsphjUqvQM+fJ2VjaLEibI4TBtYYYhZkf3l+W4w1nfYOe7PmGg4VjQR zENpcZPh6Yy37r7YcM8op09WLWaLeXoh5f5bv/AVEvUooeEXxZ1HZqSbwZ1mFcWrnvFDf2047zZ+b aVG7svKQ==;
Received: from al182064.dynamic.ppp.asahi-net.or.jp ([111.234.182.64] helo=localhost) by akagi.fsij.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from <gniibe@fsij.org>) id 1nUSbb-0006F3-32; Wed, 16 Mar 2022 13:18:19 +0100
References: <87sfrqthre.fsf@fifthhorseman.net>
User-agent: mu4e 1.4.15; emacs 27.1
From: NIIBE Yutaka <gniibe@fsij.org>
To: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
Cc: openpgp-dt@ietf.org
In-reply-to: <87sfrqthre.fsf@fifthhorseman.net>
Date: Wed, 16 Mar 2022 21:18:14 +0900
Message-ID: <87ee32ozuh.fsf@jumper.gniibe.org>
MIME-Version: 1.0
Content-Type: text/plain
Archived-At: <https://mailarchive.ietf.org/arch/msg/openpgp-dt/3cuuJYbECT-P96AU_ioRjiv1l-o>
Subject: Re: [Openpgp-dt] v5 keys and hardware tokens (issue #63)
X-BeenThere: openpgp-dt@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OpenPGP working group design team <openpgp-dt.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/openpgp-dt>, <mailto:openpgp-dt-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/openpgp-dt/>
List-Post: <mailto:openpgp-dt@ietf.org>
List-Help: <mailto:openpgp-dt-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/openpgp-dt>, <mailto:openpgp-dt-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 16 Mar 2022 12:18:28 -0000

Hello,

Daniel Kahn Gillmor wrote:
> The public keys data for each of these three secret keys can typically
> be extracted from the card, but they will be the raw public key
> material, not stored in full OpenPGP format.

Right.  Only raw public key material is available, it's not in OpenPGP
format.

> Some cards may not be able to produce the full raw public key material
> available, or may have it wrong, somehow. Or maybe it's expensive to
> retrieve?  (when/why is it not available?)

For all OpenPGP card implementations (I know of), after user generates
or loads key on smartcard, public raw key material is always avaiable.
I don't know any implementation which can not retrieve raw key material.

>  - arbitrary-length field of "URL", which is intended to point to a place to download the full certificates

For GnuPG, a user can do:

    gpg --card-edit -> fetch

to retrieve OpenPGP key from the URL.  (It was useful before WKD.)
It's because there is no (defined) space on card to store OpenPGP key.


> As v5 fingerprints are 32 octets, not 20 octets, they don't fit nicely
> on these cards.

Yes.

> As i understand it, the biggest concern we have is that some
> applications rely on the fingerprint field from the card in order to
> retrieve the OpenPGP fingerprint from the network.  Presumably this is
> donen because extracting the public key material from the card to create
> an OpenPGP public key and thereby derive the fingerprint is not always
> possible.

If we can assume some constants (like ECDH KDF parameters), OpenPGP
fingerprint can be derived with raw public key material plus timestamp.
When I tested in the past (in 2019) for v5 key, I did that.
--