IETF Logo Mail Archive

Re: [jose] [COSE] COSE/JOSE elliptic curves and their relationship with key types

Michael Richardson <mcr+ietf@sandelman.ca> Wed, 21 July 2021 22:48 UTC

Return-Path: <mcr+ietf@sandelman.ca>
X-Original-To: jose@ietfa.amsl.com
Delivered-To: jose@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ABCA13A2D56; Wed, 21 Jul 2021 15:48:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 WXGgkUzE77UZ; Wed, 21 Jul 2021 15:48:01 -0700 (PDT)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 220C33A2D54; Wed, 21 Jul 2021 15:48:00 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 8CBC438A01; Wed, 21 Jul 2021 18:51:24 -0400 (EDT)
Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id BrskcZTliNjW; Wed, 21 Jul 2021 18:51:20 -0400 (EDT)
Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id A46EF389EC; Wed, 21 Jul 2021 18:51:20 -0400 (EDT)
Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 8393D54A; Wed, 21 Jul 2021 18:47:55 -0400 (EDT)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: cose@ietf.org, jose@ietf.org
In-Reply-To: <20210721182159.GI88594@kduck.mit.edu>
References: <20210707212059.GX17170@mit.edu> <21116.1625697755@localhost> <20210713034600.GJ17170@mit.edu> <31210.1626192377@localhost> <20210721182159.GI88594@kduck.mit.edu>
X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.1
X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m<nPbLgmtKK-5dC@#:k
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg="pgp-sha512"; protocol="application/pgp-signature"
Date: Wed, 21 Jul 2021 18:47:55 -0400
Message-ID: <20282.1626907675@localhost>
Archived-At: <https://mailarchive.ietf.org/arch/msg/jose/DEZWxXeHS7TvwhFwqBZNQB4KLV4>
Subject: Re: [jose] [COSE] COSE/JOSE elliptic curves and their relationship with key types
X-BeenThere: jose@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Javascript Object Signing and Encryption <jose.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/jose>, <mailto:jose-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/jose/>
List-Post: <mailto:jose@ietf.org>
List-Help: <mailto:jose-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/jose>, <mailto:jose-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 21 Jul 2021 22:48:06 -0000

Benjamin Kaduk <kaduk@mit.edu> wrote:
    >> As the thread between Neil and Ilari shows, there were reasons to make
    >> different choices.
    >>
    >> My take, being intentionally not intimate with such issues, is that the best
    >> encoding for using the key may not be the best encoding for transmitting the
    >> key.   That the translation between the two forms might sometimes fail, and

    > This sounds like you are in favor of allowing multiple "kty" values?

Uhm, I'm not sure I think that.
I think that I said that it could be that need to accomodate different
encodings.  I didn't think that they would both be present.

    >> so it's a protocol decision as to which to transmit, which to sign (in a
    >> certificate), etc.
    >> (And that this was the entire lwig-curves document's point)

    > FWIW, my understanding is that if the translation fails then the point/key
    > is malformed anyway and should not be used.

I guess translation fails, means there is a non-sense operation in the
middle, like divide-by-zero or infinity?  That is, it can be detected.

I agree that this is true for Ecliptic Point algorithms that we currently use.
It could be (I have no knowledge here) that this isn't always the case.
Could the translation fail, but result in what syntatically looks right, but
it just always fails to validate a signature?
Is that distinguishable from the case where Mallory toggles some bits?

--
Michael Richardson <mcr+IETF@sandelman.ca>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide

v2.23.0 | Report a Bug | By Email