Jim, Ben,
Jim Schaad writes:
[decrypted access_token as HKDF input]
>> Now you have lost me. The innermost COSE wrapping layer would be the one in
>> the contents of the cnf claim, given that we do not invent claims that also
>> can
>> include COSE structures?
>
> Yes this is the binary
> -Original Message-
> From: Olaf Bergmann
> Sent: Wednesday, July 1, 2020 1:25 AM
> To: Jim Schaad
> Cc: 'Benjamin Kaduk' ; 'Carsten Bormann' ;
> ace@ietf.org; draft-ietf-ace-dtls-authorize@ietf.org
> Subject: Re: [Ace] AD review of draft-ietf-ace-dtls-aut
On Wed, Jul 01, 2020 at 10:25:27AM +0200, Olaf Bergmann wrote:
> Hi Jim,
>
> Jim Schaad writes:
>
> > If you are not doing a re-encoding of the token, then I believe that
> > preferred serialization and deterministic serialization are going to
> > generate the same answer. With the map being
Hi Jim,
Jim Schaad writes:
> If you are not doing a re-encoding of the token, then I believe that
> preferred serialization and deterministic serialization are going to
> generate the same answer. With the map being used then this is not
> true, and it is also true that the change in map
Hi Olaf,
On Tue, Jun 30, 2020 at 12:19:41PM +0200, Olaf Bergmann wrote:
> Hi Ben,
>
> Thank you for the quick followup and another set of very useful
> comments. I have created a working copy with updates as listed
> inline. If you want me to, I can submit these as -12.
If it's easy for you,
> -Original Message-
> From: Benjamin Kaduk
> Sent: Tuesday, June 30, 2020 9:25 AM
> To: Carsten Bormann
> Cc: Olaf Bergmann ; draft-ietf-ace-dtls-
> authorize@ietf.org; ace@ietf.org
> Subject: Re: [Ace] AD review of draft-ietf-ace-dtls-authorize-09
>
>
Carsten Bormann writes:
>>>
>>> I would generally prefer to avoid the need for deterministic/canonical
>>> encoding — is there really a need to re-encode the token?
>>
>> There is no need to re-encode the token, and I do not expect that this
>> would happen if the authorization server has used
>>
>> I would generally prefer to avoid the need for deterministic/canonical
>> encoding — is there really a need to re-encode the token?
>
> There is no need to re-encode the token, and I do not expect that this
> would happen if the authorization server has used a finite length.
So would we
Carsten Bormann writes:
> On 2020-06-30, at 12:19, Olaf Bergmann wrote:
>>
>> NEW:
>>
>> All CBOR data types are encoded in canonical CBOR as defined in
>> Section 3.9 of {{RFC7049}}. This implies in particular that the
>> `type` and `L` components use the minimum length encoding
>
>
On Tue, Jun 30, 2020 at 04:21:34PM +0200, Carsten Bormann wrote:
> On 2020-06-30, at 12:19, Olaf Bergmann wrote:
> >
> > NEW:
> >
> > All CBOR data types are encoded in canonical CBOR as defined in
> > Section 3.9 of {{RFC7049}}. This implies in particular that the
> > `type` and `L`
On 2020-06-30, at 12:19, Olaf Bergmann wrote:
>
> NEW:
>
> All CBOR data types are encoded in canonical CBOR as defined in
> Section 3.9 of {{RFC7049}}. This implies in particular that the
> `type` and `L` components use the minimum length encoding
Note that 7049bis, which has been
Hi Ben,
Thank you for the quick followup and another set of very useful
comments. I have created a working copy with updates as listed
inline. If you want me to, I can submit these as -12.
Benjamin Kaduk writes:
> Hi Olaf,
>
> Thanks for the updated -11!
> Some minor replies below, though in
Hi Olaf,
Thanks for the updated -11!
Some minor replies below, though in general the proposals look good.
On Thu, Jun 18, 2020 at 02:38:32PM +0200, Olaf Bergmann wrote:
> Hi Benjamin,
>
> Benjamin Kaduk writes:
>
> > Thanks! I think we will probably need an -11 fairly soon, though, given
> >
Hi Benjamin,
Benjamin Kaduk writes:
> Thanks! I think we will probably need an -11 fairly soon, though, given
> the remaining comments I have.
We have just submitted -11 that addresses your comments. See below for
detailed responses. I have trimmed-down the email thread context a bit
to
On Wed, May 13, 2020 at 06:18:25PM +0200, Olaf Bergmann wrote:
> Hi Ben,
>
> Benjamin Kaduk writes:
>
> > Please go ahead and upload a new version to the datatracker when you get a
> > chance; I do have some further comments below.
>
> Thanks again for the detailed response. I have just
Hi Ben,
Benjamin Kaduk writes:
> Please go ahead and upload a new version to the datatracker when you get a
> chance; I do have some further comments below.
Thanks again for the detailed response. I have just submitted version
-10 that includes changes to your previous comments as well as the
Hi Benjamin,
Benjamin Kaduk writes:
> Please go ahead and upload a new version to the datatracker when you get a
> chance; I do have some further comments below.
Thank you very much for the quick reply. I will submit -10 based on
your comments shortly.
Grüße
Olaf
Hi Olaf,
Please go ahead and upload a new version to the datatracker when you get a
chance; I do have some further comments below.
On Tue, Apr 14, 2020 at 06:20:38PM +0200, Olaf Bergmann wrote:
> Ben,
>
> Thanks again for the thorough review of the ACE DTLS profile and my
> sincere apologies
Ben,
Thanks again for the thorough review of the ACE DTLS profile and my
sincere apologies for the long time it took to process. Please find our
comments inline. As this comprises a lot of changes, the proposed text
already has been included in the Editor's copy [1]. Our proposals for
new text
-Original Message-
From: Benjamin Kaduk
Sent: Thursday, January 9, 2020 1:22 PM
To: Jim Schaad
Cc: 'Olaf Bergmann' ;
draft-ietf-ace-dtls-authorize@ietf.org; ace@ietf.org
Subject: Re: [Ace] AD review of draft-ietf-ace-dtls-authorize-09
On Thu, Jan 09, 2020 at 12:52:56PM -0800
> > > Sent: Monday, January 6, 2020 2:03 AM
> > > To: Jim Schaad
> > > Cc: ace@ietf.org; 'Benjamin Kaduk' ;
> > > draft-ietf-ace-dtls-authorize@ietf.org
> > > Subject: Re: [Ace] AD review of draft-ietf-ace-dtls-authorize-09
> > >
>
-Original Message-
From: Benjamin Kaduk
Sent: Thursday, January 9, 2020 12:27 PM
To: Jim Schaad
Cc: draft-ietf-ace-dtls-authorize@ietf.org; ace@ietf.org
Subject: Re: AD review of draft-ietf-ace-dtls-authorize-09
On Fri, Jan 03, 2020 at 08:36:54PM -0800, Jim Schaad wrote
-Original Message-
From: Benjamin Kaduk
Sent: Thursday, January 9, 2020 12:17 PM
To: Olaf Bergmann
Cc: Jim Schaad ; ace@ietf.org;
draft-ietf-ace-dtls-authorize@ietf.org
Subject: Re: [Ace] AD review of draft-ietf-ace-dtls-authorize-09
On Thu, Jan 09, 2020 at 12:32:40PM +0100
On Fri, Jan 03, 2020 at 08:36:54PM -0800, Jim Schaad wrote:
>
>
> -Original Message-
> From: Benjamin Kaduk
> Sent: Thursday, January 2, 2020 3:40 PM
> To: draft-ietf-ace-dtls-authorize@ietf.org
> Cc: ace@ietf.org
> Subject: AD review of draft-ietf-ace-dtls-
org; 'Benjamin Kaduk' ;
> > draft-ietf-ace-dtls-authorize....@ietf.org
> > Subject: Re: [Ace] AD review of draft-ietf-ace-dtls-authorize-09
> >
> > Jim,
> >
> > Jim Schaad writes:
> >
> > [Ben's review]
> >> We also are potentially in vi
Hi Jim,
Jim Schaad writes:
> -Original Message-
> From: Ace On Behalf Of Olaf Bergmann
> Sent: Monday, January 6, 2020 2:03 AM
> To: Jim Schaad
> Cc: ace@ietf.org; 'Benjamin Kaduk' ;
> draft-ietf-ace-dtls-authorize@ietf.org
> Subject: Re: [Ace] AD review o
-Original Message-
From: Ace On Behalf Of Olaf Bergmann
Sent: Monday, January 6, 2020 2:03 AM
To: Jim Schaad
Cc: ace@ietf.org; 'Benjamin Kaduk' ;
draft-ietf-ace-dtls-authorize@ietf.org
Subject: Re: [Ace] AD review of draft-ietf-ace-dtls-authorize-09
Jim,
Jim Schaad writes
Jim,
Jim Schaad writes:
[Ben's review]
> We also are potentially in violation of the framework's requirements with
> respect to the independent selection of profiles for client/AS and client/RS
> interactions -- at present, when DTLS+RPK is used for client/RS, we require
> that DTLS+RPK is
-Original Message-
From: Benjamin Kaduk
Sent: Thursday, January 2, 2020 3:40 PM
To: draft-ietf-ace-dtls-authorize@ietf.org
Cc: ace@ietf.org
Subject: AD review of draft-ietf-ace-dtls-authorize-09
Hi all,
Some high-level remarks before delving into the section-by-section
comments
Hi all,
Some high-level remarks before delving into the section-by-section
comments:
This document is pretty clearly DTLS 1.2-specific -- it talks about
particular protocol messages, message fields, and cipher suites that
simply do not apply to DTLS 1.3. In order to use this profile with DTLS
30 matches
Mail list logo
