Re: [Ace] OSCORE Profile status update and way forward

Daniel Migault <> Mon, 19 October 2020 20:45 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 4207C3A09C5; Mon, 19 Oct 2020 13:45:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.197
X-Spam-Status: No, score=-0.197 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id PltucxrwXlA8; Mon, 19 Oct 2020 13:45:33 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::92b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id BDD023A09C3; Mon, 19 Oct 2020 13:45:32 -0700 (PDT)
Received: by with SMTP id t15so278324ual.6; Mon, 19 Oct 2020 13:45:32 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=qRV5uxgjzns+jK1GtX7rbTgzT/FieDJuDqNmqBsDXBk=; b=BqaJ1KizXlpfcxYRFSl3/qnY0Hv1nxcAm+Qt56WFXDYKzN7zRNEH+xy3xr1OGQZeym aZBzq23BvJf2zWHGcx19jEp+VFxo3uThaZWyFCK5EGCSVZIl9n+WoqrJB6to/sQ96uTG 1a6aDl4YIxJmVdns2/WgUElO7ZkRUoBGB4rroQyBe9xI8S4AGiTaEJEUBEfF/7DYzwc/ lk6nix/YE5YUpTsqn4DpUNXDTGrp3PgW1JGj9smnYNQew/6tcuw/2tkJNi3iwFOL8emM mBcP0bzcWLHON90nA/RTT4pXUDOpPnZ65RoSm5QTTccMFveWnNxkFlO9HLCqox8WcBg5 6KAg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=qRV5uxgjzns+jK1GtX7rbTgzT/FieDJuDqNmqBsDXBk=; b=tpBBukg/8pAOU9lwmTI5bllF+jHKoxfl/YSSlritsIk3swnZPS47BAumRALwnqR+4n r14HQT9BXoPacyiGZyv9sP0EZIbbTnHtX80tacmkanFZXmGn+MSYbv3oY6WcGNTiP1AC duReZWU1ZqKKax2J56smVC+A//YTSvelF5oWYLJXmfyYKr+9BRtD1RV0U9JfLwDeITEK CbYz4JeL/vOmYzALH2Q/nhJuHrLeG6SzMUOZK0py8iPFlQgQAg9oj778oT3V8UfyyATp VEYUwNtQOCBS6+4mgWQPLA1FluYyaoVDWWQHQQW+FHOjrDUQT3nuz1Ggj8YvAsaR44MM 4csg==
X-Gm-Message-State: AOAM532Eaeo7pN9fYk2QlRlYwF8EBYMEYR9i1ThMfACbO2kK+oWwWULU z/MC2r2nHa/Z+7WqFJ1VV2qsg0eR2zKRtpSa1x+EmzIZkxI=
X-Google-Smtp-Source: ABdhPJypLT/H+OLV2pMCqiP7oEmFXo7990tmKDE8c0vFBeYcZ+uipyWR7LZuo8oIeZ6JUleGjKWAYr/OUWntwlyq5bo=
X-Received: by 2002:ab0:3a92:: with SMTP id r18mr759819uaw.42.1603140331614; Mon, 19 Oct 2020 13:45:31 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <> <>
In-Reply-To: <>
From: Daniel Migault <>
Date: Mon, 19 Oct 2020 16:45:20 -0400
Message-ID: <>
To: Francesca Palombini <>
Cc: =?UTF-8?Q?Christian_Ams=C3=BCss?= <>, "" <>, Ace Wg <>
Content-Type: multipart/alternative; boundary="000000000000fdb73f05b20c313d"
Archived-At: <>
Subject: Re: [Ace] OSCORE Profile status update and way forward
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 19 Oct 2020 20:45:34 -0000

Thanks Francesca for the reply. Other members of the WG, if you have an
opinion, please let the WG know asap. We set October 20 to get comments on
which path to take.


On Mon, Oct 19, 2020 at 11:52 AM Francesca Palombini <francesca.palombini=> wrote:

> Hi Christian, Daniel,
> Daniel: I agree that what you describe is the best way forward. Once the
> PR regarding the negotiation of Ids is merged, I can only see a minor
> addition to the draft, to clarify what Christian has brought up. By the end
> of this week we should have Christian's comment implemented as well. After
> that, we're ready for another round of reviews, and I think a WGLC is
> warranted.
> Christian, let us know if there is anything else except some more
> considerations covering what you are saying. Göran summarized it well, but
> basically no, there is no particular benefit. The sentence was added as the
> response from a review comment, but it seems like a good idea to add more
> context to it.
> Thanks,
> Francesca
> On 15/10/2020, 20:01, "Göran Selander" <>
> wrote:
>     Hi Christian,
>     The purpose of the update was to clarify that Appendix B.2 of RFC 8613
> could be used in conjunction with the ACE OSCORE profile. But as you point
> out, the use of B.2 would need to be understood between the client and
> server beforehand. There are slight differences: With B.2 there is no need
> to transport the access token again. And B.2 can be triggered by the
> (resource) server, if it understands that it does not have the right
> context (which can happen even if there is no ID context in the request).
> Just using the ACE OSCORE profile, the client would need to understand that
> the context is lost and run the protocol again. So, there is a difference
> but essentially the same functionality can be obtained.
>     Would it be sufficient to clarify the differences as above to address
> your comment?
>     Thanks,
>     Göran
>     On 2020-10-09, 17:45, "Christian Amsüss" <>
> wrote:
>         Hello Francesca, hello ACE group,
>         On Mon, Sep 21, 2020 at 01:48:33PM +0000, Francesca Palombini
> wrote:
>         > - clarified that Appendix B.2 of OSCORE can be used with this
> profile,
>         > and what implementers need to think about if they do.
>         I understand B.2 to be something that the involved parties need to
> agree
>         on beforehand; after all, the ID context may be something the
> server
>         relies on (at least for the initial attempt) to find the right key,
>         especially when multiple AS are involved. (For example, the RS
> could
>         have an agreement that the AS may issue any KID as long as they
> use a
>         particular ID context). If the server expects B.2 to happen
> (which, as
>         it is put now, it can as long as it supports it in general), it
> needs to
>         shard its KID space for the ASs it uses. (Generally, B.2 is
> mutually
>         exclusive with ID contexts's use of namespacing KIDs).
>         Is the expectation that clients that do not anticipate B.2 by the
> time
>         they are configured with their AS just don't offer B.2 to their
> peers?
>         Given B.2 is in its current form client-initiated only (AFAIR we
> had
>         versions where ID1 could be empty in draft versions, but currently
> it
>         reads as client-initialized), does B.2 have any benefits for
>         clients? After all, they could just as well post the token with a
> new
>         nonce1 to the same effect.
>         Kind Regards
>         Christian
>         --
>         To use raw power is to make yourself infinitely vulnerable to
> greater powers.
>           -- Bene Gesserit axiom
> _______________________________________________
> Ace mailing list

Daniel Migault