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

Daniel Migault <> Fri, 23 October 2020 23:58 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 333EA3A0ADD; Fri, 23 Oct 2020 16:58:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Status: No, score=-2.097 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, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 3kXsKSd_PLwl; Fri, 23 Oct 2020 16:58:21 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::e2c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 4D81D3A0989; Fri, 23 Oct 2020 16:58:21 -0700 (PDT)
Received: by with SMTP id b129so1818509vsb.1; Fri, 23 Oct 2020 16:58:21 -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=Gdl7bdo1qBZmTwHjEn1LarHxZTgOLtR76Z95sXsZ1Fk=; b=mmS0KPDytmQ426YhbBk498ysL/Rwd51FQoZjqhaQop0M9ppYky04o3io85ZJDDzDyq LO3FFhyOZVPNv69cX7ZC8UT7QpJzRG5RYeslmv5L1wGEn0IVSWPhfsFQ8/i8JBPdm5WQ zxqeWxDYDcWEV4t+OIaDC4uyC/QSRM90kbQSpplN/jp883GAxwgRlYOxeIYQUsivi38y Ov9kv+W33PVLxI9uj0lOkov8UUOr1N9ih/Uu8WABVGxfHVIVfP0CWwRuxpUVwV92GyvN GQfa6THToxdqCfQFqrfaNnZsA+psGp/v69ZFAcLsQKKcJljxL3og5UFuDTFt0khpEIHb Kk3g==
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=Gdl7bdo1qBZmTwHjEn1LarHxZTgOLtR76Z95sXsZ1Fk=; b=k+zJ+had3HRH3IU4XWl+Sy5GGjLD3upYoJjm2Gy3KYeGA/2qRaz5bIiyDG7icuEowd Lg/Q69RxnSRvLl1m9oXz6C86z8OXzEeLS8T/a9tqO6z/H+h/p24VVllN8BpOUUsZOzH9 ISNUAoWE2wj5ygfyWAGYoQ9J9vyHh7nAZvZVpA84fOBcWJU30K5P40MsSawblK76+Mpa VHAZXflla8kLC+iCCyYXQpW0oxFW91KNv9wvEsoMVyBd7EaGvbu5jbGDGhwDlUTvM1hc PWnRVE5dPRVYBV2i6FaJ4x7UWPqQZkdGOYjbgdLzYgg+zhG4H6Kh+X/g6d8HnCaMatkL /0/A==
X-Gm-Message-State: AOAM531t31pk5B1MCLIjNnFZspMWS/dpquJ310vfzIwFEN9/SUORJ67M JWydOCGJyfBsozNj/ZnYd8LimA6tMJuSsIPhe2Ds4E2v46k=
X-Google-Smtp-Source: ABdhPJwq4o1NUv8K9W5hct/SRDJPgqdmSnevq5yUhqfOsTUs1GIBVQ6JCOyWtrIluTOvMRFE0FoB0t6BBniFiG0Bm0A=
X-Received: by 2002:a67:1e02:: with SMTP id e2mr4886937vse.40.1603497500188; Fri, 23 Oct 2020 16:58:20 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <> <> <>
In-Reply-To: <>
From: Daniel Migault <>
Date: Fri, 23 Oct 2020 19:58:09 -0400
Message-ID: <>
To: Francesca Palombini <>
Cc: =?UTF-8?Q?Christian_Ams=C3=BCss?= <>, "" <>, Ace Wg <>
Content-Type: multipart/alternative; boundary="000000000000e5a1b205b25f5aa9"
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: Fri, 23 Oct 2020 23:58:23 -0000

I am not hearing anyone opposing the proposed way to move forward. Once we
will have the update from Francesca, we will be able to start a WGLC. On
the other hand, we will need reviews to move the document forward, so
please remain committed for the last miles!


On Mon, Oct 19, 2020 at 4:45 PM Daniel Migault <> wrote:

> 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.
> Yours,
> Daniel
> 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
> Ericsson

Daniel Migault