IETF Logo Mail Archive

Re: [COSE] draft-prorock-cose-post-quantum-signatures [Was: Re: Call for COSE Agenda Items for IETF 113 in Vienna]

Anders Rundgren <anders.rundgren.net@gmail.com> Fri, 11 March 2022 04:23 UTC

Return-Path: <anders.rundgren.net@gmail.com>
X-Original-To: cose@ietfa.amsl.com
Delivered-To: cose@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 33EA23A0896 for <cose@ietfa.amsl.com>; Thu, 10 Mar 2022 20:23:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.109
X-Spam-Level:
X-Spam-Status: No, score=-7.109 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, FREEMAIL_FROM=0.001, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_HI=-5, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 Ex88hDh38h1K for <cose@ietfa.amsl.com>; Thu, 10 Mar 2022 20:23:53 -0800 (PST)
Received: from mail-wr1-x42b.google.com (mail-wr1-x42b.google.com [IPv6:2a00:1450:4864:20::42b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DF53B3A0881 for <cose@ietf.org>; Thu, 10 Mar 2022 20:23:52 -0800 (PST)
Received: by mail-wr1-x42b.google.com with SMTP id r10so11141901wrp.3 for <cose@ietf.org>; Thu, 10 Mar 2022 20:23:52 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=message-id:date:mime-version:user-agent:from:subject:to:references :content-language:in-reply-to:content-transfer-encoding; bh=R70m0vNi9cIemWWbiuRRqtoVFtQ6RjfOrYiakMYxFlg=; b=Dj3UsQpFKwHqFMnKLOi1JNgmSuTiymkdmIIB/xnz/mTHQv78CL4JxupgZIOLh/LHKc POyV/3izRFFlMmaf707t2ulfyK8nq7EmbeoD+SreuF5yg64iqYt/mvDV/DJ8X07EZJQL ytud6jMRw/SAQSFJEOu/xh0LF4QLBEf8EcdhFuD26lpKYGjrv3+Ue28+2a0JdeFglHmT xs3u4ItjJwyADlc0JmdAYAXCO9MkOzub28CYs9DBcoz/kD/MHBCPs1IYWadwUeL3gUBM bqr57V85+5VZjEBvkJmtTAv7vaqP65VHWVwx/06XYFYoRbWxiEhHo/Gc+SC1rS0bb0ml Ml9g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent:from :subject:to:references:content-language:in-reply-to :content-transfer-encoding; bh=R70m0vNi9cIemWWbiuRRqtoVFtQ6RjfOrYiakMYxFlg=; b=gfz80vpTuoD/bpkDF4nBjfuK1UoI2f/JuE1NbIT34yGJTGQ2CXyAbiQ/ORvFRF36TS EDGKAcjb8sFpHsvxQY5ngq4UuSsqUD0ZMilEfB8MZNSwZF5Ld5WbwfxKsviGiP/G9XwJ W2OFP+uZDqRICcx09WFNOOzwD/cW+wOuRsZIBMPJ0QRCOXTiSAMk9b/0B08rupD0vrX+ jy5/aaoBIB0MWAHoD42Z5uPFloWYFg+JVDaEyTxOINHzIOVPS4u78BsZIXcozHjJS1lX TipX9MG5LENr8e98OAjHsm4TQ50Kx7NWQ+avUjeAXHuN4uaYvNkPORUjD5W4RRDBWmBb btbA==
X-Gm-Message-State: AOAM5331QfPnkaWTYpkUhvQy4wRyd9tKkHNURrkZnowYZpjrZ0gvDtsx 2psoW1SwI8w1FR5V+iEINFdO6FIyjh4=
X-Google-Smtp-Source: ABdhPJzeIrx856/PZZfSX5e8SdClvndIhAo/EOdPL4tXCJhRREYUZCOMyP9MqAFsQ2/KqVnAjOPang==
X-Received: by 2002:a5d:64e9:0:b0:203:72d0:48cf with SMTP id g9-20020a5d64e9000000b0020372d048cfmr5749429wri.163.1646972630478; Thu, 10 Mar 2022 20:23:50 -0800 (PST)
Received: from [192.168.1.67] (25.131.146.77.rev.sfr.net. [77.146.131.25]) by smtp.googlemail.com with ESMTPSA id r17-20020a05600c35d100b00389f368cf1esm38652wmq.40.2022.03.10.20.23.49 for <cose@ietf.org> (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 10 Mar 2022 20:23:49 -0800 (PST)
Message-ID: <40bf177b-9ac4-f1ed-db05-a0e8636a9363@gmail.com>
Date: Fri, 11 Mar 2022 05:23:48 +0100
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.6.2
From: Anders Rundgren <anders.rundgren.net@gmail.com>
To: "cose@ietf.org" <cose@ietf.org>
References: <SA2PR00MB1002092057CE9580A4029532F50B9@SA2PR00MB1002.namprd00.prod.outlook.com> <CAGJKSNSVuvmsdy9PmUGW7_a2kGqvAxW0fv+hOqSKE6ZfeagSWw@mail.gmail.com> <Yio968v//v87+fTH@LK-Perkele-VII2.locald>
Content-Language: en-US
In-Reply-To: <Yio968v//v87+fTH@LK-Perkele-VII2.locald>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/cose/-0hDXHJPBmzG1RvsmPXqZOn0ZOU>
Subject: Re: [COSE] draft-prorock-cose-post-quantum-signatures [Was: Re: Call for COSE Agenda Items for IETF 113 in Vienna]
X-BeenThere: cose@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: CBOR Object Signing and Encryption <cose.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/cose>, <mailto:cose-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/cose/>
List-Post: <mailto:cose@ietf.org>
List-Help: <mailto:cose-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/cose>, <mailto:cose-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 11 Mar 2022 04:23:59 -0000

Before deciding to overload "OKP" for a new crypto system, I would discuss the matter with maintainers of cryptographic libraries and APIs.

In the Java platform overloading the native counterparts to OKP keys [1,2] won't happen because that would break a lot.  I guess the same is valid for OpenSSL.

It seems to me that reusing OKP would rather create an artificial "semantic gap" which doesn't exist today where "kty" indeed is synonymous with key type/family (RSA, EC, Ed etc):
https://datatracker.ietf.org/doc/html/rfc7517#section-4.1


It is important to early on bring issues like this to a wider audience so we don't repeat the oddities we have seen in FIDO/COSE where EC signatures have different encodings and Ed25519 algorithm identifiers have different meanings.

Thanx,
Anders

1] https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/security/interfaces/EdECKey.html
2] https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/security/interfaces/XECKey.html

v2.8.7 | Report a Bug | By Email