Re: [jose] RFC 8037 "alg" quirkiness

Anders Rundgren <anders.rundgren.net@gmail.com> Sat, 19 September 2020 04:55 UTC

Return-Path: <anders.rundgren.net@gmail.com>
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 5D78C3A09C1 for <jose@ietfa.amsl.com>; Fri, 18 Sep 2020 21:55:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level:
X-Spam-Status: No, score=-2.099 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, SPF_HELO_NONE=0.001, SPF_PASS=-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=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 dKo435eSonC2 for <jose@ietfa.amsl.com>; Fri, 18 Sep 2020 21:55:52 -0700 (PDT)
Received: from mail-wm1-x329.google.com (mail-wm1-x329.google.com [IPv6:2a00:1450:4864:20::329]) (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 A26D23A09A8 for <jose@ietf.org>; Fri, 18 Sep 2020 21:55:51 -0700 (PDT)
Received: by mail-wm1-x329.google.com with SMTP id d4so7086428wmd.5 for <jose@ietf.org>; Fri, 18 Sep 2020 21:55:51 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=Cv7PUghwJbyX8Re7DAt7b9hGHB4ZP9jVcQunN6/0ngA=; b=Ni3n9NfqTFoZCYdFHX0ybiwV/+J33Q5GG625LClhVLJ/NxFMYQj/3YBvgraMCmVhNK MZo1fNUkPWRbPVk6BaoZhU72RZtDHwqsFxgKbgZAkCmAIysmgqKVD9z2sRnpdIS3uvFt v2fPsybOPYloqc3IfHi+s5a7oIRUObNtvMxKeedDt2cpFN2gZpv6Kf+9wX+pJnX6rEAQ 1J0APkXgRDv6eCA2UhoCaQYgsDoqrfhs3q0GE9zAIO0QPKarPRPyfASmdhW1DlpJF605 RGsVgRp6u6V3eebD2ZrZvV5x/oBNHNKODSdmo+MIZINltrZgSIFW6jlwLkAkfvdmg+ZI yh0w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=Cv7PUghwJbyX8Re7DAt7b9hGHB4ZP9jVcQunN6/0ngA=; b=OKIMrGodDAx9D5+ey4/LMiGpQLGUwFVm2EQJ1suPivMz9f1I5EuL/QSusEtG5e3vWg /BN7TEMzU6R0fSkso2DTON0l36rPF2ZrWKAlbwDBJhdrSR9GL05ljF1os/fowtay8//2 cLIUcqp+z8tCM8Ncn77PFjC3/zBXSegNxuzV4u2Xa4T0/+vMd4eUb5iNVyGj8BdD0F5s wVLvisjdzIo32NUj1n+nk0M19MIHNpS2lezXyK5yGk24I5HvcHjf0bCaklqDHANvMnPw onD7H5bR15gIo0r0+8kZngWzMhG/w5LqDFAF7aICGPkntt3ZWlnpv59WrJsW5fbyAOzm lFnw==
X-Gm-Message-State: AOAM5336YR0tkJbfRv0PLN6GyCcRxKo/Tz1VCnE5nLDvg96FI2xT3yn3 Aqxs5taS3WEDnG8NfgqW1simSYhopf1Gzw==
X-Google-Smtp-Source: ABdhPJyiY5unfqjmkIYCRdNtCmolooleVHqCuD+UcSjpqVRZZdB89sx0MMckd70CwiymT4VAFVfNTQ==
X-Received: by 2002:a05:600c:2215:: with SMTP id z21mr18485783wml.176.1600491349313; Fri, 18 Sep 2020 21:55:49 -0700 (PDT)
Received: from [192.168.1.79] (25.131.146.77.rev.sfr.net. [77.146.131.25]) by smtp.googlemail.com with ESMTPSA id 185sm9603283wma.18.2020.09.18.21.55.47 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 18 Sep 2020 21:55:48 -0700 (PDT)
To: Benjamin Kaduk <kaduk@mit.edu>
Cc: Ilari Liusvaara <ilariliusvaara@welho.com>, "jose@ietf.org" <jose@ietf.org>
References: <1a84f81d-c7bd-9961-9f5c-e6c358fc1095@gmail.com> <3B2FF2C4-44EB-4462-868E-C6DD1DD3F1CA@forgerock.com> <20200916123043.GB1653297@LK-Perkele-VII> <f8b75958-0461-a824-1de4-d50332e49f8c@gmail.com> <9403cfeb-40aa-8e85-3193-b403ff685168@gmail.com> <20200919040127.GK89563@kduck.mit.edu>
From: Anders Rundgren <anders.rundgren.net@gmail.com>
Message-ID: <7d046871-fa50-b96d-50bc-eb4a3fdd1c32@gmail.com>
Date: Sat, 19 Sep 2020 06:55:46 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.12.0
MIME-Version: 1.0
In-Reply-To: <20200919040127.GK89563@kduck.mit.edu>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/jose/hhiCDqYwAVlehQUCy4pHt1N3E-U>
Subject: Re: [jose] RFC 8037 "alg" quirkiness
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: Sat, 19 Sep 2020 04:55:53 -0000

On 2020-09-19 06:01, Benjamin Kaduk wrote:
> Hi Anders,

Hi Ben,

First off, this is just a comment to a Request For Comments :),
not a change request.

> 
> [The quoting seems to have gotten messed up; IIUC the context was the
> following]
> 
>>>> - In general, using the same key with multiple algorithms is not
>>>>      cryptographically safe. There can be algorithm pairs which interact
>>>>      badly (for instance, Ed25519 and the original Ed25519ph).

There is absolutely no disagreement with that but the rationale was as
I understand to make it more difficult to violate the above.  However,
this was not done for "EC" keys so it was effectively another strategy
within the same standard.  That MAY be called "quirk" in the same vein
as the multiple ways of representing binary data in JWS is.


> On Thu, Sep 17, 2020 at 07:02:09AM +0200, Anders Rundgren wrote:
>> Apparently the PKIX folks came to a different conclusion:
>>
>> https://tools.ietf.org/html/rfc8410#section-3
>>
>> "The same algorithm identifiers are used for identifying a public key,
>>    a private key, and a signature (for the two EdDSA related OIDs)."
> 
> I'm not seeing how that's inconsistent with one-algorithm-per-key -- you
> know from the context in which the OID appears whether you have a
> signature, public, or private key, and that context is used to namespace
> the following algorithm lookup.  Accordingly, there is no ambiguity as to
> what the OID means, in that context.

What I was trying to say, is that I find the PKIX naming more logical than
8037.  It is also aligned with Java 15/JCE which doesn't accept "EdDSA" as
a signature algorithm; it only understands Ed25519 and Ed448.

This became obvious in my JWS "remake" (JSF) where I adopted the PKIX
algorithm and key naming scheme:

   {
     "statement": "Hello signed world!",
     "otherProperties": [2e+3, true],
     "signature": {
       "algorithm": "Ed25519",
       "value": "nhYLrEcJV60sEG1RfZGrylL7oVvby1eNRMVzKn-ei93HrXq27e1bqsJpk0rkKg-l9TzTchPFigGt5QbVYirSBw"
     }
   }

Using EdDSA as algorithm in the example above would IMO look a bit strange.


Personally, I would also have considered using "EdDSA" and "ECDH" as "kty"
arguments rather than the somewhat esoteric "OKP" solution, but in the end
it all boils down to the quality of the library or application which should
be prepared for incorrect in-data.

I didn't follow this development when it was active because I wasn't ready
to take on curve25519 and curve448 since Oracle have taken EONS of time
to define the associated API.  It will finally be released this month!

Anders



> 
> -Ben
>