Re: [CFRG] OCB does not have an OID specified, that is a general problem

Phillip Hallam-Baker <phill@hallambaker.com> Tue, 08 June 2021 00:58 UTC

Return-Path: <hallam@gmail.com>
X-Original-To: cfrg@ietfa.amsl.com
Delivered-To: cfrg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 795E13A19BE for <cfrg@ietfa.amsl.com>; Mon, 7 Jun 2021 17:58:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.401
X-Spam-Level:
X-Spam-Status: No, score=-1.401 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.248, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no 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 5mcKidtgLHu8 for <cfrg@ietfa.amsl.com>; Mon, 7 Jun 2021 17:58:25 -0700 (PDT)
Received: from mail-yb1-f182.google.com (mail-yb1-f182.google.com [209.85.219.182]) (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 C9B993A19BA for <cfrg@irtf.org>; Mon, 7 Jun 2021 17:58:25 -0700 (PDT)
Received: by mail-yb1-f182.google.com with SMTP id f84so27778168ybg.0 for <cfrg@irtf.org>; Mon, 07 Jun 2021 17:58:25 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=GOFyZ7YbXdKr6vWwJh1htyzNFjZ2/TgJbV8cc/pfujo=; b=d25O0gbbyw7hvyI2IieFMHCq1OURDS1zSwHDtVKr31FlkIXJHzca73lcAx6CyF6nhs NhSPuc3H9Sui0hLy7ASvvqb2WuhW5SmrQ17XmhsuItQrP2Cfcm55uxBAbtnlu8GcBveU ZxzDYJieaxacGZfLsvFcxji+e40EaAKbTcMvp9DQkgYuD9DQLh4Vch2KOcoclVgvlYE+ wbIv0IgybmNsX4B8cLIWIx7HgtsysEgiSAzPmxdntCvlVB7lUnlYBx7XCMjJs0xhicFw Fh+1RdXhKclDYnjqlCs3zYQNu7RSbyCK8A3ghCGv1MELs1tZbkpBr5oVH7aJVgHDVZ2g dzVQ==
X-Gm-Message-State: AOAM530RDLBAj2Bwe8gjcLKLYY8HaN7H3e9rL2u2Cx38YCFxgylJOMiO KKgchnvYdXoTWislZHyrpHEXtKr3qYSUAt4RpXw=
X-Google-Smtp-Source: ABdhPJxJyzwuJWSK/1zvlcYVpbtk96mINRWhw11reFuPOGiDbuKGa3PcV6CZGdUsbGI3VtKr45J/i2AgDdWRpdfWSlY=
X-Received: by 2002:a05:6902:102a:: with SMTP id x10mr26147812ybt.213.1623113904559; Mon, 07 Jun 2021 17:58:24 -0700 (PDT)
MIME-Version: 1.0
References: <CAMm+Lwizfw6=T28gGOgeGZ=4CEHsQ5BoWcAt5mOWbyJHLVJmuQ@mail.gmail.com> <CE8CC19F-4D05-4E71-84E3-5087F3576E02@gmail.com>
In-Reply-To: <CE8CC19F-4D05-4E71-84E3-5087F3576E02@gmail.com>
From: Phillip Hallam-Baker <phill@hallambaker.com>
Date: Mon, 7 Jun 2021 20:58:12 -0400
Message-ID: <CAMm+LwgUwj8w-2k63PN7EkOQzrD1-QW+EsXwx_K8fgkZCp0HzA@mail.gmail.com>
To: Neil Madden <neil.e.madden@gmail.com>
Cc: IETF SAAG <saag@ietf.org>, IRTF CFRG <cfrg@irtf.org>
Content-Type: multipart/alternative; boundary="000000000000b61aed05c436a7be"
Archived-At: <https://mailarchive.ietf.org/arch/msg/cfrg/Xa_1V95k3RR10lW3wbvLpizNm1A>
Subject: Re: [CFRG] OCB does not have an OID specified, that is a general problem
X-BeenThere: cfrg@irtf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Crypto Forum Research Group <cfrg.irtf.org>
List-Unsubscribe: <https://www.irtf.org/mailman/options/cfrg>, <mailto:cfrg-request@irtf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/cfrg/>
List-Post: <mailto:cfrg@irtf.org>
List-Help: <mailto:cfrg-request@irtf.org?subject=help>
List-Subscribe: <https://www.irtf.org/mailman/listinfo/cfrg>, <mailto:cfrg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Tue, 08 Jun 2021 00:58:28 -0000

On Mon, Jun 7, 2021 at 10:02 AM Neil Madden <neil.e.madden@gmail.com> wrote:

> Unless there is a compelling reason to do so, I’d prefer that registering
> algorithm identifiers for JOSE be a manual (and rare) step. JOSE provides
> no way for consumers to advertise which Encryption Methods they support
> (“enc” - which is what OCB would be), so adding new options here can only
> harm interoperability.
>
> (This is in contrast to key agreement algorithms - “alg” - as these can be
> advertised in the JSON Web Key metadata).
>

I don't agree. JOSE has no algorithm negotiation mechanism because it is a
format, not a protocol. After we went through the whole
recommended/required algorithm thing on JOSE, it suddenly occurred to me
that this was precisely none of JOSE's business. It is for the protocols
and services built using XML Signature, JOSE, CMS etc. to decide what
algorithms to require and/or recommend.

JWK is a protocol built on top of JOSE, so it makes sense for that protocol
to specify recommended algorithms. But the recommendations made in the JOSE
spec have absolutely no bearing on the Mesh which uses parts of JOSE
because being written six years later, the state of the art has moved on.
The Mesh does not support RSA at all and the elliptic curve algs are X448
and Ed448. The curve 25519 versions are not supported for profile signing,
etc. etc.

I would expect the same to apply in the COSE world. Merely defining a code
point for JOSE or CMS does not make a statement about the algorithm
recommendation status. All it does is specify the one canonical identifier
every application will use. It is not at all important what that identifier
is (provided it is not an absurd length) it is critical that everyone use
the same identifier though.