From nobody Mon Aug 3 23:11:44 2020 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A2DA3A0EA3 for ; Mon, 3 Aug 2020 23:11:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001] autolearn=ham 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 gf4kfeQ3qF9f for ; Mon, 3 Aug 2020 23:11:40 -0700 (PDT) Received: from weald2.air.saab.se (weald2.air.saab.se [136.163.212.4]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 122D13A0EA1 for ; Mon, 3 Aug 2020 23:11:38 -0700 (PDT) Received: from mailhub2.air.saab.se ([136.163.213.5]) by weald2.air.saab.se (8.14.4/8.14.4) with ESMTP id 0746BZlq012733 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Tue, 4 Aug 2020 08:11:36 +0200 DKIM-Filter: OpenDKIM Filter v2.11.0 weald2.air.saab.se 0746BZlq012733 Received: from corpappl16349.corp.saab.se (corpappl16349.corp.saab.se [10.12.12.112]) by mailhub2.air.saab.se (8.13.8/8.13.8) with ESMTP id 0746BVEC014004 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Tue, 4 Aug 2020 08:11:31 +0200 Received: from corpappl16595.corp.saab.se (10.12.12.127) by corpappl16349.corp.saab.se (10.12.12.112) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1979.3; Tue, 4 Aug 2020 08:11:31 +0200 Received: from corpappl16595.corp.saab.se ([fe80::3c3e:6470:4c56:a86f]) by corpappl16595.corp.saab.se ([fe80::3c3e:6470:4c56:a86f%4]) with mapi id 15.01.1979.003; Tue, 4 Aug 2020 08:11:30 +0200 From: Seitz Ludwig To: "ace@ietf.org" Thread-Topic: PoP tokens, mandatory or not in ACE? Thread-Index: AdZqJCyUezTBkcwySvuFA47tyavPMw== Date: Tue, 4 Aug 2020 06:11:30 +0000 Message-ID: Accept-Language: en-SE, sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.12.13.198] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Saab-MailScanner-Information: Please contact the ISP for more information X-Saab-MailScanner-ID: 0746BVEC014004 X-Saab-MailScanner: Found to be clean X-Saab-MailScanner-SpamCheck: not spam, SpamAssassin (not cached, score=-1.5, required 5, autolearn=not spam, ALL_TRUSTED -1.00, BAYES_05 -0.50) X-Saab-MailScanner-From: ludwig.seitz@combitech.se X-Saab-MailScanner-Watermark: 1597126291.59369@onfKwMf66raBq8obxPRtPg X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.6.2 (weald2.air.saab.se [136.163.212.4]); Tue, 04 Aug 2020 08:11:36 +0200 (CEST) Archived-At: Subject: [Ace] PoP tokens, mandatory or not in ACE? X-BeenThere: ace@ietf.org 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: Tue, 04 Aug 2020 06:11:42 -0000 Hello ACE, As a follow-up on a discussion between the authors and the Gen-ART Last Cal= l reviewer we have the following issue I'd like to bring to the list to giv= e you the occasion to comment on our proposed solution: > * In the previously mentioned paragraph in 3.3.1: > > ... This > specification assumes that the access token is a PoP token as > described in [I-D.ietf-ace-oauth-authz] unless specifically stated > otherwise. > > The "unless specifically stated otherwise" is too vague to be normative.= =20 > How would the alternative be indicated? Is this an escape hatch for futur= e extensions? If so, it needs more work to make that clear and to open a pa= th for that > future work. In response, Ben Kaduk suggested to make PoP tokens mandatory in both the f= ramework and the profiles. I objected saying that there may be legitimate u= se cases for bearer tokens in ACE. Steffi made the following suggestion, wh= ich both Ben and me think is the best way forward: > Since no alternatives to PoP tokens are mentioned in the DTLS profile, I = would change this to: "This specification implements access tokens as proof= -of-possession=20 > tokens". > > Maybe the framework may add that a profile that uses a different token ty= pe must specify how this would work. If you disagree with this approach please join the discussion. Regards, Ludwig -- Ludwig Seitz Infrastructure Security Analyst=20 Combitech AB From nobody Wed Aug 5 09:39:16 2020 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 578563A0ABB; Wed, 5 Aug 2020 09:39:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: 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=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 sV5bpsAqeWfr; Wed, 5 Aug 2020 09:39:13 -0700 (PDT) Received: from mail-vk1-xa34.google.com (mail-vk1-xa34.google.com [IPv6:2607:f8b0:4864:20::a34]) (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 974B43A0A9B; Wed, 5 Aug 2020 09:39:13 -0700 (PDT) Received: by mail-vk1-xa34.google.com with SMTP id x142so6849180vke.0; Wed, 05 Aug 2020 09:39:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=IJu+hHpSSfUv1s3oUFRtgUBep2kfkFhMLwldmxtf8m8=; b=oEPqc+ojgCbBV0ldklcdnEBfcf6w1OOPnbo3kkxhQz6gdymbur19TCFkaE4RbPET+R SKMPPXJjkdGrTC2p4pJNwZaJmZaDQW7wDHr7yqQO177kUGnPVc1tjJsPscLB3B71xRoW SouiVKu/ao62LozU95PLbnHQymMxQSBnHhOxEKcANKvHzabSCDVuRTJR4MhAmslDD1a+ pp+N1XBw7vct/lPH0/OdqS9+DeQUhMwDKpePkZ1fabYOdYYWaWEjLziFasYqFy7jNgl5 vdsKcToezIzoPDt8OkmV6+bQR4u1Iz6UeHZJDxkEp3tvdGkwZheBj77MZHWfBWG2JWzO a2bw== 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; bh=IJu+hHpSSfUv1s3oUFRtgUBep2kfkFhMLwldmxtf8m8=; b=VtqPeN6CGxOmDbtTyIxlwsOH/yzOR9ug+3pEgmuW355ScXlgzPPKT2XodcM+a+YDcz ExNI3EWynU1bygNUSbsib3BtdyJd+I9H70irfAl7XZZeceWOwIWgE221yE+X/cOsJL9B RPJqDj03HL7AbgChvYdS3M72hxMcWYrDLLO73d7Oz/H/P21hNSQbJ7mdrgmdNqOy6d10 FOnvecn4Kk0JpWyhGTBVsRJIacPcpfOoPXHgc87UJIcnx0A9t0/uUEY4c44zVZ/+WqF5 WCCEh9xkMbsSAtOmEGOfEILPHycnPczoCiMnsKcgLidkP2Pg0PoCrhGJJDyyOrfukquR C2Lw== X-Gm-Message-State: AOAM532IC1dpK7a6rSemORpSFl8DkB6mg0X54JrE361W5kqQO/9PjRoQ lN4RVZIcC7xaCIJOr/mAWlE6XsX2WI7AyJbzAIAtcA== X-Google-Smtp-Source: ABdhPJwzEIWBWDVXQdbOyaVn9Dv0A9b5blfTAx285cCUZLqTa9vijOvzEnUJ1Q51q+YhU777jbHIPFr/tlYUfNX2vE4= X-Received: by 2002:a1f:d642:: with SMTP id n63mr3311767vkg.77.1596645552068; Wed, 05 Aug 2020 09:39:12 -0700 (PDT) MIME-Version: 1.0 References: <39C59343-D873-4282-8BD2-A5B6A659B3A0@ietf.org> In-Reply-To: <39C59343-D873-4282-8BD2-A5B6A659B3A0@ietf.org> From: Daniel Migault Date: Wed, 5 Aug 2020 12:39:01 -0400 Message-ID: To: drip@ietf.org, curdle , IETF-Calsify , Ace Wg Content-Type: multipart/alternative; boundary="000000000000f69fe405ac2402a0" Archived-At: Subject: [Ace] Fwd: [108all] Final reminder: IETF 108 meeting survey X-BeenThere: ace@ietf.org 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: Wed, 05 Aug 2020 16:39:15 -0000 --000000000000f69fe405ac2402a0 Content-Type: text/plain; charset="UTF-8" Hi, Please consider - if not already done - to fill the IETf108 survey below. Yours, Daniel ---------- Forwarded message --------- From: IETF Executive Director Date: Wed, Aug 5, 2020 at 6:30 AM Subject: [108all] Final reminder: IETF 108 meeting survey To: <108all@ietf.org> Thank you very much to the ~230 people who have filled in the IETF 108 meeting survey as this data is crucial to helping us plan future meetings. We could still use another 70 or so responses and so this is a final reminder to please help us by taking a few minutes to complete the survey: https://www.surveymonkey.com/r/T3SL7JF Thanks in advance -- Jay Daley IETF Executive Director exec-director@ietf.org -- 108all mailing list 108all@ietf.org https://www.ietf.org/mailman/listinfo/108all -- Daniel Migault Ericsson --000000000000f69fe405ac2402a0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Hi,=C2=A0

Please consider - if not = already done - to fill the IETf108 survey below.=C2=A0

=
Yours,=C2=A0
Daniel

---------- Forwarded message ---------
F= rom: IETF Executive Directo= r <exec-director@ietf.org>
Date: Wed, Aug 5, 2020 at 6:30 AM=
Subject: [108all] Final reminder: IETF 108 meeting survey
To: <<= a href=3D"mailto:108all@ietf.org">108all@ietf.org>


= Thank you very much to the ~230 people who have filled in the IETF 108 meet= ing survey as this data is crucial to helping us plan future meetings.=C2= =A0 We could still use another 70 or so responses and so this is a final re= minder to please help us by taking a few minutes to complete the survey:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 https:= //www.surveymonkey.com/r/T3SL7JF

Thanks in advance

--
Jay Daley
IETF Executive Director
exec-director@i= etf.org

--
108all mailing list
108all@ietf.org https://www.ietf.org/mailman/listinfo/108all


--
Dani= el Migault
Ericsson
--000000000000f69fe405ac2402a0-- From nobody Mon Aug 10 13:25:25 2020 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DFA1F3A0D93 for ; Mon, 10 Aug 2020 13:25:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=unavailable 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 bPLyXT7dfNJO for ; Mon, 10 Aug 2020 13:25:11 -0700 (PDT) Received: from p3plsmtpa11-01.prod.phx3.secureserver.net (p3plsmtpa11-01.prod.phx3.secureserver.net [68.178.252.102]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7A35B3A0D83 for ; Mon, 10 Aug 2020 13:25:10 -0700 (PDT) Received: from [192.168.1.78] ([76.167.193.86]) by :SMTPAUTH: with ESMTPA id 5EM1kceYbHQQg5EM1kJp7u; Mon, 10 Aug 2020 13:25:10 -0700 X-CMAE-Analysis: v=2.3 cv=dP7YZ9Rb c=1 sm=1 tr=0 a=t2DvPg6iSvRzsOFYbaV4uQ==:117 a=t2DvPg6iSvRzsOFYbaV4uQ==:17 a=YaPx7vO5ZZfLwkmRaMsA:9 a=QEXdDO2ut3YA:10 a=Ohn9mvRcOn01qA0XQ9UA:9 a=5SGI_DtbSNQBuw0V:21 a=_W_S_7VecoQA:10 X-SECURESERVER-ACCT: lgl@island-resort.com From: Laurence Lundblade Content-Type: multipart/alternative; boundary="Apple-Mail=_0CBF1B83-1310-411D-BA95-7892200EFA17" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Message-Id: Date: Mon, 10 Aug 2020 13:25:09 -0700 To: Ace Wg , cose X-Mailer: Apple Mail (2.3445.104.11) X-CMAE-Envelope: MS4wfMEnjNlliq34F0w2tytYtZpaLar2xlehdEgnVxvdsr4GkH/ugD5kC0p5DiNHo9XmYqITjHeFDExJA+U5LJE9lbkMWKSdTLC5A+u+Oun+7bK2fVuKeWEv stG72/91N60xxOfRafk+4O7+b9AJ86RGsuw2HDBDi1lDaZhFVrWhysCgr8q+rwR16fsKrTrOHAbAxw== Archived-At: Subject: [Ace] Gap in registration of application/cwt? X-BeenThere: ace@ietf.org 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, 10 Aug 2020 20:25:20 -0000 --Apple-Mail=_0CBF1B83-1310-411D-BA95-7892200EFA17 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 It doesn=E2=80=99t seem clear what the CBOR tagging requirements are = when application/cwt is used to indicate a message is a CWT. This is the text that I think it missing: The CBOR CWT tag (61) must NOT be used. It is unnecessary because the = media type already indicates it is a CWT. The COSE type indicating tag MUST be present. It is necessary to = determine whether what the COSE type is, whether it is COSE_Sign1, = COSE_Mac0... Another solution could be a MIME parameter added to the application/cwt = indicating the COSE type. Step 3 in section 7.2 also seems wrong. It doesn=E2=80=99t make it an = error for the COSE type tag to be absent when the CBOR CWT tag is = present. This is all based on my understanding that the surrounding protocol for = must specify exactly when CBOR tags are to be used and when they are not = to be used and that the surrounding protocol must not leave it as an = optional implementation choice. In this case application/cwt is the = supporting protocol. LL= --Apple-Mail=_0CBF1B83-1310-411D-BA95-7892200EFA17 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
It doesn=E2=80=99t seem clear what the CBOR tagging = requirements are when application/cwt is used to indicate a message is a = CWT.

This is = the text that I think it missing:

The CBOR CWT tag (61) must NOT be used. = It is unnecessary because the media type already indicates it is a = CWT.

The COSE = type indicating tag MUST be present. It is necessary to determine = whether what the COSE type is, whether it is COSE_Sign1, = COSE_Mac0...

Another solution could be a MIME parameter added to the = application/cwt indicating the COSE type.

Step 3 in section 7.2 also seems wrong. = It doesn=E2=80=99t make it an error for the COSE type tag to be absent = when the CBOR CWT tag is present.


This= is all based on my understanding that the surrounding protocol for must = specify exactly when CBOR tags are to be used and when they are not to = be used and that the surrounding protocol must not leave it as an = optional implementation choice. In this case application/cwt is the = supporting protocol.

LL
= --Apple-Mail=_0CBF1B83-1310-411D-BA95-7892200EFA17-- From nobody Mon Aug 10 17:49:25 2020 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB1813A0E6B; Mon, 10 Aug 2020 17:49:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham 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 pjDb-nNbIqk4; Mon, 10 Aug 2020 17:49:22 -0700 (PDT) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0A5623A0E6A; Mon, 10 Aug 2020 17:49:21 -0700 (PDT) Received: from Jude (73.180.8.170) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Mon, 10 Aug 2020 17:49:15 -0700 From: Jim Schaad To: 'Laurence Lundblade' , 'Ace Wg' , 'cose' References: In-Reply-To: Date: Mon, 10 Aug 2020 17:49:13 -0700 Message-ID: <004201d66f79$3d95ed10$b8c1c730$@augustcellars.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0043_01D66F3E.9139D430" X-Mailer: Microsoft Outlook 16.0 Content-Language: en-us Thread-Index: AQEQxPObADvrQueaMVqePLeeIeR2QKq9Z/LQ X-Originating-IP: [73.180.8.170] Archived-At: Subject: Re: [Ace] [COSE] Gap in registration of application/cwt? X-BeenThere: ace@ietf.org 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: Tue, 11 Aug 2020 00:49:24 -0000 ------=_NextPart_000_0043_01D66F3E.9139D430 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable =20 =20 From: COSE On Behalf Of Laurence Lundblade Sent: Monday, August 10, 2020 1:25 PM To: Ace Wg ; cose Subject: [COSE] Gap in registration of application/cwt? =20 It doesn=E2=80=99t seem clear what the CBOR tagging requirements are = when application/cwt is used to indicate a message is a CWT. =20 This is the text that I think it missing: =20 The CBOR CWT tag (61) must NOT be used. It is unnecessary because the = media type already indicates it is a CWT. =20 The COSE type indicating tag MUST be present. It is necessary to = determine whether what the COSE type is, whether it is COSE_Sign1, = COSE_Mac0... =20 Another solution could be a MIME parameter added to the application/cwt = indicating the COSE type. =20 [JLS] Yes that would have been an alternative that would work =E2=80=93 = However this option would require either that you use text content types = for CoAP or you allocate N different integer content types one for each = possible set of options that could be placed there. The current = solution is cleaner and smaller. =20 Step 3 in section 7.2 also seems wrong. It doesn=E2=80=99t make it an = error for the COSE type tag to be absent when the CBOR CWT tag is = present. =20 =20 This is all based on my understanding that the surrounding protocol for = must specify exactly when CBOR tags are to be used and when they are not = to be used and that the surrounding protocol must not leave it as an = optional implementation choice. In this case application/cwt is the = supporting protocol. =20 [JLS] What is the text that says that this is true. This would be a = surprising statement for me. =20 Jim =20 =20 LL ------=_NextPart_000_0043_01D66F3E.9139D430 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

 

 

From: COSE = <cose-bounces@ietf.org> On Behalf Of Laurence = Lundblade
Sent: Monday, August 10, 2020 1:25 PM
To: = Ace Wg <ace@ietf.org>; cose = <cose@ietf.org>
Subject: [COSE] Gap in registration of = application/cwt?

 

It = doesn=E2=80=99t seem clear what the CBOR tagging requirements are when = application/cwt is used to indicate a message is a = CWT.

 

This is the text that I think it = missing:

 

The CBOR CWT tag (61) must NOT be used. It is = unnecessary because the media type already indicates it is a = CWT.

 

The COSE type indicating tag MUST be present. It is = necessary to determine whether what the COSE type is, whether it is = COSE_Sign1, COSE_Mac0...

 

Another solution could be a MIME parameter added to = the application/cwt indicating the COSE type.

 

[JLS] Yes = that would have been an alternative that would work =E2=80=93 However = this option would require either that you use text content types for = CoAP or you allocate N different integer content types one for each = possible set of options that could be placed there.=C2=A0 The current = solution is cleaner and smaller.

 

Step 3 in section 7.2 also seems wrong. It = doesn=E2=80=99t make it an error for the COSE type tag to be absent when = the CBOR CWT tag is present.

 

 

This is all based on my understanding that the = surrounding protocol for must specify exactly when CBOR tags are to be = used and when they are not to be used and that the surrounding protocol = must not leave it as an optional implementation choice. In this case = application/cwt is the supporting protocol.

 

[JLS] What = is the text that says that this is true.=C2=A0 This would be a = surprising statement for me.

 

Jim

 

 

LL

------=_NextPart_000_0043_01D66F3E.9139D430-- From nobody Tue Aug 11 12:20:44 2020 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6FB3F3A07FF for ; Tue, 11 Aug 2020 12:20:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham 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 sV259LnNCP6m for ; Tue, 11 Aug 2020 12:20:40 -0700 (PDT) Received: from p3plsmtpa11-09.prod.phx3.secureserver.net (p3plsmtpa11-09.prod.phx3.secureserver.net [68.178.252.110]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9C17C3A0ACF for ; Tue, 11 Aug 2020 12:20:40 -0700 (PDT) Received: from [192.168.1.78] ([76.167.193.86]) by :SMTPAUTH: with ESMTPA id 5Zp9kW9axC7Kr5Zp9kZAIG; Tue, 11 Aug 2020 12:20:40 -0700 X-CMAE-Analysis: v=2.3 cv=Sb+JicZu c=1 sm=1 tr=0 a=t2DvPg6iSvRzsOFYbaV4uQ==:117 a=t2DvPg6iSvRzsOFYbaV4uQ==:17 a=VrHXGImtAAAA:8 a=48vgC7mUAAAA:8 a=k7AfbbVJMtS5I1zSK-4A:9 a=JUj9kErCxBmwy0pV:21 a=0N83j4SsBfmt8v5G:21 a=QEXdDO2ut3YA:10 a=2w5PlCjTHkOfpIql5PAA:9 a=HQB38gyGZK4FBqPh:21 a=ehssqexYlHdPNOzM:21 a=wiBMwEmpoH3A3d4k:21 a=_W_S_7VecoQA:10 a=rjybpTLx1R2UrS7S5igv:22 a=w1C3t2QeGrPiZgrLijVG:22 X-SECURESERVER-ACCT: lgl@island-resort.com From: Laurence Lundblade Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_8B8F8A5A-4200-428B-8CB5-C6446211F747" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Tue, 11 Aug 2020 12:20:39 -0700 In-Reply-To: <004201d66f79$3d95ed10$b8c1c730$@augustcellars.com> Cc: Ace Wg , cose To: Jim Schaad References: <004201d66f79$3d95ed10$b8c1c730$@augustcellars.com> X-Mailer: Apple Mail (2.3445.104.11) X-CMAE-Envelope: MS4wfAYh/vY/OAh6QjrvQzjClzZF8gBU1gNiMhkLL/e+nyf25WkYIKAIqz3Eywx04009u1MADI+SnRSXo6JWTd1fVDBgvw8A/mVBYOv8HaQMm1iNmEE3raLy 98EGCxdqeBM7M0qpda1MR0RYEIHNN4NDy54/H5CszDZnEc2FHga2YmhyW3wGeJtKGQv7r5gu9sqdWEjDPL6cOWvskz8suG3IMbEE1AGGE6W/GZ31kZ0knhWB Archived-At: Subject: Re: [Ace] [COSE] Gap in registration of application/cwt? X-BeenThere: ace@ietf.org 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: Tue, 11 Aug 2020 19:20:42 -0000 --Apple-Mail=_8B8F8A5A-4200-428B-8CB5-C6446211F747 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Aug 10, 2020, at 5:49 PM, Jim Schaad = wrote: >=20 > This is all based on my understanding that the surrounding protocol = for must specify exactly when CBOR tags are to be used and when they are = not to be used and that the surrounding protocol must not leave it as an = optional implementation choice. In this case application/cwt is the = supporting protocol. > =20 > [JLS] What is the text that says that this is true. This would be a = surprising statement for me. Here=E2=80=99s three things that lead me to this. CBORbis The sentence of the first paragraph in 4.2.2 = = very clearly states this, though this is only for deterministic = encoding. Typical CDDL Most CDDL that describes tagged data describes it only as tagged or = untagged, not as optionally tagged. COSE is one example of this.=20 Email threads This thread = and this thread = . I summarized this behavior in this email = = and no where in the rest of the thread was it indicated differently. So, it is not a hard requirement because 4.2.2 is only for deterministic = encoding, but seems like a =E2=80=9Cshould" in spirit. It is the = preferred way to design a CBOR protocol. However you slice it, I think it is up to the surrounding protocol to = say whether a tag is always required, never required or optionally = required. If the protocol doesn=E2=80=99t say, then it defaults to = optionally required. Defaulting or explicitly allowing optional tagging means the receiver = has to allow for all the tagging scenarios and makes possible the error = case where the surrounding protocol says the data is of one type and the = tag conflicts with it. (e.g. an application/cwt that contains a tagged = CoSWID). I don=E2=80=99t think optional tagging is of any advantage in a protocol = design. It doesn=E2=80=99t enable anything. It has some disadvantage because it introduces error conditions and = potential confusion. I think there are several scenarios with section 6 and application/cwt = that could be more clear. Can you use tag 61 or not? I think the current answer is that in = application/cwt, tag 61 is optional. How do you know what the COSE type is? It is somewhat obvious that COSE = tags will work, but there is no requirement to use them. A MIME = parameter or other is entirely allowed here. Section 6 does say that determination that something is a CWT is = application dependent, but doesn=E2=80=99t say that the COSE type is = also application dependent. Section 7 does address this. Said another way, my fully general CWT decoder that is called by some = application needs an input parameter to indicate the COSE type because = there is no requirement in 8392 that a CWT indicate which COSE type is = in use. Sometimes the caller will be able to provide the COSE type and = sometimes they won=E2=80=99t. Sometimes there will be an error of = conflicting COSE type and sometimes the error will be that the COSE type = can=E2=80=99t be determined. I think it would have been cleanest if CWT always indicated the COSE = type be used and the tagging optionality didn=E2=80=99t span two = protocol layers, but that would be an incompatible change. Maybe a = recommendation that CWT=E2=80=99s SHOULD always indicate their COSE = type? LL= --Apple-Mail=_8B8F8A5A-4200-428B-8CB5-C6446211F747 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On Aug 10, 2020, at 5:49 PM, Jim Schaad <ietf@augustcellars.com> wrote:

This is all based on my understanding that the = surrounding protocol for must specify exactly when CBOR tags are to be = used and when they are not to be used and that the surrounding protocol = must not leave it as an optional implementation choice. In this case = application/cwt is the supporting protocol.
 
[JLS] What is the text that says that this is = true.  This would be a surprising statement for = me.

Here=E2=80= =99s three things that lead me to this.

CBORbis
The sentence of the first = paragraph in 4.2.2 very clearly states this, though this is = only for deterministic encoding.

Typical = CDDL
Most CDDL that describes tagged data = describes it only as tagged or untagged, not as optionally tagged. =  COSE is one example of this. 

Email = threads
This thread and this thread.

I summarized this = behavior in this email and no where in the rest of the thread = was it indicated differently.

So, it is not a hard requirement because = 4.2.2 is only for deterministic encoding, but seems like a =E2=80=9Cshould= " in spirit. It is the preferred way to design a CBOR protocol.

However you slice it, I = think it is up to the surrounding protocol to say whether a tag is = always required, never required or optionally required. If the protocol = doesn=E2=80=99t say, then it defaults to optionally required.

Defaulting or explicitly = allowing optional tagging means the receiver has to allow for all the = tagging scenarios and makes possible the error case where the = surrounding protocol says the data is of one type and the tag conflicts = with it. (e.g. an application/cwt that contains a tagged = CoSWID).

I = don=E2=80=99t think optional tagging is of any advantage in a protocol = design. It doesn=E2=80=99t enable anything.

It has some disadvantage because it = introduces error conditions and potential confusion.

I think there are = several scenarios with section 6 and application/cwt that could be more = clear.

Can you use tag 61 or not? I think the current answer is that = in application/cwt, tag 61 is optional.

How do you know what the COSE type is? = It is somewhat obvious that COSE tags will work, but there is no = requirement to use them. A MIME parameter or other is entirely allowed = here.

Section = 6 does say that determination that something is a CWT is application = dependent, but doesn=E2=80=99t say that the COSE type is also = application dependent. Section 7 does address = this.

Said another way, my fully general CWT decoder that is called = by some application needs an input parameter to indicate the COSE type = because there is no requirement in 8392 that a CWT indicate which COSE = type is in use. Sometimes the caller will be able to provide the COSE = type and sometimes they won=E2=80=99t. Sometimes there will be an error = of conflicting COSE type and sometimes the error will be that the COSE = type can=E2=80=99t be determined.

I think it would have been cleanest if = CWT always indicated the COSE type be used and the tagging optionality = didn=E2=80=99t span two protocol layers, but that would be an = incompatible change.  Maybe a recommendation that CWT=E2=80=99s = SHOULD always indicate their COSE type?

LL
= --Apple-Mail=_8B8F8A5A-4200-428B-8CB5-C6446211F747-- From nobody Fri Aug 14 13:58:55 2020 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B7DB13A08D1 for ; Fri, 14 Aug 2020 13:58:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.894 X-Spam-Level: X-Spam-Status: No, score=-1.894 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=unavailable 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 qGUy2EGZBZz0 for ; Fri, 14 Aug 2020 13:58:52 -0700 (PDT) Received: from p3plsmtpa08-05.prod.phx3.secureserver.net (p3plsmtpa08-05.prod.phx3.secureserver.net [173.201.193.106]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D48873A08D7 for ; Fri, 14 Aug 2020 13:58:45 -0700 (PDT) Received: from [192.168.1.78] ([76.167.193.86]) by :SMTPAUTH: with ESMTPA id 6gmikrwMSeip66gmjkFNJw; Fri, 14 Aug 2020 13:58:45 -0700 X-CMAE-Analysis: v=2.3 cv=b5LMHeOx c=1 sm=1 tr=0 a=t2DvPg6iSvRzsOFYbaV4uQ==:117 a=t2DvPg6iSvRzsOFYbaV4uQ==:17 a=K6EGIJCdAAAA:8 a=VrHXGImtAAAA:8 a=48vgC7mUAAAA:8 a=PXcJJhn042mYNjhRpNEA:9 a=ooK1ZYYnHGwGP9pd:21 a=8S_NYmHccqdHhq-g:21 a=QEXdDO2ut3YA:10 a=ehQ0wd4UoleRMcFXBYsA:9 a=anr6qqSgD_S8I-ad:21 a=5s7gydGq379n2PzS:21 a=20_1RYVDE6hz34o0:21 a=_W_S_7VecoQA:10 a=L6pVIi0Kn1GYQfi8-iRI:22 a=rjybpTLx1R2UrS7S5igv:22 a=w1C3t2QeGrPiZgrLijVG:22 X-SECURESERVER-ACCT: lgl@island-resort.com From: Laurence Lundblade Message-Id: <66829A45-EDC1-4317-AA0A-FD335B6CF820@island-resort.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_A1CAA8C5-5E59-4B02-830E-4326A93A8EAF" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Fri, 14 Aug 2020 13:58:43 -0700 In-Reply-To: Cc: Ace Wg , cose To: Jim Schaad References: <004201d66f79$3d95ed10$b8c1c730$@augustcellars.com> X-Mailer: Apple Mail (2.3445.104.11) X-CMAE-Envelope: MS4wfPCOW6soSC8d5JmY4vX4PHwXnZDR5VFHxrAdywRTaLWR5bO+Gd9+afHtO5ZFsGu2MJleX1qptlmpyiKE5fU5rN0smIRXD7tNqINCujdruwnPLvTGCTcc fFJCF19S8iFbhAmHVfVpswfxBwxqa38MbM+Owsu2VQB21yJv/AWsvfMimON2NzlmXl7AjEa3S0xvFyCHejAMwqRqnvPU/78NRfvmkK3Ke9/o8z1DsMeFkMZj Archived-At: Subject: Re: [Ace] [COSE] Gap in registration of application/cwt? X-BeenThere: ace@ietf.org 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, 14 Aug 2020 20:58:54 -0000 --Apple-Mail=_A1CAA8C5-5E59-4B02-830E-4326A93A8EAF Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Here=E2=80=99s a series of scenarios that I think are legal CWT. These = are allowed by RFC 8392, right? 1) Explicitly tagged, no external type info needed - Has CWT tag - Has COSE type tag 2) CWT identification by label, COSE type tagged - The CWT is a CBOR data item with a label. The definition of the label = says the contents of the label are always CWT - No CWT tag necessary as it is implied by the label - Has a COSE type tag 3) CWT and COSE by label - The CWT is an item with a label. The definition of the label says the = contents of the label are always CWT and of a specific COSE type - No tags necessary 4) Application/CWT identifies content as CWT, tagging for COSE type - No CWT tag - Has a COSE tag 5) Application/CWT identifies content as CWT - Has CWT tag even though it is redundant=20 - Has a COSE tag 6) Application/CWT; cose-type=3DCOSE_Sign1 (or Mac0 or =E2=80=A6) - No tags are used - Identification is completely by the MIME type header - (I understand that the cose-type MIME parameter is not defined, but it = could be. 8392 doesn=E2=80=99t forbid it) 7) A protocol like FIDO identifies a protocol element that is an = attention type the type of which is CWT with COSE_Sign1 - No tags are used 8) A protocol like FIDO identifies a protocol element that is an = attention type the type of which is CWT; the COSE type is determined by = tag - No CWT tag - Has a COSE tag The one thing you can=E2=80=99t do is have a CWT tag without a COSE type = tag. 8392 section 6 forbids this. LL > On Aug 11, 2020, at 12:20 PM, Laurence Lundblade = wrote: >=20 >=20 >=20 >> On Aug 10, 2020, at 5:49 PM, Jim Schaad > wrote: >>=20 >> This is all based on my understanding that the surrounding protocol = for must specify exactly when CBOR tags are to be used and when they are = not to be used and that the surrounding protocol must not leave it as an = optional implementation choice. In this case application/cwt is the = supporting protocol. >> =20 >> [JLS] What is the text that says that this is true. This would be a = surprising statement for me. >=20 > Here=E2=80=99s three things that lead me to this. >=20 > CBORbis > The sentence of the first paragraph in 4.2.2 = = very clearly states this, though this is only for deterministic = encoding. >=20 > Typical CDDL > Most CDDL that describes tagged data describes it only as tagged or = untagged, not as optionally tagged. COSE is one example of this.=20 >=20 > Email threads > This thread = and this thread = . >=20 > I summarized this behavior in this email = = and no where in the rest of the thread was it indicated differently. >=20 > So, it is not a hard requirement because 4.2.2 is only for = deterministic encoding, but seems like a =E2=80=9Cshould" in spirit. It = is the preferred way to design a CBOR protocol. >=20 > However you slice it, I think it is up to the surrounding protocol to = say whether a tag is always required, never required or optionally = required. If the protocol doesn=E2=80=99t say, then it defaults to = optionally required. >=20 > Defaulting or explicitly allowing optional tagging means the receiver = has to allow for all the tagging scenarios and makes possible the error = case where the surrounding protocol says the data is of one type and the = tag conflicts with it. (e.g. an application/cwt that contains a tagged = CoSWID). >=20 > I don=E2=80=99t think optional tagging is of any advantage in a = protocol design. It doesn=E2=80=99t enable anything. >=20 > It has some disadvantage because it introduces error conditions and = potential confusion. >=20 > I think there are several scenarios with section 6 and application/cwt = that could be more clear. >=20 > Can you use tag 61 or not? I think the current answer is that in = application/cwt, tag 61 is optional. >=20 > How do you know what the COSE type is? It is somewhat obvious that = COSE tags will work, but there is no requirement to use them. A MIME = parameter or other is entirely allowed here. >=20 > Section 6 does say that determination that something is a CWT is = application dependent, but doesn=E2=80=99t say that the COSE type is = also application dependent. Section 7 does address this. >=20 > Said another way, my fully general CWT decoder that is called by some = application needs an input parameter to indicate the COSE type because = there is no requirement in 8392 that a CWT indicate which COSE type is = in use. Sometimes the caller will be able to provide the COSE type and = sometimes they won=E2=80=99t. Sometimes there will be an error of = conflicting COSE type and sometimes the error will be that the COSE type = can=E2=80=99t be determined. >=20 > I think it would have been cleanest if CWT always indicated the COSE = type be used and the tagging optionality didn=E2=80=99t span two = protocol layers, but that would be an incompatible change. Maybe a = recommendation that CWT=E2=80=99s SHOULD always indicate their COSE = type? >=20 > LL --Apple-Mail=_A1CAA8C5-5E59-4B02-830E-4326A93A8EAF Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
Here=E2=80=99s a series of scenarios that I think are legal = CWT. These are allowed by RFC 8392, right?

1) Explicitly tagged, no external type = info needed
- Has CWT tag
- = Has COSE type tag

2) CWT identification by label, COSE type tagged
- The CWT is a CBOR data item with a label. The definition of = the label says the contents of the label are always CWT
- No CWT tag necessary as it is implied by the = label
- Has a COSE type tag

3) CWT and COSE by label
- The CWT is an item with a label. The definition of the = label says the contents of the label are always CWT and of a specific = COSE type
- No tags necessary

4) Application/CWT = identifies content as CWT, tagging for COSE type
- = No CWT tag
- Has a COSE tag

5) Application/CWT = identifies content as CWT
- Has CWT tag even though = it is redundant 
- Has a COSE = tag

6) = Application/CWT; cose-type=3DCOSE_Sign1 (or Mac0 or =E2=80=A6)
- No tags are used
- Identification is = completely by the MIME type header
- (I understand = that the cose-type MIME parameter is not defined, but it could be. 8392 = doesn=E2=80=99t forbid it)

7) A protocol like FIDO identifies a protocol element that is = an attention type the type of which is CWT with COSE_Sign1
- No tags are used

8) A protocol like FIDO = identifies a protocol element that is an attention type the type of = which is CWT; the COSE type is determined by tag
- = No CWT tag
- Has a COSE tag

The one thing you = can=E2=80=99t do is have a CWT tag without a COSE type tag. 8392 section = 6 forbids this.

LL





On Aug 11, 2020, at 12:20 PM, Laurence Lundblade <lgl@island-resort.com> wrote:



On Aug 10, 2020, at 5:49 PM, Jim Schaad <ietf@augustcellars.com> wrote:

This is all based on my understanding that the = surrounding protocol for must specify exactly when CBOR tags are to be = used and when they are not to be used and that the surrounding protocol = must not leave it as an optional implementation choice. In this case = application/cwt is the supporting protocol.
 
[JLS] What is the text that says that this is = true.  This would be a surprising statement for = me.

Here=E2=80= =99s three things that lead me to this.

CBORbis
The sentence of the first = paragraph in 4.2.2 very clearly states this, though this is = only for deterministic encoding.

Typical = CDDL
Most CDDL that describes tagged data = describes it only as tagged or untagged, not as optionally tagged. =  COSE is one example of this. 

Email = threads
This thread and this thread.

I summarized this = behavior in this email and no where in the rest of the thread = was it indicated differently.

So, it is not a hard requirement because = 4.2.2 is only for deterministic encoding, but seems like a =E2=80=9Cshould= " in spirit. It is the preferred way to design a CBOR protocol.

However you slice it, I = think it is up to the surrounding protocol to say whether a tag is = always required, never required or optionally required. If the protocol = doesn=E2=80=99t say, then it defaults to optionally required.

Defaulting or explicitly = allowing optional tagging means the receiver has to allow for all the = tagging scenarios and makes possible the error case where the = surrounding protocol says the data is of one type and the tag conflicts = with it. (e.g. an application/cwt that contains a tagged = CoSWID).

I = don=E2=80=99t think optional tagging is of any advantage in a protocol = design. It doesn=E2=80=99t enable anything.

It has some disadvantage because it = introduces error conditions and potential confusion.

I think there are = several scenarios with section 6 and application/cwt that could be more = clear.

Can you use tag 61 or not? I think the current answer is that = in application/cwt, tag 61 is optional.

How do you know what the COSE type is? = It is somewhat obvious that COSE tags will work, but there is no = requirement to use them. A MIME parameter or other is entirely allowed = here.

Section = 6 does say that determination that something is a CWT is application = dependent, but doesn=E2=80=99t say that the COSE type is also = application dependent. Section 7 does address = this.

Said another way, my fully general CWT decoder that is called = by some application needs an input parameter to indicate the COSE type = because there is no requirement in 8392 that a CWT indicate which COSE = type is in use. Sometimes the caller will be able to provide the COSE = type and sometimes they won=E2=80=99t. Sometimes there will be an error = of conflicting COSE type and sometimes the error will be that the COSE = type can=E2=80=99t be determined.

I think it would have been cleanest if = CWT always indicated the COSE type be used and the tagging optionality = didn=E2=80=99t span two protocol layers, but that would be an = incompatible change.  Maybe a recommendation that CWT=E2=80=99s = SHOULD always indicate their COSE type?

LL

= --Apple-Mail=_A1CAA8C5-5E59-4B02-830E-4326A93A8EAF-- From nobody Fri Aug 14 15:35:16 2020 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0ADE53A0433; Fri, 14 Aug 2020 15:35:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham 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 HyI05NOwlooe; Fri, 14 Aug 2020 15:35:11 -0700 (PDT) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5B4D33A041B; Fri, 14 Aug 2020 15:35:10 -0700 (PDT) Received: from Jude (73.180.8.170) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Fri, 14 Aug 2020 15:35:02 -0700 From: Jim Schaad To: 'Laurence Lundblade' CC: 'Ace Wg' , 'cose' References: <004201d66f79$3d95ed10$b8c1c730$@augustcellars.com> <66829A45-EDC1-4317-AA0A-FD335B6CF820@island-resort.com> In-Reply-To: <66829A45-EDC1-4317-AA0A-FD335B6CF820@island-resort.com> Date: Fri, 14 Aug 2020 15:35:01 -0700 Message-ID: <00af01d6728b$27579480$7606bd80$@augustcellars.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00B0_01D67250.7AFB0670" X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQEQxPObADvrQueaMVqePLeeIeR2QAJXtPJSAea5GecCGLJowKqQ0fmg Content-Language: en-us X-Originating-IP: [73.180.8.170] Archived-At: Subject: Re: [Ace] [COSE] Gap in registration of application/cwt? X-BeenThere: ace@ietf.org 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, 14 Aug 2020 22:35:14 -0000 ------=_NextPart_000_00B0_01D67250.7AFB0670 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable =20 =20 From: Laurence Lundblade =20 Sent: Friday, August 14, 2020 1:59 PM To: Jim Schaad Cc: Ace Wg ; cose Subject: Re: [COSE] Gap in registration of application/cwt? =20 Here=E2=80=99s a series of scenarios that I think are legal CWT. These = are allowed by RFC 8392, right? =20 1) Explicitly tagged, no external type info needed - Has CWT tag - Has COSE type tag [JLS] Yes =20 2) CWT identification by label, COSE type tagged - The CWT is a CBOR data item with a label. The definition of the label = says the contents of the label are always CWT - No CWT tag necessary as it is implied by the label - Has a COSE type tag [JLS] Yes, the label could be internal to the CBOR object or external = such as an media-type =20 3) CWT and COSE by label - The CWT is an item with a label. The definition of the label says the = contents of the label are always CWT and of a specific COSE type - No tags necessary [JLS] Yes that would be fine =20 4) Application/CWT identifies content as CWT, tagging for COSE type - No CWT tag - Has a COSE tag [JLS] This is the same as 2? I don=E2=80=99t think that it would be = restricted to just that media type. =20 5) Application/CWT identifies content as CWT - Has CWT tag even though it is redundant=20 - Has a COSE tag [JLS] Yes =20 6) Application/CWT; cose-type=3DCOSE_Sign1 (or Mac0 or =E2=80=A6) - No tags are used - Identification is completely by the MIME type header - (I understand that the cose-type MIME parameter is not defined, but it = could be. 8392 doesn=E2=80=99t forbid it) [JLS] Yes you could do that, and as I stated in a previous mail this is = not a good idea for the CoAP world. =20 7) A protocol like FIDO identifies a protocol element that is an = attention type the type of which is CWT with COSE_Sign1 - No tags are used [JLS] yes =20 8) A protocol like FIDO identifies a protocol element that is an = attention type the type of which is CWT; the COSE type is determined by = tag - No CWT tag - Has a COSE tag [JLS] yes =20 The one thing you can=E2=80=99t do is have a CWT tag without a COSE type = tag. 8392 section 6 forbids this. =20 [JLS] There however is a set of nested cases that you might need to look = at. That is 6.CWT ( COSE_Encrypt_Tagged ( COSE_Sign )) You would also = need to think about the requirements for nested COSE layers. =20 Jim =20 =20 LL =20 =20 =20 =20 On Aug 11, 2020, at 12:20 PM, Laurence Lundblade > wrote: =20 =20 On Aug 10, 2020, at 5:49 PM, Jim Schaad > wrote: =20 This is all based on my understanding that the surrounding protocol for = must specify exactly when CBOR tags are to be used and when they are not = to be used and that the surrounding protocol must not leave it as an = optional implementation choice. In this case application/cwt is the = supporting protocol. =20 [JLS] What is the text that says that this is true. This would be a = surprising statement for me. =20 Here=E2=80=99s three things that lead me to this. =20 CBORbis The sentence of the first paragraph in 4.2.2 = = very clearly states this, though this is only for deterministic = encoding. =20 Typical CDDL Most CDDL that describes tagged data describes it only as tagged or = untagged, not as optionally tagged. COSE is one example of this.=20 =20 Email threads This thread = and this thread = . =20 I summarized this behavior in this email = = and no where in the rest of the thread was it indicated differently. =20 So, it is not a hard requirement because 4.2.2 is only for deterministic = encoding, but seems like a =E2=80=9Cshould" in spirit. It is the = preferred way to design a CBOR protocol. =20 However you slice it, I think it is up to the surrounding protocol to = say whether a tag is always required, never required or optionally = required. If the protocol doesn=E2=80=99t say, then it defaults to = optionally required. =20 Defaulting or explicitly allowing optional tagging means the receiver = has to allow for all the tagging scenarios and makes possible the error = case where the surrounding protocol says the data is of one type and the = tag conflicts with it. (e.g. an application/cwt that contains a tagged = CoSWID). =20 I don=E2=80=99t think optional tagging is of any advantage in a protocol = design. It doesn=E2=80=99t enable anything. =20 It has some disadvantage because it introduces error conditions and = potential confusion. =20 I think there are several scenarios with section 6 and application/cwt = that could be more clear. =20 Can you use tag 61 or not? I think the current answer is that in = application/cwt, tag 61 is optional. =20 How do you know what the COSE type is? It is somewhat obvious that COSE = tags will work, but there is no requirement to use them. A MIME = parameter or other is entirely allowed here. =20 Section 6 does say that determination that something is a CWT is = application dependent, but doesn=E2=80=99t say that the COSE type is = also application dependent. Section 7 does address this. =20 Said another way, my fully general CWT decoder that is called by some = application needs an input parameter to indicate the COSE type because = there is no requirement in 8392 that a CWT indicate which COSE type is = in use. Sometimes the caller will be able to provide the COSE type and = sometimes they won=E2=80=99t. Sometimes there will be an error of = conflicting COSE type and sometimes the error will be that the COSE type = can=E2=80=99t be determined. =20 I think it would have been cleanest if CWT always indicated the COSE = type be used and the tagging optionality didn=E2=80=99t span two = protocol layers, but that would be an incompatible change. Maybe a = recommendation that CWT=E2=80=99s SHOULD always indicate their COSE = type? =20 LL =20 ------=_NextPart_000_00B0_01D67250.7AFB0670 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

 

 

From: Laurence Lundblade = <lgl@island-resort.com>
Sent: Friday, August 14, 2020 = 1:59 PM
To: Jim Schaad = <ietf@augustcellars.com>
Cc: Ace Wg = <ace@ietf.org>; cose <cose@ietf.org>
Subject: Re: = [COSE] Gap in registration of = application/cwt?

 

Here=E2=80=99s a series of scenarios that I think are = legal CWT. These are allowed by RFC 8392, = right?

 

1) Explicitly tagged, no external type info = needed

- Has CWT = tag

- Has COSE type = tag

[JLS] = Yes

 

2) CWT identification by label, COSE type = tagged

- The CWT is a CBOR = data item with a label. The definition of the label says the contents of = the label are always CWT

- = No CWT tag necessary as it is implied by the = label

- Has a COSE type = tag

[JLS] Yes, the label could be = internal to the CBOR object or external such as an = media-type

 

3) CWT and COSE by label

- The CWT is an item with a label. The definition of = the label says the contents of the label are always CWT and of a = specific COSE type

- No = tags necessary

[JLS] Yes that would = be fine

 

4) Application/CWT identifies content as CWT, tagging = for COSE type

- No CWT = tag

- Has a COSE = tag

[JLS] This is the same as = 2?=C2=A0 I don=E2=80=99t think that it would be restricted to just that = media type.

 

5) Application/CWT identifies content as = CWT

- Has CWT tag even = though it is redundant 

- Has a COSE tag

[JLS] Yes

 

6) Application/CWT; cose-type=3DCOSE_Sign1 (or Mac0 or = =E2=80=A6)

- No tags are = used

- Identification is = completely by the MIME type header

- (I understand that the cose-type MIME parameter is = not defined, but it could be. 8392 doesn=E2=80=99t forbid = it)

[JLS] Yes you could do that, and = as I stated in a previous mail this is not a good idea for the CoAP = world.

 

7) A protocol like FIDO identifies a protocol element = that is an attention type the type of which is CWT with = COSE_Sign1

- No tags are = used

[JLS] = yes

 

8) A protocol like FIDO identifies a protocol element = that is an attention type the type of which is CWT; the COSE type is = determined by tag

- No CWT = tag

- Has a COSE = tag

[JLS] = yes

 

The one thing you can=E2=80=99t do is have a CWT tag = without a COSE type tag. 8392 section 6 forbids this.

 

[JLS] There = however is a set of nested cases that you might need to look at.=C2=A0 = That is 6.CWT ( COSE_Encrypt_Tagged ( COSE_Sign ))=C2=A0 You would also = need to think about the requirements for nested COSE = layers.

 

Jim

 

 

LL

 

 

 

 



On Aug 11, 2020, at 12:20 PM, Laurence Lundblade = <lgl@island-resort.com> = wrote:

 

 



On Aug 10, 2020, at 5:49 PM, Jim Schaad <ietf@augustcellars.com> = wrote:

 

This is all based on my understanding that the = surrounding protocol for must specify exactly when CBOR tags are to be = used and when they are not to be used and that the surrounding protocol = must not leave it as an optional implementation choice. In this case = application/cwt is the supporting protocol.

 

[JLS] What is the text that says that this is = true.  This would be a surprising statement for = me.

 

Here=E2=80=99s three things that lead me to = this.

 

CBORbis

The sentence of the first paragraph in 4.2.2 very clearly states this, though this is only for = deterministic encoding.

 

Typical CDDL

Most CDDL that describes tagged data describes it only = as tagged or untagged, not as optionally tagged.  COSE is one = example of this. 

 

Email threads

 

I = summarized this behavior in this email and no where in the rest of the thread was it = indicated differently.

 

So, it is not a hard requirement because 4.2.2 is only = for deterministic encoding, but seems like a =E2=80=9Cshould" in = spirit. It is the preferred way to design a CBOR = protocol.

 

However you slice it, I think it is up to the = surrounding protocol to say whether a tag is always required, never = required or optionally required. If the protocol doesn=E2=80=99t say, = then it defaults to optionally required.

 

Defaulting or explicitly allowing optional tagging = means the receiver has to allow for all the tagging scenarios and makes = possible the error case where the surrounding protocol says the data is = of one type and the tag conflicts with it. (e.g. an application/cwt that = contains a tagged CoSWID).

 

I = don=E2=80=99t think optional tagging is of any advantage in a protocol = design. It doesn=E2=80=99t enable anything.

 

It has some disadvantage because it introduces error = conditions and potential confusion.

 

I = think there are several scenarios with section 6 and application/cwt = that could be more clear.

 

Can you use tag 61 or not? I think the current answer = is that in application/cwt, tag 61 is = optional.

 

How do you know what the COSE type is? It is somewhat = obvious that COSE tags will work, but there is no requirement to use = them. A MIME parameter or other is entirely allowed = here.

 

Section 6 does say that determination that something = is a CWT is application dependent, but doesn=E2=80=99t say that the COSE = type is also application dependent. Section 7 does address = this.

 

Said another way, my fully general CWT decoder that is = called by some application needs an input parameter to indicate the COSE = type because there is no requirement in 8392 that a CWT indicate which = COSE type is in use. Sometimes the caller will be able to provide the = COSE type and sometimes they won=E2=80=99t. Sometimes there will be an = error of conflicting COSE type and sometimes the error will be that the = COSE type can=E2=80=99t be determined.

 

I = think it would have been cleanest if CWT always indicated the COSE type = be used and the tagging optionality didn=E2=80=99t span two protocol = layers, but that would be an incompatible change.  Maybe a = recommendation that CWT=E2=80=99s SHOULD always indicate their COSE = type?

 

LL

<= p class=3DMsoNormal> 

------=_NextPart_000_00B0_01D67250.7AFB0670-- From nobody Sat Aug 15 10:58:28 2020 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F5AD3A089D for ; Sat, 15 Aug 2020 10:58:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.894 X-Spam-Level: X-Spam-Status: No, score=-1.894 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham 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 FwK6zBPZ-fa6 for ; Sat, 15 Aug 2020 10:58:25 -0700 (PDT) Received: from p3plsmtpa06-05.prod.phx3.secureserver.net (p3plsmtpa06-05.prod.phx3.secureserver.net [173.201.192.106]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 728443A08A3 for ; Sat, 15 Aug 2020 10:58:25 -0700 (PDT) Received: from [192.168.1.78] ([76.167.193.86]) by :SMTPAUTH: with ESMTPA id 70RkkF98s5Zij70RkkXsxV; Sat, 15 Aug 2020 10:58:24 -0700 X-CMAE-Analysis: v=2.3 cv=XP9OtjpE c=1 sm=1 tr=0 a=t2DvPg6iSvRzsOFYbaV4uQ==:117 a=t2DvPg6iSvRzsOFYbaV4uQ==:17 a=VrHXGImtAAAA:8 a=K6EGIJCdAAAA:8 a=48vgC7mUAAAA:8 a=bFzclpeIq9MwBgp7VhUA:9 a=8I6_VEMliVAvdM0K:21 a=48s_paRzSZvxVOPN:21 a=QEXdDO2ut3YA:10 a=eypa8oWK2F2CkhvW-8UA:9 a=X3EDfnADaIYM8snQ:21 a=N1mhsGAlisfas1Wx:21 a=LB8P8dvH4siyT6m8:21 a=_W_S_7VecoQA:10 a=rjybpTLx1R2UrS7S5igv:22 a=L6pVIi0Kn1GYQfi8-iRI:22 a=w1C3t2QeGrPiZgrLijVG:22 X-SECURESERVER-ACCT: lgl@island-resort.com From: Laurence Lundblade Message-Id: <39135152-A5D8-48AB-B882-B29DCE5E3811@island-resort.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_C2B0FD4B-89A1-446B-9435-8F88B4DBFA6D" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Sat, 15 Aug 2020 10:58:23 -0700 In-Reply-To: <00af01d6728b$27579480$7606bd80$@augustcellars.com> Cc: cose , Ace Wg To: Jim Schaad References: <004201d66f79$3d95ed10$b8c1c730$@augustcellars.com> <66829A45-EDC1-4317-AA0A-FD335B6CF820@island-resort.com> <00af01d6728b$27579480$7606bd80$@augustcellars.com> X-Mailer: Apple Mail (2.3445.104.11) X-CMAE-Envelope: MS4wfGxnkWHM0/BE/KxSnQg95LVNYBQvUmtTbHAgCNZvaAf4MtSLk+5SpkrhWAahs47BKs8xeWBbq3e7P58f62bPbu6rW6nknh4j5s0pL784XEOKPqVexQqz JvX26buXs4x+2WMp9QbJMYqi3VYFFshgSUExOy71r6INHMJbzA0FBaXHfXAEdWnDWXNA5jnId0Y7fN5nue2trIyUZMhPLLedeB/LVKaYMd2QTyIMNg9L7oOk Archived-At: Subject: Re: [Ace] [COSE] Gap in registration of application/cwt? X-BeenThere: ace@ietf.org 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: Sat, 15 Aug 2020 17:58:27 -0000 --Apple-Mail=_C2B0FD4B-89A1-446B-9435-8F88B4DBFA6D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Aug 14, 2020, at 3:35 PM, Jim Schaad = wrote: >=20 > =20 > =20 > From: Laurence Lundblade >=20 > Sent: Friday, August 14, 2020 1:59 PM > To: Jim Schaad > > Cc: Ace Wg >; cose > > Subject: Re: [COSE] Gap in registration of application/cwt? > =20 > Here=E2=80=99s a series of scenarios that I think are legal CWT. These = are allowed by RFC 8392, right? > =20 > 1) Explicitly tagged, no external type info needed > - Has CWT tag > - Has COSE type tag > [JLS] Yes > =20 > 2) CWT identification by label, COSE type tagged > - The CWT is a CBOR data item with a label. The definition of the = label says the contents of the label are always CWT > - No CWT tag necessary as it is implied by the label > - Has a COSE type tag > [JLS] Yes, the label could be internal to the CBOR object or external = such as an media-type I was being very specific with the term label, meaning a label/key = identifying an item in a CBOR map. > =20 > 3) CWT and COSE by label > - The CWT is an item with a label. The definition of the label says = the contents of the label are always CWT and of a specific COSE type > - No tags necessary > [JLS] Yes that would be fine > =20 > 4) Application/CWT identifies content as CWT, tagging for COSE type > - No CWT tag > - Has a COSE tag > [JLS] This is the same as 2? I don=E2=80=99t think that it would be = restricted to just that media type. You mean there could be other media types that also identify the content = as CWT? > =20 > 5) Application/CWT identifies content as CWT > - Has CWT tag even though it is redundant=20 > - Has a COSE tag > [JLS] Yes Additionally, one might interpret CBORbis 4.2.2 to say the the CWT tag = should not be present. > =20 > 6) Application/CWT; cose-type=3DCOSE_Sign1 (or Mac0 or =E2=80=A6) > - No tags are used > - Identification is completely by the MIME type header > - (I understand that the cose-type MIME parameter is not defined, but = it could be. 8392 doesn=E2=80=99t forbid it) > [JLS] Yes you could do that, and as I stated in a previous mail this = is not a good idea for the CoAP world. > =20 > 7) A protocol like FIDO identifies a protocol element that is an = attention type the type of which is CWT with COSE_Sign1 > - No tags are used > [JLS] yes > =20 > 8) A protocol like FIDO identifies a protocol element that is an = attention type the type of which is CWT; the COSE type is determined by = tag > - No CWT tag > - Has a COSE tag > [JLS] yes > =20 > The one thing you can=E2=80=99t do is have a CWT tag without a COSE = type tag. 8392 section 6 forbids this. > =20 > [JLS] There however is a set of nested cases that you might need to = look at. That is 6.CWT ( COSE_Encrypt_Tagged ( COSE_Sign )) You would = also need to think about the requirements for nested COSE layers. All but the most outer COSE type are always identified by a tag, per 7.1 = step 5 and 7.2 step 6, right? LL > =20 > Jim > =20 > =20 > LL > =20 > =20 > =20 > =20 >=20 >=20 >> On Aug 11, 2020, at 12:20 PM, Laurence Lundblade = > wrote: >> =20 >> =20 >>=20 >>=20 >>> On Aug 10, 2020, at 5:49 PM, Jim Schaad > wrote: >>> =20 >>> This is all based on my understanding that the surrounding protocol = for must specify exactly when CBOR tags are to be used and when they are = not to be used and that the surrounding protocol must not leave it as an = optional implementation choice. In this case application/cwt is the = supporting protocol. >>> =20 >>> [JLS] What is the text that says that this is true. This would be a = surprising statement for me. >>=20 >> =20 >> Here=E2=80=99s three things that lead me to this. >> =20 >>> CBORbis >>> The sentence of the first paragraph in 4.2.2 = = very clearly states this, though this is only for deterministic = encoding. >>> =20 >>> Typical CDDL >>> Most CDDL that describes tagged data describes it only as tagged or = untagged, not as optionally tagged. COSE is one example of this.=20 >>> =20 >>> Email threads >>> This thread = and this thread = . >>> =20 >>> I summarized this behavior in this email = = and no where in the rest of the thread was it indicated differently. >>> =20 >> So, it is not a hard requirement because 4.2.2 is only for = deterministic encoding, but seems like a =E2=80=9Cshould" in spirit. It = is the preferred way to design a CBOR protocol. >> =20 >> However you slice it, I think it is up to the surrounding protocol to = say whether a tag is always required, never required or optionally = required. If the protocol doesn=E2=80=99t say, then it defaults to = optionally required. >> =20 >> Defaulting or explicitly allowing optional tagging means the receiver = has to allow for all the tagging scenarios and makes possible the error = case where the surrounding protocol says the data is of one type and the = tag conflicts with it. (e.g. an application/cwt that contains a tagged = CoSWID). >> =20 >> I don=E2=80=99t think optional tagging is of any advantage in a = protocol design. It doesn=E2=80=99t enable anything. >> =20 >> It has some disadvantage because it introduces error conditions and = potential confusion. >> =20 >> I think there are several scenarios with section 6 and = application/cwt that could be more clear. >> =20 >>> Can you use tag 61 or not? I think the current answer is that in = application/cwt, tag 61 is optional. >>> =20 >>> How do you know what the COSE type is? It is somewhat obvious that = COSE tags will work, but there is no requirement to use them. A MIME = parameter or other is entirely allowed here. >>> =20 >>> Section 6 does say that determination that something is a CWT is = application dependent, but doesn=E2=80=99t say that the COSE type is = also application dependent. Section 7 does address this. >> =20 >> Said another way, my fully general CWT decoder that is called by some = application needs an input parameter to indicate the COSE type because = there is no requirement in 8392 that a CWT indicate which COSE type is = in use. Sometimes the caller will be able to provide the COSE type and = sometimes they won=E2=80=99t. Sometimes there will be an error of = conflicting COSE type and sometimes the error will be that the COSE type = can=E2=80=99t be determined. >> =20 >> I think it would have been cleanest if CWT always indicated the COSE = type be used and the tagging optionality didn=E2=80=99t span two = protocol layers, but that would be an incompatible change. Maybe a = recommendation that CWT=E2=80=99s SHOULD always indicate their COSE = type? >> =20 >> LL >=20 > =20 > _______________________________________________ > Ace mailing list > Ace@ietf.org > https://www.ietf.org/mailman/listinfo/ace = --Apple-Mail=_C2B0FD4B-89A1-446B-9435-8F88B4DBFA6D Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On Aug 14, 2020, at 3:35 PM, Jim Schaad <ietf@augustcellars.com> wrote:

 
 
From: Laurence Lundblade <lgl@island-resort.com> 
Sent: Friday, August 14, 2020 = 1:59 PM
To: Jim Schaad <ietf@augustcellars.com>
Cc: Ace Wg <ace@ietf.org>; cose <cose@ietf.org>
Subject: Re: [COSE] Gap in = registration of application/cwt?
 
Here=E2=80=99= s a series of scenarios that I think are legal CWT. These are allowed by = RFC 8392, right?
 
1) Explicitly tagged, no external type = info needed
- Has CWT tag
- Has = COSE type tag
[JLS] = Yes
 
2) = CWT identification by label, COSE type tagged
- The CWT = is a CBOR data item with a label. The definition of the label says the = contents of the label are always CWT
- No CWT tag necessary as it is implied = by the label
- Has a COSE type tag
[JLS] Yes, the label could = be internal to the CBOR object or external such as an = media-type

I was being very specific with the term label, = meaning a label/key identifying an item in a CBOR map.

 
3) = CWT and COSE by label
- The CWT is an item with a label. The = definition of the label says the contents of the label are always CWT = and of a specific COSE type
- No tags necessary
[JLS] Yes that would be = fine
 
4) Application/CWT identifies content = as CWT, tagging for COSE type
- No CWT tag
- Has a = COSE tag
[JLS] = This is the same as 2?  I don=E2=80=99t think that it would be = restricted to just that media = type.

You mean there could be other media types that = also identify the content as CWT?

 
5) Application/CWT identifies content as CWT
- Has CWT = tag even though it is redundant 
- Has a = COSE tag
[JLS] = Yes

Additionally, one might interpret CBORbis 4.2.2 to = say the the CWT tag should not be present.

 
6) = Application/CWT; cose-type=3DCOSE_Sign1 (or Mac0 or =E2=80=A6)
- No tags = are used
- Identification is completely by the MIME type = header
- (I understand that the cose-type MIME = parameter is not defined, but it could be. 8392 doesn=E2=80=99t forbid = it)
[JLS] Yes you could = do that, and as I stated in a previous mail this is not a good idea for = the CoAP world.
 
7) A protocol like FIDO identifies a = protocol element that is an attention type the type of which is CWT with = COSE_Sign1
- No tags are used
[JLS] yes
 
8) A protocol like FIDO identifies a protocol = element that is an attention type the type of which is CWT; the COSE = type is determined by tag
- No CWT tag
- Has a = COSE tag
[JLS] = yes
 
The one thing you can=E2=80=99t do is = have a CWT tag without a COSE type tag. 8392 section 6 forbids this.
 
[JLS] There however is a = set of nested cases that you might need to look at.  That is 6.CWT = ( COSE_Encrypt_Tagged ( COSE_Sign ))  You would also need to think = about the requirements for nested COSE = layers.

All but the most outer COSE type are always = identified by a tag, per 7.1 step 5 and 7.2 step 6, right?

LL


 
Jim
 
 
LL
 
 
 
 


On Aug 11, 2020, at = 12:20 PM, Laurence Lundblade <lgl@island-resort.com> wrote:
 
 


On Aug 10, 2020, at 5:49 PM, Jim Schaad <ietf@augustcellars.com> = wrote:
 
This is all based on my understanding that the = surrounding protocol for must specify exactly when CBOR tags are to be = used and when they are not to be used and that the surrounding protocol = must not leave it as an optional implementation choice. In this case = application/cwt is the supporting protocol.
 
[JLS] = What is the text that says that this is true.  This would be a = surprising statement for me.
 
Here=E2=80=99s three things that lead = me to this.
 
CBORbis
The = sentence of the first paragraph in 4.2.2 very clearly states this, though this is only = for deterministic encoding.
 
Typical CDDL
Most CDDL that describes tagged data = describes it only as tagged or untagged, not as optionally tagged. =  COSE is one example of this. 
 
Email threads
This thread and this thread.
 
I = summarized this behavior in this email and no where in the rest of the thread was it = indicated differently.
 
So, = it is not a hard requirement because 4.2.2 is only for deterministic = encoding, but seems like a =E2=80=9Cshould" in spirit. It is the = preferred way to design a CBOR protocol.
 
However you slice it, I think it is up to the surrounding = protocol to say whether a tag is always required, never required or = optionally required. If the protocol doesn=E2=80=99t say, then it = defaults to optionally required.
 
Defaulting or explicitly allowing optional tagging means the = receiver has to allow for all the tagging scenarios and makes possible = the error case where the surrounding protocol says the data is of one = type and the tag conflicts with it. (e.g. an application/cwt that = contains a tagged CoSWID).
 
I = don=E2=80=99t think optional tagging is of any advantage in a protocol = design. It doesn=E2=80=99t enable anything.
 
It = has some disadvantage because it introduces error conditions and = potential confusion.
 
I think there are several scenarios = with section 6 and application/cwt that could be more clear.
 
Can you use tag 61 or not? I think the current = answer is that in application/cwt, tag 61 is optional.
 
How = do you know what the COSE type is? It is somewhat obvious that COSE tags = will work, but there is no requirement to use them. A MIME parameter or = other is entirely allowed here.
 
Section 6 does say that determination that something is a CWT = is application dependent, but doesn=E2=80=99t say that the COSE type is = also application dependent. Section 7 does address this.
 
Said another way, my fully general CWT = decoder that is called by some application needs an input parameter to = indicate the COSE type because there is no requirement in 8392 that a = CWT indicate which COSE type is in use. Sometimes the caller will be = able to provide the COSE type and sometimes they won=E2=80=99t. = Sometimes there will be an error of conflicting COSE type and sometimes = the error will be that the COSE type can=E2=80=99t be determined.
 
I = think it would have been cleanest if CWT always indicated the COSE type = be used and the tagging optionality didn=E2=80=99t span two protocol = layers, but that would be an incompatible change.  Maybe a = recommendation that CWT=E2=80=99s SHOULD always indicate their COSE = type?
 
LL
 
_______________________________________________
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace

= --Apple-Mail=_C2B0FD4B-89A1-446B-9435-8F88B4DBFA6D-- From nobody Sat Aug 15 11:43:04 2020 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C4C33A0855; Sat, 15 Aug 2020 11:43:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham 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 Y4a1FjmLBrwu; Sat, 15 Aug 2020 11:43:01 -0700 (PDT) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1ECD53A0859; Sat, 15 Aug 2020 11:42:59 -0700 (PDT) Received: from Jude (73.180.8.170) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Sat, 15 Aug 2020 11:42:35 -0700 From: Jim Schaad To: 'Laurence Lundblade' CC: 'cose' , 'Ace Wg' References: <004201d66f79$3d95ed10$b8c1c730$@augustcellars.com> <66829A45-EDC1-4317-AA0A-FD335B6CF820@island-resort.com> <00af01d6728b$27579480$7606bd80$@augustcellars.com> <39135152-A5D8-48AB-B882-B29DCE5E3811@island-resort.com> In-Reply-To: <39135152-A5D8-48AB-B882-B29DCE5E3811@island-resort.com> Date: Sat, 15 Aug 2020 11:42:33 -0700 Message-ID: <00d201d67333$d8449d30$88cdd790$@augustcellars.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00D3_01D672F9.2BEE0290" X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQEQxPObADvrQueaMVqePLeeIeR2QAJXtPJSAea5GecCGLJowAJ+XblxAdxq5xCqb0y90A== Content-Language: en-us X-Originating-IP: [73.180.8.170] Archived-At: Subject: Re: [Ace] [COSE] Gap in registration of application/cwt? X-BeenThere: ace@ietf.org 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: Sat, 15 Aug 2020 18:43:03 -0000 ------=_NextPart_000_00D3_01D672F9.2BEE0290 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable =20 =20 From: Laurence Lundblade =20 Sent: Saturday, August 15, 2020 10:58 AM To: Jim Schaad Cc: cose ; Ace Wg Subject: Re: [Ace] [COSE] Gap in registration of application/cwt? =20 =20 On Aug 14, 2020, at 3:35 PM, Jim Schaad > wrote: =20 =20 =20 From: Laurence Lundblade >=20 Sent: Friday, August 14, 2020 1:59 PM To: Jim Schaad > Cc: Ace Wg >; cose > Subject: Re: [COSE] Gap in registration of application/cwt? =20 Here=E2=80=99s a series of scenarios that I think are legal CWT. These = are allowed by RFC 8392, right? =20 1) Explicitly tagged, no external type info needed - Has CWT tag - Has COSE type tag [JLS] Yes =20 2) CWT identification by label, COSE type tagged - The CWT is a CBOR data item with a label. The definition of the label = says the contents of the label are always CWT - No CWT tag necessary as it is implied by the label - Has a COSE type tag [JLS] Yes, the label could be internal to the CBOR object or external = such as an media-type =20 I was being very specific with the term label, meaning a label/key = identifying an item in a CBOR map. =20 3) CWT and COSE by label - The CWT is an item with a label. The definition of the label says the = contents of the label are always CWT and of a specific COSE type - No tags necessary [JLS] Yes that would be fine =20 4) Application/CWT identifies content as CWT, tagging for COSE type - No CWT tag - Has a COSE tag [JLS] This is the same as 2? I don=E2=80=99t think that it would be = restricted to just that media type. =20 You mean there could be other media types that also identify the content = as CWT? [JLS] Yes this could be done in the future. One would normally expect = this to be an application specific profile, but funny things happen. =20 5) Application/CWT identifies content as CWT - Has CWT tag even though it is redundant=20 - Has a COSE tag [JLS] Yes =20 Additionally, one might interpret CBORbis 4.2.2 to say the the CWT tag = should not be present. [JLS] For deterministic encoding, but not for general encoding. =20 6) Application/CWT; cose-type=3DCOSE_Sign1 (or Mac0 or =E2=80=A6) - No tags are used - Identification is completely by the MIME type header - (I understand that the cose-type MIME parameter is not defined, but it = could be. 8392 doesn=E2=80=99t forbid it) [JLS] Yes you could do that, and as I stated in a previous mail this is = not a good idea for the CoAP world. =20 7) A protocol like FIDO identifies a protocol element that is an = attention type the type of which is CWT with COSE_Sign1 - No tags are used [JLS] yes =20 8) A protocol like FIDO identifies a protocol element that is an = attention type the type of which is CWT; the COSE type is determined by = tag - No CWT tag - Has a COSE tag [JLS] yes =20 The one thing you can=E2=80=99t do is have a CWT tag without a COSE type = tag. 8392 section 6 forbids this. =20 [JLS] There however is a set of nested cases that you might need to look = at. That is 6.CWT ( COSE_Encrypt_Tagged ( COSE_Sign )) You would also = need to think about the requirements for nested COSE layers. =20 All but the most outer COSE type are always identified by a tag, per 7.1 = step 5 and 7.2 step 6, right? [JLS] Yes I guess that is true. I think my code is more generous that = this in terms of what is accepted. Jim =20 =20 LL =20 =20 Jim =20 =20 LL =20 =20 =20 =20 On Aug 11, 2020, at 12:20 PM, Laurence Lundblade > wrote: =20 =20 On Aug 10, 2020, at 5:49 PM, Jim Schaad > wrote: =20 This is all based on my understanding that the surrounding protocol for = must specify exactly when CBOR tags are to be used and when they are not = to be used and that the surrounding protocol must not leave it as an = optional implementation choice. In this case application/cwt is the = supporting protocol. =20 [JLS] What is the text that says that this is true. This would be a = surprising statement for me. =20 Here=E2=80=99s three things that lead me to this. =20 CBORbis The sentence of the first paragraph in 4.2.2 = = very clearly states this, though this is only for deterministic = encoding. =20 Typical CDDL Most CDDL that describes tagged data describes it only as tagged or = untagged, not as optionally tagged. COSE is one example of this.=20 =20 Email threads This thread = and this thread = . =20 I summarized this behavior in this email = = and no where in the rest of the thread was it indicated differently. =20 So, it is not a hard requirement because 4.2.2 is only for deterministic = encoding, but seems like a =E2=80=9Cshould" in spirit. It is the = preferred way to design a CBOR protocol. =20 However you slice it, I think it is up to the surrounding protocol to = say whether a tag is always required, never required or optionally = required. If the protocol doesn=E2=80=99t say, then it defaults to = optionally required. =20 Defaulting or explicitly allowing optional tagging means the receiver = has to allow for all the tagging scenarios and makes possible the error = case where the surrounding protocol says the data is of one type and the = tag conflicts with it. (e.g. an application/cwt that contains a tagged = CoSWID). =20 I don=E2=80=99t think optional tagging is of any advantage in a protocol = design. It doesn=E2=80=99t enable anything. =20 It has some disadvantage because it introduces error conditions and = potential confusion. =20 I think there are several scenarios with section 6 and application/cwt = that could be more clear. =20 Can you use tag 61 or not? I think the current answer is that in = application/cwt, tag 61 is optional. =20 How do you know what the COSE type is? It is somewhat obvious that COSE = tags will work, but there is no requirement to use them. A MIME = parameter or other is entirely allowed here. =20 Section 6 does say that determination that something is a CWT is = application dependent, but doesn=E2=80=99t say that the COSE type is = also application dependent. Section 7 does address this. =20 Said another way, my fully general CWT decoder that is called by some = application needs an input parameter to indicate the COSE type because = there is no requirement in 8392 that a CWT indicate which COSE type is = in use. Sometimes the caller will be able to provide the COSE type and = sometimes they won=E2=80=99t. Sometimes there will be an error of = conflicting COSE type and sometimes the error will be that the COSE type = can=E2=80=99t be determined. =20 I think it would have been cleanest if CWT always indicated the COSE = type be used and the tagging optionality didn=E2=80=99t span two = protocol layers, but that would be an incompatible change. Maybe a = recommendation that CWT=E2=80=99s SHOULD always indicate their COSE = type? =20 LL =20 _______________________________________________ Ace mailing list Ace@ietf.org = https://www.ietf.org/mailman/listinfo/ace =20 ------=_NextPart_000_00D3_01D672F9.2BEE0290 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

 

 

From: Laurence Lundblade = <lgl@island-resort.com>
Sent: Saturday, August 15, 2020 = 10:58 AM
To: Jim Schaad = <ietf@augustcellars.com>
Cc: cose <cose@ietf.org>; = Ace Wg <ace@ietf.org>
Subject: Re: [Ace] [COSE] Gap in = registration of application/cwt?

 

 



On Aug 14, 2020, at 3:35 PM, Jim Schaad <ietf@augustcellars.com> = wrote:

 

 

 

From: Laurence Lundblade <lgl@island-resort.com> 
Sent: Friday, August 14, 2020 1:59 = PM
To: Jim = Schaad <ietf@augustcellars.com>
= Cc: Ace Wg <ace@ietf.org>; cose <cose@ietf.org>
Subject: Re: [COSE] Gap in = registration of application/cwt?

 

Here=E2=80=99s a series of scenarios that I think are = legal CWT. These are allowed by RFC 8392, = right?

 

1) Explicitly tagged, no external type info = needed

- Has = CWT tag

- Has = COSE type tag

[JLS] = Yes

 

2) CWT identification by label, COSE type = tagged

- The = CWT is a CBOR data item with a label. The definition of the label says = the contents of the label are always = CWT

- No CWT = tag necessary as it is implied by the = label

- Has a = COSE type tag

[JLS] Yes, = the label could be internal to the CBOR object or external such as an = media-type

 

I = was being very specific with the term label, meaning a label/key = identifying an item in a CBOR map.



 

3) CWT and COSE by = label

- The CWT = is an item with a label. The definition of the label says the contents = of the label are always CWT and of a specific COSE = type

- No tags = necessary

[JLS] Yes that = would be fine

 

4) Application/CWT identifies content as CWT, tagging = for COSE type

- = No CWT tag

- = Has a COSE tag

[JLS] This = is the same as 2?  I don=E2=80=99t think that it would be = restricted to just that media = type.

 

You mean there could be other media types that also = identify the content as CWT?

[JLS] = Yes this could be done in the future. =C2=A0=C2=A0One would normally = expect this to be an application specific profile, but funny things = happen.

 

5) Application/CWT identifies content as = CWT

- Has CWT = tag even though it is = redundant 

- Has a COSE tag

[JLS] = Yes

 

Additionally, one might interpret CBORbis 4.2.2 to say = the the CWT tag should not be present.

[JLS] For deterministic encoding, but not =C2=A0for = general encoding.

 

6) Application/CWT; cose-type=3DCOSE_Sign1 (or Mac0 or = =E2=80=A6)

- No = tags are used

- = Identification is completely by the MIME type = header

- (I = understand that the cose-type MIME parameter is not defined, but it = could be. 8392 doesn=E2=80=99t forbid it)

[JLS] Yes you could do that, and as I stated in a = previous mail this is not a good idea for the CoAP = world.

 

7) A protocol like FIDO identifies a protocol element = that is an attention type the type of which is CWT with = COSE_Sign1

- No = tags are used

[JLS] = yes

 

8) A protocol like FIDO identifies a protocol element = that is an attention type the type of which is CWT; the COSE type is = determined by tag

- No CWT tag

- Has a COSE tag

[JLS] yes

 

The one thing you can=E2=80=99t do is have a CWT tag = without a COSE type tag. 8392 section 6 forbids = this.

 

[JLS] There however is a set of nested cases that you = might need to look at.  That is 6.CWT ( COSE_Encrypt_Tagged ( = COSE_Sign ))  You would also need to think about the requirements = for nested COSE = layers.

 

All but the most outer COSE type are always identified = by a tag, per 7.1 step 5 and 7.2 step 6, right?

[JLS] Yes I guess that is true.=C2=A0 I think my code = is more generous that this in terms of what is = accepted.

Jim

 

 

LL

 



 

Jim

 

 

LL

 

 

 

 




On Aug 11, 2020, at 12:20 PM, Laurence Lundblade = <lgl@island-resort.com> = wrote:

 

 




On Aug 10, 2020, at 5:49 PM, Jim Schaad <ietf@augustcellars.com> = wrote:

 

This is all based on my understanding that the = surrounding protocol for must specify exactly when CBOR tags are to be = used and when they are not to be used and that the surrounding protocol = must not leave it as an optional implementation choice. In this case = application/cwt is the supporting = protocol.

 

[JLS] What is the text that says that this is = true.  This would be a surprising statement for = me.

 

Here=E2=80=99s three things that lead me to = this.

 

CBORbis

The sentence of the first paragraph in 4.2.2 very clearly states this, though this is only for = deterministic encoding.

 

Typical = CDDL

Most = CDDL that describes tagged data describes it only as tagged or untagged, = not as optionally tagged.  COSE is one example of = this. 

 

Email = threads

 

I summarized this behavior in this email and no where in the rest of the thread was it = indicated differently.

 

So, it is not a hard requirement because 4.2.2 is only = for deterministic encoding, but seems like a =E2=80=9Cshould" in = spirit. It is the preferred way to design a CBOR = protocol.

 

However you slice it, I think it is up to the = surrounding protocol to say whether a tag is always required, never = required or optionally required. If the protocol doesn=E2=80=99t say, = then it defaults to optionally = required.

 

Defaulting or explicitly allowing optional tagging = means the receiver has to allow for all the tagging scenarios and makes = possible the error case where the surrounding protocol says the data is = of one type and the tag conflicts with it. (e.g. an application/cwt that = contains a tagged CoSWID).

 

I don=E2=80=99t think optional tagging is of any = advantage in a protocol design. It doesn=E2=80=99t enable = anything.

 

It has some disadvantage because it introduces error = conditions and potential = confusion.

 

I think there are several scenarios with section 6 and = application/cwt that could be more = clear.

 

Can you use tag 61 or not? I = think the current answer is that in application/cwt, tag 61 is = optional.

 

How do you know what the COSE type is? It is somewhat = obvious that COSE tags will work, but there is no requirement to use = them. A MIME parameter or other is entirely allowed = here.

 

Section 6 does say that determination that something = is a CWT is application dependent, but doesn=E2=80=99t say that the COSE = type is also application dependent. Section 7 does address = this.

 

Said another way, my fully general CWT decoder that is = called by some application needs an input parameter to indicate the COSE = type because there is no requirement in 8392 that a CWT indicate which = COSE type is in use. Sometimes the caller will be able to provide the = COSE type and sometimes they won=E2=80=99t. Sometimes there will be an = error of conflicting COSE type and sometimes the error will be that the = COSE type can=E2=80=99t be = determined.

 

I think it would have been cleanest if CWT always = indicated the COSE type be used and the tagging optionality = didn=E2=80=99t span two protocol layers, but that would be an = incompatible change.  Maybe a recommendation that CWT=E2=80=99s = SHOULD always indicate their COSE = type?

 

LL

<= /div>

 

____________= ___________________________________
Ace mailing list
Ace@ietf.org=
<= a href=3D"https://www.ietf.org/mailman/listinfo/ace">https://www.= ietf.org/mailman/listinfo/ace

 

------=_NextPart_000_00D3_01D672F9.2BEE0290-- From nobody Sat Aug 15 14:50:40 2020 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 859E23A0906; Sat, 15 Aug 2020 14:50:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham 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 20zKCKJeNEQM; Sat, 15 Aug 2020 14:50:37 -0700 (PDT) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C5BE83A08FF; Sat, 15 Aug 2020 14:50:28 -0700 (PDT) Received: from Jude (73.180.8.170) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Sat, 15 Aug 2020 14:50:03 -0700 From: Jim Schaad To: CC: 'Ace Wg' Date: Sat, 15 Aug 2020 14:50:02 -0700 Message-ID: <00dd01d6734e$09020920$1b061b60$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Thread-Index: AdZzJ+68Pxgn1F8vR8KWNZXGDlhvyA== Content-Language: en-us X-Originating-IP: [73.180.8.170] Archived-At: Subject: [Ace] Review of draft-ietf-ace-mqtt-tls-profile-06 X-BeenThere: ace@ietf.org 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: Sat, 15 Aug 2020 21:50:39 -0000 Section 2.2.3 - /Clean Start to 0/Clean Start to 0, specify the previous session number/ - I think it should be stated that the session number is provided, which is what the state is associated with. Section 2.2.4 - Last sentence. There is a difference between the connect and re-auth flows in that the first and last messages are going to be AUTH '25', AUTH '0' not CONNECT/CONNACK. Everything else does stay the same. - Might just want to say a similar flow and point forward. Section 2.2.6.1 - I am not sure where you got this from: "Note that this is different in MQTT v5.0, the Broker is allowed to process AUTH packets even if the Broker rejects the CONNECT)." I think that if the broker rejects the connect it must CONNACK and disconnect. Section 3.1 - Missed a case of "publish_+/topic3" Jim From nobody Sun Aug 16 12:14:00 2020 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 594053A0AE2; Sun, 16 Aug 2020 12:13:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: 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=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 DjtGE_H5ZxIy; Sun, 16 Aug 2020 12:13:57 -0700 (PDT) Received: from mail-ua1-x92f.google.com (mail-ua1-x92f.google.com [IPv6:2607:f8b0:4864:20::92f]) (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 010133A0A50; Sun, 16 Aug 2020 12:13:56 -0700 (PDT) Received: by mail-ua1-x92f.google.com with SMTP id v20so4133651ual.4; Sun, 16 Aug 2020 12:13:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=5aqaecNCKzfofen1ygEQD42wJy7OGyC51xWl0KP7ALQ=; b=W+4pBL/BsqyadNZjYFlTL+NBe3JYe7rN9gHNmgq2G2Kyqb4JwwQJLRgRf497uNyGkr gddINYzv4XBTG1Jv5df5+fB4zrQcMcwmBxyRglW8Q9U1+XO7yrSXvl6x0KOyw6KiVspx ZyZlJjgcz7TOcHfT5z5wtdyXl0TnmrKU4hJdRYkylrNe8EqcBb9h2QiYl/g1o45WgpTm ygBypHCJT5hIxhFV1Y2qBcIRjnMOsAOm17Bdr5gLUZE9XoJu6O5Pdbx5tpLDMDqvKZCn e3NXlLdbqdpDouB3aKpcPBk2qz8zBO9yepw7XhvbiF11astgczy0sgKOriRTsZfZcoYK PQbw== 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=5aqaecNCKzfofen1ygEQD42wJy7OGyC51xWl0KP7ALQ=; b=JW+9X0dRKsfCbr2cVg49Eevuqefyh/WIPjJcq5tGDQnfyzsXxAIGijE8sp+ft3qXvL 6x5QPAZB5QxA9J2L42ngvtY3SLf+CcarNkDo2mpXFHNMjM+NmNzZZGumDA0ZrgS2bWHf h8BCyN7k1Dlzqb2bua9dai9is7agt2RorFBCOAXcosOmebmQSSQX9xSlygVMgai5hfoV OHQhF+4iTZShQf4tnTZS7y6cV7nvublncAHBaNBrVjdLHd2NkGXz06pRjBYh0BZ1QUH2 0G12NY3NyWd9b1QFZfikY+KveRd6TMLRPCnCFrJFM0FSE09PHk+/p9YZ9/tRA6h5QckN iXpw== X-Gm-Message-State: AOAM532QHvkPfK53cD7goGYj2Xc6EOsK5V0BsGesgQa0w2zxP4ZdV8az P/GXZgH79zrkK6InEkRjPSyyEsa7sejrN2O0mOk0GwfCr8Kz8g== X-Google-Smtp-Source: ABdhPJweQtfDp0QztiBRE7pXwU7FMpgP/x/mduDdBjMgJOh+u+DzX5Q3wtNp1bGVFQvDxnD8ng9Oscdf8DAY7jL+qSI= X-Received: by 2002:ab0:7684:: with SMTP id v4mr6211780uaq.36.1597605235837; Sun, 16 Aug 2020 12:13:55 -0700 (PDT) MIME-Version: 1.0 References: <00dd01d6734e$09020920$1b061b60$@augustcellars.com> In-Reply-To: <00dd01d6734e$09020920$1b061b60$@augustcellars.com> From: Cigdem Sengul Date: Sun, 16 Aug 2020 20:13:44 +0100 Message-ID: To: Jim Schaad Cc: draft-ietf-ace-mqtt-tls-profile@ietf.org, Ace Wg Content-Type: multipart/alternative; boundary="00000000000092ce3905ad03749c" Archived-At: Subject: Re: [Ace] Review of draft-ietf-ace-mqtt-tls-profile-06 X-BeenThere: ace@ietf.org 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: Sun, 16 Aug 2020 19:13:58 -0000 --00000000000092ce3905ad03749c Content-Type: text/plain; charset="UTF-8" Hello Jim, Responses inside. On Sat, Aug 15, 2020 at 10:50 PM Jim Schaad wrote: > Section 2.2.3 - /Clean Start to 0/Clean Start to 0, specify the previous > session number/ - I think it should be stated that the session number is > provided, which is what the state is associated with. > > To the best of my knowledge, and from what I read from the MQTT v5 spec: The ClientID MUST be used by Clients and by Servers to identify state that they hold relating to this MQTT Session between the Client and the Server. I do not think the server uses anything other than the Client ID to look up the state. > Section 2.2.4 - Last sentence. There is a difference between the connect > and re-auth flows in that the first and last messages are going to be AUTH > '25', AUTH '0' not CONNECT/CONNACK. Everything else does stay the same. - > Might just want to say a similar flow and point forward. > > Will clarify that this is only for CONNECT as it is under section 2- Authorizing Connection Requests. Will direct to section 4 for re-authentication. > Section 2.2.6.1 - I am not sure where you got this from: "Note that this is > different in MQTT v5.0, the Broker is allowed to process AUTH packets even > if the Broker rejects the CONNECT)." I think that if the broker rejects > the > connect it must CONNACK and disconnect. > I've got that from MQTT v5 spec: If a Client sets an Authentication Method in the CONNECT, the Client MUST NOT send any packets other than AUTH or DISCONNECT packets until it has received a CONNACK packet [MQTT-3.1.2-30]. and: If the Server rejects the CONNECT, it MUST NOT process any data sent by the Client after the CONNECT packet except AUTH packets [MQTT-3.1.4-6]. So, the spec allows clients to send AUTH after CONNECT before CONNACK, and servers to process AUTH after CONNECT (before CONNACK I suppose). I agree the wording may be confusing: What I want to say is that: the servers in our profile do not process anything after CONNECT before CONNACK. So, the AUTH flow is strictly initiated by the server during the connection handshake. After that, the client may do AUTH first, for re-authentication. > Section 3.1 - Missed a case of "publish_+/topic3" > Yes, in previous version, example was for publish only for topic3. I thought I should give a pub/sub, pub only, and sub only examples. Is that OK? Thanks, --Cigdem > > Jim > > > _______________________________________________ > Ace mailing list > Ace@ietf.org > https://www.ietf.org/mailman/listinfo/ace > --00000000000092ce3905ad03749c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello Jim,=C2=A0
Responses inside.=C2= =A0

On Sat, Aug 15, 2020 at 10:50 PM Jim Schaad <ietf@augustcellars.com> wrote:
Section 2.2.3 - /Clean Start = to 0/Clean Start to 0, specify the previous
session number/=C2=A0 - I think it should be stated that the session number= is
provided, which is what the state is associated with.


To the best of my knowledge, and from = what I read from the MQTT v5 spec:
The ClientID MUST be used by Clients and by Servers to identi= fy state that they hold relating to this MQTT Session between the Client an= d the Server.=C2=A0
I do not think the server uses anythin= g other than the Client ID to look up the state.=C2=A0=C2=A0
=C2= =A0
Section 2.2.4 - Last sentence.=C2=A0 There is a difference between the conn= ect
and re-auth flows in that the first and last messages are going to be AUTH<= br> '25', AUTH '0' not CONNECT/CONNACK.=C2=A0 Everything else d= oes stay the same. -
Might just want to say a similar flow and point forward.

Will clarify that this is only for CONNECT as it is u= nder section 2-=C2=A0A= uthorizing Connection Requests.=C2=A0
Will direct to section 4 for re-authentica= tion.
=C2=A0
Section 2.2.6.1 - I am not sure where you got this from: "Note that th= is is
different in MQTT v5.0, the Broker is allowed to process AUTH packets even<= br> if the Broker rejects the CONNECT)."=C2=A0 I think that if the broker = rejects the
connect it must CONNACK and disconnect.=C2=A0

I've got that from MQTT v5 spec:

If a Client sets an Authent= ication Method in the CONNECT, the Client MUST NOT send any packets other t= han AUTH or DISCONNECT packets until it has received a CONNACK packet=C2=A0[MQTT-3.1.2-30].

=C2=A0and:

If the= Server rejects the CONNECT, it MUST NOT process any data sent by the Clien= t after the CONNECT packet except AUTH packets=C2=A0[M= QTT-3.1.4-6].=C2=A0

So, the s= pec allows clients to send AUTH after CONNECT before CONNACK, and servers t= o process AUTH after CONNECT (before CONNACK I suppose).=C2=A0
I agree the wording may=C2=A0 be confusing:
What I w= ant to say is that: the servers in our profile do not process anything afte= r CONNECT before CONNACK.=C2=A0
So, the AUTH flow is strictly ini= tiated by the server during the connection handshake.
After that,= the client may do AUTH first, for re-authentication.=C2=A0

<= /div>

Section 3.1 - Missed a case of "publish_+/topic3"
Yes, in previous=C2=A0version, example was for publish only for topic= 3.
I thought I should give a pub/sub, pub only, and sub only exam= ples.=C2=A0
Is that OK?

Thanks,
--Cigdem=C2=A0

=C2=A0

Jim


_______________________________________________
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace
--00000000000092ce3905ad03749c-- From nobody Sun Aug 16 13:10:43 2020 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2258F3A10F5; Sun, 16 Aug 2020 13:10:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham 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 taZ-B39RuHSV; Sun, 16 Aug 2020 13:10:38 -0700 (PDT) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D97883A0B95; Sun, 16 Aug 2020 13:10:37 -0700 (PDT) Received: from Jude (73.180.8.170) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Sun, 16 Aug 2020 13:10:28 -0700 From: Jim Schaad To: 'Cigdem Sengul' CC: , 'Ace Wg' References: <00dd01d6734e$09020920$1b061b60$@augustcellars.com> In-Reply-To: Date: Sun, 16 Aug 2020 13:10:27 -0700 Message-ID: <00f601d67409$4a3f04e0$debd0ea0$@augustcellars.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00F7_01D673CE.9DE33A20" X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQMqeFZNts+Ba8La03OrSbr3Xch6qAHBpxSwpoURffA= Content-Language: en-us X-Originating-IP: [73.180.8.170] Archived-At: Subject: Re: [Ace] Review of draft-ietf-ace-mqtt-tls-profile-06 X-BeenThere: ace@ietf.org 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: Sun, 16 Aug 2020 20:10:42 -0000 ------=_NextPart_000_00F7_01D673CE.9DE33A20 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable =20 =20 From: Cigdem Sengul =20 Sent: Sunday, August 16, 2020 12:14 PM To: Jim Schaad Cc: draft-ietf-ace-mqtt-tls-profile@ietf.org; Ace Wg Subject: Re: [Ace] Review of draft-ietf-ace-mqtt-tls-profile-06 =20 Hello Jim,=20 Responses inside.=20 =20 On Sat, Aug 15, 2020 at 10:50 PM Jim Schaad > wrote: Section 2.2.3 - /Clean Start to 0/Clean Start to 0, specify the previous session number/ - I think it should be stated that the session number = is provided, which is what the state is associated with. =20 To the best of my knowledge, and from what I read from the MQTT v5 spec: The ClientID MUST be used by Clients and by Servers to identify state = that they hold relating to this MQTT Session between the Client and the = Server.=20 I do not think the server uses anything other than the Client ID to look = up the state. =20 [JLS] I got the name wrong, the need for the identifier remains. =20 Section 2.2.4 - Last sentence. There is a difference between the = connect and re-auth flows in that the first and last messages are going to be = AUTH '25', AUTH '0' not CONNECT/CONNACK. Everything else does stay the same. = - Might just want to say a similar flow and point forward. Will clarify that this is only for CONNECT as it is under section 2- = Authorizing Connection Requests.=20 Will direct to section 4 for re-authentication. =20 Section 2.2.6.1 - I am not sure where you got this from: "Note that this = is different in MQTT v5.0, the Broker is allowed to process AUTH packets = even if the Broker rejects the CONNECT)." I think that if the broker rejects = the connect it must CONNACK and disconnect. =20 =20 I've got that from MQTT v5 spec: If a Client sets an Authentication Method in the CONNECT, the Client = MUST NOT send any packets other than AUTH or DISCONNECT packets until it = has received a CONNACK packet [MQTT-3.1.2-30]. and: If the Server rejects the CONNECT, it MUST NOT process any data sent by = the Client after the CONNECT packet except AUTH packets [MQTT-3.1.4-6].=20 =20 [JLS] I read this as the following would not do the publish CONNECT --> PUBLISH --> <-- AUTH AUTH --> <-- CONNACK fail The PUBLISH can be received but is not processed unless the CONNACK is = going to be a success. [/JLS] =20 So, the spec allows clients to send AUTH after CONNECT before CONNACK, = and servers to process AUTH after CONNECT (before CONNACK I suppose).=20 =20 I agree the wording may be confusing: What I want to say is that: the servers in our profile do not process = anything after CONNECT before CONNACK.=20 So, the AUTH flow is strictly initiated by the server during the = connection handshake. After that, the client may do AUTH first, for re-authentication.=20 [JLS] Given that a client may only send an AUTH in response to an AUTH, = I don=E2=80=99t know how much this is needed. =20 [JLS] I think if you just delete the aside (in parens) then it says = what needs to be said and is not confusing. =20 =20 Section 3.1 - Missed a case of "publish_+/topic3" Yes, in previous version, example was for publish only for topic3. I thought I should give a pub/sub, pub only, and sub only examples.=20 Is that OK? =20 Yes, I was just pointing out that this was using the old syntax. = Nothing more. =20 Jim =20 =20 Thanks, --Cigdem=20 =20 =20 Jim _______________________________________________ Ace mailing list Ace@ietf.org =20 https://www.ietf.org/mailman/listinfo/ace ------=_NextPart_000_00F7_01D673CE.9DE33A20 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

 

 

From: Cigdem Sengul = <cigdem.sengul@gmail.com>
Sent: Sunday, August 16, 2020 = 12:14 PM
To: Jim Schaad = <ietf@augustcellars.com>
Cc: = draft-ietf-ace-mqtt-tls-profile@ietf.org; Ace Wg = <ace@ietf.org>
Subject: Re: [Ace] Review of = draft-ietf-ace-mqtt-tls-profile-06

 

Hello Jim, 

Responses inside. 

 

On = Sat, Aug 15, 2020 at 10:50 PM Jim Schaad <ietf@augustcellars.com> = wrote:

Section 2.2.3 - /Clean Start to 0/Clean = Start to 0, specify the previous
session number/  - I think it = should be stated that the session number is
provided, which is what = the state is associated with.

 

To the best of my knowledge, and from what I read from = the MQTT v5 spec:

The ClientID MUST be used by Clients and by Servers to = identify state that they hold relating to this MQTT Session between the = Client and the Server. 

I do not think the server uses anything other than the = Client ID to look up the state.  

[JLS] I got the name wrong, the need for the = identifier remains.

 

Section 2.2.4 - Last sentence.  = There is a difference between the connect
and re-auth flows in that = the first and last messages are going to be AUTH
'25', AUTH '0' not = CONNECT/CONNACK.  Everything else does stay the same. -
Might = just want to say a similar flow and point = forward.

Will = clarify that this is only for CONNECT as it is under section = 2- Authorizing = Connection Requests. 

Will = direct to section 4 for = re-authentication.

 

Section = 2.2.6.1 - I am not sure where you got this from: "Note that this = is
different in MQTT v5.0, the Broker is allowed to process AUTH = packets even
if the Broker rejects the CONNECT)."  I think = that if the broker rejects the
connect it must CONNACK and = disconnect. 

 

I've got that from MQTT v5 = spec:

If a Client sets an Authentication Method in the CONNECT, = the Client MUST NOT send any packets other than AUTH or DISCONNECT = packets until it has received a CONNACK packet&nb= sp;[MQTT= -3.1.2-30].

&nb= sp;and:

If the Server rejects the CONNECT, it MUST NOT process = any data sent by the Client after the CONNECT packet except AUTH = packets&nb= sp;[MQTT= -3.1.4-6]. 

 

[JLS] I read this as the following would not do the = publish

CONNECT =C3=A0

PUBLISH =C3=A0

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C3=9F AUTH

AUTH =C3=A0

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C3=9F CONNACK = fail

The PUBLISH can be received but = is not processed unless the CONNACK is going to be a = success.

[/JLS]

 

So, the spec allows clients to send AUTH after CONNECT = before CONNACK, and servers to process AUTH after CONNECT (before = CONNACK I suppose). 

 

I = agree the wording may  be confusing:

What I want to say is that: the servers in our profile = do not process anything after CONNECT before = CONNACK. 

So, the = AUTH flow is strictly initiated by the server during the connection = handshake.

After that, the = client may do AUTH first, for re-authentication. 

[JLS] Given that a client may only send an AUTH in = response to an AUTH, I don=E2=80=99t know how much this is = needed.

 

[JLS]=C2=A0 I think if you just delete the aside (in = parens) then it says what needs to be said and is not = confusing.

 

 


Section 3.1 - Missed a case of = "publish_+/topic3"

Yes, in previous version, example was for publish = only for topic3.

I thought = I should give a pub/sub, pub only, and sub only = examples. 

Is that = OK?

 

Yes, I was just pointing out that this was using the = old syntax.=C2=A0 Nothing more.

 

Jim

 

 

Thanks,

--Cigdem 

 

 


Jim


____________________________________= ___________
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace

------=_NextPart_000_00F7_01D673CE.9DE33A20-- From nobody Mon Aug 17 08:49:48 2020 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B4CA53A0CDF; Mon, 17 Aug 2020 08:49:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: 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=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 oLbm0qP4W5Xo; Mon, 17 Aug 2020 08:49:44 -0700 (PDT) Received: from mail-ua1-x929.google.com (mail-ua1-x929.google.com [IPv6:2607:f8b0:4864:20::929]) (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 756CB3A0CD9; Mon, 17 Aug 2020 08:49:44 -0700 (PDT) Received: by mail-ua1-x929.google.com with SMTP id g20so4884099uan.7; Mon, 17 Aug 2020 08:49:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=cPJhwx4GuZhLSgcwTm0qrDRVk484yGZzvz/04meASTM=; b=kR9SwIcruT5VXHwnq9nvKTkrcJUrqLsomqttZhS4tIfFsigmyTYJxFVJLiXBYQJA3i aqK+VkdH6Su7WG1O8N0kB0k5kDhL5sosNt5BvbseiEjVC1hRAinQtbDoHp2/qQalMSI+ P9IhneHEHqZQel7kev3/Er3ogqJFUOmq6+OC+3thD5+YnEi7CYmOFDrm5nIxW0e3e3s+ 2nYDbU6BDWGCwXsLIt2eK2dbT9DUu7Hi+J2ELiEwJvZX+/wawhPkW6egRNuE4TWJseWM P2FtjwdtvEL1kUFZcKUeff5KGx2zDhiGn29uZeVWYThUWZDveBG+e8jpKkrxFJIz47zG rSIw== 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=cPJhwx4GuZhLSgcwTm0qrDRVk484yGZzvz/04meASTM=; b=GY5IfMUh7Ql1nSruBi4BVyCebUgKKFQE3TMLFK6odebJFsvEgn0XKvCTW4FXdGD3BM gLkeAG1ZePsCddNubbfzDKbPiRpjD8BsaOw7R1j1jZiRHy5DtITuIcSwTx318+EfWYTI ikaApOFXrZr3bQu/ynWaIN6yVerVN/v2beysllWGtAYs+rcC2YJqLdgbJNixS3DG7ffa CP122boYuf2shv5TWQ0NR3tAvR4KBs8BQrthNh2/r7ZP2vJylNvZFRZ5SiA6BVp55N4A YO6v58yZ5NTUcoUKGlRWFDaNlYg70nG5Pm9nW+Jw18qQplnpL0ZdjLf3ihNUgJSt9Tiz JkuQ== X-Gm-Message-State: AOAM533acl5VNJ7Kb8pVZpGWtiWzm+pI44jCj6d7dnY/GHJnWELxIsHI f9JZjq3cUjT+SnKUPitY9w5cE6deN3CdwGeK3TcR1xpijdoX9g== X-Google-Smtp-Source: ABdhPJyWbJGI0KZ9RjHvJkjmfimOYoWe8Xt6uo4yQTfPsCz9ehEoSMFdh0iSYElHGBCIU11cSgrXMPAV62DYppaYbpY= X-Received: by 2002:ab0:7684:: with SMTP id v4mr8372362uaq.36.1597679383310; Mon, 17 Aug 2020 08:49:43 -0700 (PDT) MIME-Version: 1.0 References: <00dd01d6734e$09020920$1b061b60$@augustcellars.com> <00f601d67409$4a3f04e0$debd0ea0$@augustcellars.com> In-Reply-To: <00f601d67409$4a3f04e0$debd0ea0$@augustcellars.com> From: Cigdem Sengul Date: Mon, 17 Aug 2020 16:49:33 +0100 Message-ID: To: Jim Schaad Cc: draft-ietf-ace-mqtt-tls-profile@ietf.org, Ace Wg Content-Type: multipart/alternative; boundary="0000000000001b779005ad14b82e" Archived-At: Subject: Re: [Ace] Review of draft-ietf-ace-mqtt-tls-profile-06 X-BeenThere: ace@ietf.org 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, 17 Aug 2020 15:49:47 -0000 --0000000000001b779005ad14b82e Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hello Jim, Responses inside. > > > > On Sat, Aug 15, 2020 at 10:50 PM Jim Schaad > wrote: > > Section 2.2.3 - /Clean Start to 0/Clean Start to 0, specify the previous > session number/ - I think it should be stated that the session number is > provided, which is what the state is associated with. > > > > To the best of my knowledge, and from what I read from the MQTT v5 spec: > > The ClientID MUST be used by Clients and by Servers to identify state tha= t > they hold relating to this MQTT Session between the Client and the Server= . > > I do not think the server uses anything other than the Client ID to look > up the state. > > [JLS] I got the name wrong, the need for the identifier remains. > [CS] I see - I realise I did a shortcut to say MQTT broker keep session state. Actually, I think I should give examples of session state as I need to explain what could be problematic by identifying state only with client-id as discussed in the last IETF meeting. (i.e., The Session State in the Client consists of: =C2=B7 QoS 1 and QoS 2 messages which have been sent to the Server,= but have not been completely acknowledged. =C2=B7 QoS 2 messages which have been received from the Server, but= have not been completely acknowledged. The Session State in the Server consists of: =C2=B7 The existence of a Session, even if the rest of the Session = State is empty. =C2=B7 The Clients subscriptions, including any Subscription Identi= fiers. =C2=B7 QoS 1 and QoS 2 messages which have been sent to the Client,= but have not been completely acknowledged. =C2=B7 QoS 1 and QoS 2 messages pending transmission to the Client = and OPTIONALLY QoS 0 messages pending transmission to the Client. =C2=B7 QoS 2 messages which have been received from the Client, but= have not been completely acknowledged.The Will Message and the Will Delay Interval =C2=B7 If the Session is currently not connected, the time at which= the Session will end and Session State will be discarded. ) > > Section 2.2.4 - Last sentence. There is a difference between the connect > and re-auth flows in that the first and last messages are going to be AUT= H > '25', AUTH '0' not CONNECT/CONNACK. Everything else does stay the same. = - > Might just want to say a similar flow and point forward. > > Will clarify that this is only for CONNECT as it is under section 2- Auth= orizing > Connection Requests. > > Will direct to section 4 for re-authentication. > > > > Section 2.2.6.1 - I am not sure where you got this from: "Note that this = is > different in MQTT v5.0, the Broker is allowed to process AUTH packets eve= n > if the Broker rejects the CONNECT)." I think that if the broker rejects > the > connect it must CONNACK and disconnect. > > > > I've got that from MQTT v5 spec: > > If a Client sets an Authentication Method in the CONNECT, the Client MUST > NOT send any packets other than AUTH or DISCONNECT packets until it has > received a CONNACK packet [MQTT-3.1.2-30]. > > and: > > If the Server rejects the CONNECT, it MUST NOT process any data sent by > the Client after the CONNECT packet except AUTH packets [MQTT-3.1.4-6]. > > > > [JLS] I read this as the following would not do the publish > > CONNECT =C3=A0 > > PUBLISH =C3=A0 > > =C3=9F AUTH > > AUTH =C3=A0 > > =C3=9F CONNACK fail > > The PUBLISH can be received but is not processed unless the CONNACK is > going to be a success. > > [/JLS] > [CS] I think this sequence should not happen, as Client MUST NOT send PUBLISH before CONNACK. I did not know what brokers do if they receive PUBLISH (and still processing a CONNECT) - drop or buffer until process. I quickly browsed mosquitto src. It looks like the broker sets a context flag to mark the session active after CONNECT is processed and accepted. If this flag is not set when processing publish, it goes to an error state and doesn't look like it keeps the packet. > > > So, the spec allows clients to send AUTH after CONNECT before CONNACK, an= d > servers to process AUTH after CONNECT (before CONNACK I suppose). > > > > I agree the wording may be confusing: > > What I want to say is that: the servers in our profile do not process > anything after CONNECT before CONNACK. > > So, the AUTH flow is strictly initiated by the server during the > connection handshake. > > After that, the client may do AUTH first, for re-authentication. > > [JLS] Given that a client may only send an AUTH in response to an AUTH, I > don=E2=80=99t know how much this is needed. > > > > [JLS] I think if you just delete the aside (in parens) then it says what > needs to be said and is not confusing. > > > [CS] OK, agreed, less is more in this case. Will delete the parentheses text. > > > > Section 3.1 - Missed a case of "publish_+/topic3" > > Yes, in previous version, example was for publish only for topic3. > > I thought I should give a pub/sub, pub only, and sub only examples. > > Is that OK? > > > > Yes, I was just pointing out that this was using the old syntax. Nothing > more. > [CS] Found it. OK, that was very buggy. Will change to: Following the example in the previous section, a client sending a SUBSCRIBE message to 'a/topic3' would be allowed to subscribe, as the scope includes "["+/topic3",["sub"]]". Thanks again for catching it. --Cigdem > > > Jim > > > > > > Thanks, > > --Cigdem > > > > > > > Jim > > > _______________________________________________ > Ace mailing list > Ace@ietf.org > https://www.ietf.org/mailman/listinfo/ace > > --0000000000001b779005ad14b82e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello Jim,=C2=A0
Responses inside.

=C2=A0

=C2=A0

On Sat, Aug 15, 2020 at = 10:50 PM Jim Schaad <ietf@augustcellars.com> wrote:

Secti= on 2.2.3 - /Clean Start to 0/Clean Start to 0, specify the previous
sess= ion number/=C2=A0 - I think it should be stated that the session number is<= br>provided, which is what the state is associated with.

<= /blockquote>

=C2=A0

=

To the best of my knowledge, and from what I read fr= om the MQTT v5 spec:

The ClientID MUST be used by Clients and by Servers to identify= state that they hold relating to this MQTT Session between the Client and = the Server.=C2=A0

I do not think the server uses anything other than the Client ID to look u= p the state.=C2=A0=C2=A0

[JLS] I go= t the name wrong, the need for the identifier remains.

[CS] I see - I realise I did a shortcut to s= ay MQTT broker keep session state.=C2=A0
Actually, I think I shou= ld give examples of session state as I need to explain what could be proble= matic by identifying state only with client-id as discussed in the last IET= F meeting.=C2=A0
(i.e.,=C2=A0

The Session State in the Client consists of:

=C2=B7=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0QoS 1 and QoS 2 messages which have been se= nt to the Server, but have not been completely acknowledged.

=C2=B7=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0QoS 2 messages which have been received fro= m the Server, but have not been completely acknowledged.

=C2=A0

The Session = State in the Server consists of:

=C2=B7<= span style=3D"font-variant-numeric:normal;font-variant-east-asian:normal;fo= nt-stretch:normal;font-size:7pt;line-height:normal;font-family:"Times = New Roman"">=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0The existence of a Session, even if the rest of the Session State= is empty.

=C2=B7=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0The Client= s subscriptions, including any Subscription Identifiers.

=C2=B7=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0QoS 1 and QoS 2 messages which have been= sent to the Client, but have not been completely acknowledged.

=C2=B7=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0QoS 1 and QoS 2 messages pendin= g transmission to the Client and OPTIONALLY QoS 0 messages pending transmis= sion to the Client.

=C2=B7=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= QoS 2 messages which have been received from the Client, but have not been = completely acknowledged.The Will Message and the Will Delay Interval

=C2=B7=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0If the Session is currently not co= nnected, the time at which the Session will end and Session State will be d= iscarded.

)


=

=C2=A0

Section 2.2.4 - Last sentence.=C2=A0 There is a difference between the = connect
and re-auth flows in that the first and last messages are going = to be AUTH
'25', AUTH '0' not CONNECT/CONNACK.=C2=A0 Eve= rything else does stay the same. -
Might just want to say a similar flow= and point forward.

Will clarify that this is only for CONNECT as it is under section 2-=C2= =A0Authorizing Connection Reques= ts.=C2=A0

Will direct to section 4 for re-authent= ication.

=C2=A0

Section= 2.2.6.1 - I am not sure where you got this from: "Note that this isdifferent in MQTT v5.0, the Broker is allowed to process AUTH packets eve= n
if the Broker rejects the CONNECT)."=C2=A0 I think that if the br= oker rejects the
connect it must CONNACK and disconnect.=C2=A0

=C2=A0

<= /div>

I've got that from MQTT v5 spec:

If a Client sets an Authenti= cation Method in the CONNECT, the Client MUST NOT send any packets other th= an AUTH or DISCONNECT packets until it has received a CONNACK packet= =C2= =A0[MQTT-3.1.2-30].

=C2=A0and:

If the Ser= ver rejects the CONNECT, it MUST NOT process any data sent by the Client af= ter the CONNECT packet except AUTH packets=C2=A0[MQTT-3.1.4-6]= .=C2=A0

=C2=A0

[JLS] I read this as the following would not do the= publish

CONNECT =C3=A0

P= UBLISH =C3=A0

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C3=9F AUTH

AUTH =C3=A0

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 =C3=9F CONNACK fail

The PUBLISH can be r= eceived but is not processed unless the CONNACK is going to be a success.

[/JLS]


[CS] I think this sequence should not = happen, as Client MUST NOT send PUBLISH before CONNACK.
I did not= know what brokers do if they receive PUBLISH (and still processing a CONNE= CT) - drop or buffer until process. I quickly browsed mosquitto src.=C2=A0<= /div>
It looks like the broker sets a context flag to mark the session = active after CONNECT is processed and accepted.=C2=A0
If this fla= g is not set when processing publish,=C2=A0 it goes to an error state and d= oesn't look like it keeps the packet.=C2=A0
=C2=A0

=C2=A0<= u>

So, the spec allows clients to = send AUTH after CONNECT before CONNACK, and servers to process AUTH after C= ONNECT (before CONNACK I suppose).=C2=A0

=C2=A0

= I agree the wording may=C2=A0 be confusing:

What I want to say is that: the servers in our profile = do not process anything after CONNECT before CONNACK.=C2=A0

So, the AUTH flow is strictly initiated= by the server during the connection handshake.

After that, the client may do AUTH first, for re-au= thentication.=C2=A0

[JLS] Given tha= t a client may only send an AUTH in response to an AUTH, I don=E2=80=99t kn= ow how much this is needed.

= =C2=A0

[JLS]=C2=A0 I think if you just del= ete the aside (in parens) then it says what needs to be said and is not con= fusing.

=C2=A0

[CS] OK, agreed, less is more in this= case. Will delete the parentheses text.=C2=A0=C2=A0

=

=C2=A0


Section 3.1 - Missed a case = of "publish_+/topic3"

Yes, in previous=C2=A0version, example was for publish only = for topic3.

I thought I = should give a pub/sub, pub only, and sub only examples.=C2=A0=

Is that OK?

=C2=A0

Yes, I was ju= st pointing out that this was using the old syntax.=C2=A0 Nothing more.

=

[CS] Found i= t. OK, that was very buggy. Will change to:
=C2=A0Following the e= xample in the previous section,
=C2=A0 =C2=A0a client sending a SUBSCR= IBE message to 'a/topic3' would be allowed to
=C2=A0 =C2=A0subsc= ribe, as the scope includes=C2=A0 "["+/topic3",["sub"]]".=

Thanks again for catching it.
--Cigdem=C2=A0

<= /u>=C2=A0

Jim

=C2=A0

=C2=A0

Thanks,<= /p>

--Cigdem=C2=A0

=

=C2=A0

=C2=A0


Jim


____________________________________________= ___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace<= /u>

--0000000000001b779005ad14b82e-- From nobody Mon Aug 17 09:31:23 2020 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DA2B3A11FE; Mon, 17 Aug 2020 09:31:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham 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 2En_zjgloMWt; Mon, 17 Aug 2020 09:31:19 -0700 (PDT) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9C0113A112F; Mon, 17 Aug 2020 09:31:18 -0700 (PDT) Received: from Jude (73.180.8.170) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Mon, 17 Aug 2020 09:31:10 -0700 From: Jim Schaad To: 'Cigdem Sengul' CC: , 'Ace Wg' References: <00dd01d6734e$09020920$1b061b60$@augustcellars.com> <00f601d67409$4a3f04e0$debd0ea0$@augustcellars.com> In-Reply-To: Date: Mon, 17 Aug 2020 09:31:08 -0700 Message-ID: <014901d674b3$d16e19b0$744a4d10$@augustcellars.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_014A_01D67479.25111670" X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQMqeFZNts+Ba8La03OrSbr3Xch6qAHBpxSwAaRV0WACqZVhnKZj+VVA Content-Language: en-us X-Originating-IP: [73.180.8.170] Archived-At: Subject: Re: [Ace] Review of draft-ietf-ace-mqtt-tls-profile-06 X-BeenThere: ace@ietf.org 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, 17 Aug 2020 16:31:22 -0000 ------=_NextPart_000_014A_01D67479.25111670 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable =20 =20 From: Cigdem Sengul =20 Sent: Monday, August 17, 2020 8:50 AM To: Jim Schaad Cc: draft-ietf-ace-mqtt-tls-profile@ietf.org; Ace Wg Subject: Re: [Ace] Review of draft-ietf-ace-mqtt-tls-profile-06 =20 Hello Jim,=20 Responses inside. =20 =20 =20 On Sat, Aug 15, 2020 at 10:50 PM Jim Schaad > wrote: Section 2.2.3 - /Clean Start to 0/Clean Start to 0, specify the previous session number/ - I think it should be stated that the session number = is provided, which is what the state is associated with. =20 To the best of my knowledge, and from what I read from the MQTT v5 spec: The ClientID MUST be used by Clients and by Servers to identify state = that they hold relating to this MQTT Session between the Client and the = Server.=20 I do not think the server uses anything other than the Client ID to look = up the state. =20 [JLS] I got the name wrong, the need for the identifier remains. [CS] I see - I realise I did a shortcut to say MQTT broker keep session = state.=20 Actually, I think I should give examples of session state as I need to = explain what could be problematic by identifying state only with = client-id as discussed in the last IETF meeting.=20 (i.e.,=20 The Session State in the Client consists of: * QoS 1 and QoS 2 messages which have been sent to the Server, = but have not been completely acknowledged. * QoS 2 messages which have been received from the Server, but = have not been completely acknowledged. =20 The Session State in the Server consists of: * The existence of a Session, even if the rest of the Session = State is empty. * The Clients subscriptions, including any Subscription = Identifiers. * QoS 1 and QoS 2 messages which have been sent to the Client, = but have not been completely acknowledged. * QoS 1 and QoS 2 messages pending transmission to the Client = and OPTIONALLY QoS 0 messages pending transmission to the Client. * QoS 2 messages which have been received from the Client, but = have not been completely acknowledged.The Will Message and the Will = Delay Interval * If the Session is currently not connected, the time at which = the Session will end and Session State will be discarded. ) =20 =20 Section 2.2.4 - Last sentence. There is a difference between the = connect and re-auth flows in that the first and last messages are going to be = AUTH '25', AUTH '0' not CONNECT/CONNACK. Everything else does stay the same. = - Might just want to say a similar flow and point forward. Will clarify that this is only for CONNECT as it is under section 2- = Authorizing Connection Requests.=20 Will direct to section 4 for re-authentication. =20 Section 2.2.6.1 - I am not sure where you got this from: "Note that this = is different in MQTT v5.0, the Broker is allowed to process AUTH packets = even if the Broker rejects the CONNECT)." I think that if the broker rejects = the connect it must CONNACK and disconnect. =20 =20 I've got that from MQTT v5 spec: If a Client sets an Authentication Method in the CONNECT, the Client = MUST NOT send any packets other than AUTH or DISCONNECT packets until it = has received a CONNACK packet [MQTT-3.1.2-30]. and: If the Server rejects the CONNECT, it MUST NOT process any data sent by = the Client after the CONNECT packet except AUTH packets [MQTT-3.1.4-6].=20 =20 [JLS] I read this as the following would not do the publish CONNECT --> PUBLISH --> <-- AUTH AUTH --> <-- CONNACK fail The PUBLISH can be received but is not processed unless the CONNACK is = going to be a success. [/JLS] =20 [CS] I think this sequence should not happen, as Client MUST NOT send = PUBLISH before CONNACK. I did not know what brokers do if they receive PUBLISH (and still = processing a CONNECT) - drop or buffer until process. I quickly browsed = mosquitto src.=20 It looks like the broker sets a context flag to mark the session active = after CONNECT is processed and accepted.=20 If this flag is not set when processing publish, it goes to an error = state and doesn't look like it keeps the packet.=20 =20 [JLS] No, Clients are allowed to send further MQTT Control Packets = immediately after sending a CONNECT packet; Clients need not wait for a = CONNACK packet to arrive from the Server. =E2=80=93 this is the = preceding two sentences to requirement MQTT-3.1.4-6. I would agree that = this is going to be server specific. The following paragraph suggests = that clients SHOULD wait for the CONNACK but it is non-normative. I = think that I would write my client code to wait. I would have to work = really hard to figure out what my code base would do for this as I know = it does queue packets for later processing but I am not sure what it = would do for this case. =20 =20 So, the spec allows clients to send AUTH after CONNECT before CONNACK, = and servers to process AUTH after CONNECT (before CONNACK I suppose).=20 =20 I agree the wording may be confusing: What I want to say is that: the servers in our profile do not process = anything after CONNECT before CONNACK.=20 So, the AUTH flow is strictly initiated by the server during the = connection handshake. After that, the client may do AUTH first, for re-authentication.=20 [JLS] Given that a client may only send an AUTH in response to an AUTH, = I don=E2=80=99t know how much this is needed. =20 [JLS] I think if you just delete the aside (in parens) then it says = what needs to be said and is not confusing. =20 [CS] OK, agreed, less is more in this case. Will delete the parentheses = text. =20 =20 Section 3.1 - Missed a case of "publish_+/topic3" Yes, in previous version, example was for publish only for topic3. I thought I should give a pub/sub, pub only, and sub only examples.=20 Is that OK? =20 Yes, I was just pointing out that this was using the old syntax. = Nothing more. =20 [CS] Found it. OK, that was very buggy. Will change to: Following the example in the previous section, a client sending a SUBSCRIBE message to 'a/topic3' would be allowed = to subscribe, as the scope includes "["+/topic3",["sub"]]". =20 Thanks again for catching it. --Cigdem=20 =20 Jim =20 =20 Thanks, --Cigdem=20 =20 =20 Jim _______________________________________________ Ace mailing list Ace@ietf.org =20 https://www.ietf.org/mailman/listinfo/ace ------=_NextPart_000_014A_01D67479.25111670 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

 

 

From: Cigdem Sengul = <cigdem.sengul@gmail.com>
Sent: Monday, August 17, 2020 = 8:50 AM
To: Jim Schaad = <ietf@augustcellars.com>
Cc: = draft-ietf-ace-mqtt-tls-profile@ietf.org; Ace Wg = <ace@ietf.org>
Subject: Re: [Ace] Review of = draft-ietf-ace-mqtt-tls-profile-06

 

Hello Jim, 

Responses inside.

 

 <= /o:p>

 <= /o:p>

On Sat, Aug = 15, 2020 at 10:50 PM Jim Schaad <ietf@augustcellars.com> = wrote:

Section 2.2.3 - = /Clean Start to 0/Clean Start to 0, specify the previous
session = number/  - I think it should be stated that the session number = is
provided, which is what the state is associated = with.

 <= /o:p>

To the best = of my knowledge, and from what I read from the MQTT v5 = spec:

The ClientID MUST be used by Clients and by Servers to = identify state that they hold relating to this MQTT Session between the = Client and the Server. 

I do not = think the server uses anything other than the Client ID to look up the = state.  

[JLS] I got = the name wrong, the need for the identifier = remains.

[CS] I see - I realise I did a shortcut to say MQTT = broker keep session state. 

Actually, I think I should give examples of session = state as I need to explain what could be problematic by identifying = state only with client-id as discussed in the last IETF = meeting. 

(i.e., 

The= Session State in the Client consists of:

=C2=B7        = ; QoS= 1 and QoS 2 messages which have been sent to the Server, but have not = been completely acknowledged.

=C2=B7        = ; QoS= 2 messages which have been received from the Server, but have not been = completely acknowledged.

&nb= sp;

The= Session State in the Server consists of:

=C2=B7        = ; The= existence of a Session, even if the rest of the Session State is = empty.

=C2=B7        = ; The= Clients subscriptions, including any Subscription = Identifiers.

=C2=B7        = ; QoS= 1 and QoS 2 messages which have been sent to the Client, but have not = been completely acknowledged.

=C2=B7        = ; QoS= 1 and QoS 2 messages pending transmission to the Client and OPTIONALLY = QoS 0 messages pending transmission to the = Client.

=C2=B7        = ; QoS= 2 messages which have been received from the Client, but have not been = completely acknowledged.The Will Message and the Will Delay = Interval

=C2=B7        = ; If = the Session is currently not connected, the time at which the Session = will end and Session State will be discarded.

)

 

 <= /o:p>

Section 2.2.4 - = Last sentence.  There is a difference between the connect
and = re-auth flows in that the first and last messages are going to be = AUTH
'25', AUTH '0' not CONNECT/CONNACK.  Everything else does = stay the same. -
Might just want to say a similar flow and point = forward.

Will = clarify that this is only for CONNECT as it is under section = 2- Authorizing = Connection Requests. 

Will direct to section 4 for = re-authentication.

 <= /o:p>

Section = 2.2.6.1 - I am not sure where you got this from: "Note that this = is
different in MQTT v5.0, the Broker is allowed to process AUTH = packets even
if the Broker rejects the CONNECT)."  I think = that if the broker rejects the
connect it must CONNACK and = disconnect. 

 <= /o:p>

I've got = that from MQTT v5 spec:

If a Client sets an Authentication Method in the CONNECT, = the Client MUST NOT send any packets other than AUTH or DISCONNECT = packets until it has received a CONNACK packet&nb= sp;[MQTT= -3.1.2-30].

&nb= sp;and:

If the Server rejects the CONNECT, it MUST NOT process = any data sent by the Client after the CONNECT packet except AUTH = packets&nb= sp;[MQTT= -3.1.4-6]. 

 <= /o:p>

[JLS] I = read this as the following would not do the publish

CONNECT = =C3=A0

PUBLISH = =C3=A0

  =             &= nbsp; =C3=9F = AUTH

AUTH =C3=A0

  =             &= nbsp; =C3=9F CONNACK = fail

The PUBLISH = can be received but is not processed unless the CONNACK is going to be a = success.

[/JLS]<= /o:p>

 

[CS] I think this sequence should not happen, as = Client MUST NOT send PUBLISH before CONNACK.

I did not know what brokers do if they receive PUBLISH = (and still processing a CONNECT) - drop or buffer until process. I = quickly browsed mosquitto src. 

It looks like the broker sets a context flag to mark = the session active after CONNECT is processed and = accepted. 

If this = flag is not set when processing publish,  it goes to an error state = and doesn't look like it keeps the packet. 

 

[JLS] No, = Clients are allowed to send further MQTT Control Packets immediately = after sending a CONNECT packet; Clients need not wait for a CONNACK = packet to arrive from the Server. =E2=80=93 this is the preceding two = sentences to requirement MQTT-3.1.4-6.=C2=A0 I would agree that this is = going to be server specific.=C2=A0 The following paragraph suggests that = clients SHOULD wait for the CONNACK but it is non-normative. =C2=A0I = think that I would write my client code to wait.=C2=A0 I would have to = work really hard to figure out what my code base would do for this as I = know it does queue packets for later processing but I am not sure what = it would do for this case.

 

 <= /o:p>

So, the = spec allows clients to send AUTH after CONNECT before CONNACK, and = servers to process AUTH after CONNECT (before CONNACK I = suppose). 

 <= /o:p>

I agree the = wording may  be confusing:

What I want = to say is that: the servers in our profile do not process anything after = CONNECT before CONNACK. 

So, the = AUTH flow is strictly initiated by the server during the connection = handshake.

After that, = the client may do AUTH first, for = re-authentication. 

[JLS] Given = that a client may only send an AUTH in response to an AUTH, I = don=E2=80=99t know how much this is needed.

 <= /o:p>

[JLS]  = I think if you just delete the aside (in parens) then it says what needs = to be said and is not confusing.

 <= /o:p>

[CS] OK, agreed, less is more in this case. Will = delete the parentheses text.  

 <= /o:p>


Section = 3.1 - Missed a case of = "publish_+/topic3"

Yes, in = previous version, example was for publish only for = topic3.

I thought I = should give a pub/sub, pub only, and sub only = examples. 

Is that = OK?

 <= /o:p>

Yes, I was = just pointing out that this was using the old syntax.  Nothing = more.

 

[CS] Found it. OK, that was very buggy. Will change = to:

 Following the = example in the previous section,

   a client sending a SUBSCRIBE message to = 'a/topic3' would be allowed to
   subscribe, as the scope = includes  "["+/topic3",["sub&quo= t;]]".

 

Thanks again for catching = it.

--Cigdem 

 <= /o:p>

Jim

 <= /o:p>

 <= /o:p>

Thanks,=

--Cigdem&nbs= p;

 <= /o:p>

 <= /o:p>


Jim
<= br>
_______________________________________________
Ace mailing = list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace

= ------=_NextPart_000_014A_01D67479.25111670-- From nobody Mon Aug 17 10:45:39 2020 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 29A283A1250; Mon, 17 Aug 2020 10:45:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 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] 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 7AYVLlQ9IfT9; Mon, 17 Aug 2020 10:45:36 -0700 (PDT) Received: from mail-vs1-xe2c.google.com (mail-vs1-xe2c.google.com [IPv6:2607:f8b0:4864:20::e2c]) (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 163433A0D89; Mon, 17 Aug 2020 10:45:36 -0700 (PDT) Received: by mail-vs1-xe2c.google.com with SMTP id a1so8703687vsp.4; Mon, 17 Aug 2020 10:45:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=ECJaecc4UXzj/QS8fq5uiHDi6otzEsgIeIdhvo/sfRs=; b=e4OnjgKOhT+W75nKQ9gHQnL7iceFHp+C8mZ7rx0jSmmv7ukMt3yjloBwmTsogIHz+n amY8M1vnuNLasRW+gFvii0q4RGkTymSHdUcrLkwmJCFSZac9qT0/vI+j58dhcdce+U74 h6X1WvYJnMZrHkBclm/uHhaYRHE97r6K50u5f84ZhGd7iRgkBpRMcd1aKkqgQpcZOH7W 6Dm+sT/M+czIzcFZN80p/qNayJrKw6U6pABdbyrdvW60QrubeinuvFVrXiade9t+T84D e+8vzrmdD2CXj2UTq6wvPz5X2UQ9/7zEM7k/kcryZrnrmgoykQEh4LAWv/tfBD0LX30a cmnA== 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=ECJaecc4UXzj/QS8fq5uiHDi6otzEsgIeIdhvo/sfRs=; b=D4evVOhdkyPJjX1VrLSu24ew1ApAoIqUS/QuBmjOyjHNj5UDto72JYnpxEp77XyOPq for47RVM8C03xXlz3zH0ld+DHMV7fKy7RfTa5BaT92fXSiG+/IyA10TN7k3aPNw6Iyod nvFaj11ofYjOlgB5gMlkWpYLVzkZIRrmOpmkbSuZ6gAGgfCUDTIBSQ2KB6LgHhYv5w8P OaFIfOdoanxt9HtwWQIM3U2KNCwH3yIFWDb0DI5PFfv5btqInh2diDBjdnHs0vBqSrIJ eK4PwlFbc1y4KHlSXSFIZST1uzAswm0hmZGbis7WRj0OSgIeHWlY3CXdr1SItgidZHme VTIQ== X-Gm-Message-State: AOAM532mmo1qc0qlpkoZ/I7lPOovhDPIjGEkmc/HAkXZX8bwX4a3pmw3 OO0rowTjFsLXd1XjrUNRCLlA16gZj7OcM30Pr7HB35cesChx/w== X-Google-Smtp-Source: ABdhPJx2RpHmDtSEvJwoivE3Ekc09ObUAwvWm17NykAyTjLVTpbuTE88tZTV2gHAwWfNfeRS+BMylrJGgfGRwMwt1ZM= X-Received: by 2002:a05:6102:2012:: with SMTP id p18mr9515556vsr.62.1597686335081; Mon, 17 Aug 2020 10:45:35 -0700 (PDT) MIME-Version: 1.0 References: <00dd01d6734e$09020920$1b061b60$@augustcellars.com> <00f601d67409$4a3f04e0$debd0ea0$@augustcellars.com> <014901d674b3$d16e19b0$744a4d10$@augustcellars.com> In-Reply-To: <014901d674b3$d16e19b0$744a4d10$@augustcellars.com> From: Cigdem Sengul Date: Mon, 17 Aug 2020 18:45:24 +0100 Message-ID: To: Jim Schaad Cc: draft-ietf-ace-mqtt-tls-profile@ietf.org, Ace Wg Content-Type: multipart/alternative; boundary="00000000000077126105ad165677" Archived-At: Subject: Re: [Ace] Review of draft-ietf-ace-mqtt-tls-profile-06 X-BeenThere: ace@ietf.org 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, 17 Aug 2020 17:45:38 -0000 --00000000000077126105ad165677 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable > > > I've got that from MQTT v5 spec: > > If a Client sets an Authentication Method in the CONNECT, the Client MUST > NOT send any packets other than AUTH or DISCONNECT packets until it has > received a CONNACK packet [MQTT-3.1.2-30]. > > and: > > If the Server rejects the CONNECT, it MUST NOT process any data sent by > the Client after the CONNECT packet except AUTH packets [MQTT-3.1.4-6]. > > > > [JLS] I read this as the following would not do the publish > > CONNECT =C3=A0 > > PUBLISH =C3=A0 > > =C3=9F AUTH > > AUTH =C3=A0 > > =C3=9F CONNACK fail > > The PUBLISH can be received but is not processed unless the CONNACK is > going to be a success. > > [/JLS] > > > > [CS] I think this sequence should not happen, as Client MUST NOT send > PUBLISH before CONNACK. > > I did not know what brokers do if they receive PUBLISH (and still > processing a CONNECT) - drop or buffer until process. I quickly browsed > mosquitto src. > > It looks like the broker sets a context flag to mark the session active > after CONNECT is processed and accepted. > > If this flag is not set when processing publish, it goes to an error > state and doesn't look like it keeps the packet. > > > > [JLS] No, Clients are allowed to send further MQTT Control Packets > immediately after sending a CONNECT packet; Clients need not wait for a > CONNACK packet to arrive from the Server. =E2=80=93 this is the preceding= two > sentences to requirement MQTT-3.1.4-6. I would agree that this is going = to > be server specific. The following paragraph suggests that clients SHOULD > wait for the CONNACK but it is non-normative. I think that I would write > my client code to wait. I would have to work really hard to figure out > what my code base would do for this as I know it does queue packets for > later processing but I am not sure what it would do for this case. > > > [CS] Ok, this is confusing. I assumed that sentence regarding clients about not having to wait was when no Authentication Method set. Because there is: If a Client sets an Authentication Method in the CONNECT, the Client MUST NOT send any packets other than AUTH or DISCONNECT packets until it has received a CONNACK packet [MQTT-3.1.2-30]. In the profile, we do set an authentication method in connect to "ace". --Cigdem --00000000000077126105ad165677 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

<= div>

=C2=A0

I've got that from MQTT v5 spec:=

If a Client sets an Authentication Method in the CONNECT, the Client = MUST NOT send any packets other than AUTH or DISCONNECT packets until it ha= s received a CONNACK packet=C2=A0[MQTT-3.1.2-30].

=C2=A0and:<= u>

If the Se= rver rejects the CONNECT, it MUST NOT process any data sent by the Client a= fter the CONNECT packet except AUTH packets=C2=A0[MQTT-3.1.4-6].<= /span>=C2=A0

=C2=A0

[JLS] I read this as the following would not do th= e publish

CONNECT =C3=A0

= PUBLISH =C3=A0

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C3=9F AUTH

AUTH =C3=A0

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0 =C3=9F CONNACK fail

The PUBLISH can b= e received but is not processed unless the CONNACK is going to be a success= .

[/JLS]

=C2=A0=

[CS] I think this sequence sho= uld not happen, as Client MUST NOT send PUBLISH before CONNACK.

I did not know what brokers do if t= hey receive PUBLISH (and still processing a CONNECT) - drop or buffer until= process. I quickly browsed mosquitto src.=C2=A0

It looks like the broker sets a context flag to ma= rk the session active after CONNECT is processed and accepted.=C2=A0=

If this flag is not set when p= rocessing publish,=C2=A0 it goes to an error state and doesn't look lik= e it keeps the packet.=C2=A0

=C2=A0

[JLS] No, Clients are allowed to s= end further MQTT Control Packets immediately after sending a CONNECT packet= ; Clients need not wait for a CONNACK packet to arrive from the Server. =E2= =80=93 this is the preceding two sentences to requirement MQTT-3.1.4-6.=C2= =A0 I would agree that this is going to be server specific.=C2=A0 The follo= wing paragraph suggests that clients SHOULD wait for the CONNACK but it is = non-normative.=C2=A0 I think that I would write my client code to wait.=C2= =A0 I would have to work really hard to figure out what my code base would = do for this as I know it does queue packets for later processing but I am n= ot sure what it would do for this case.



= [CS] Ok, this is confusing.=C2=A0 I assumed that sentence regarding clients= about not having to wait was when no Authentication Method set.=C2=A0
Because there is:=C2=A0If a Client sets an Authen= tication Method in the CONNECT, the Client MUST NOT send any packets other = than AUTH or DISCONNECT packets until it has received a CONNACK packet=C2=A0[MQTT-3.1.2-30].
=C2=A0In the profi= le, we do set an authentication method in connect to "ace".=C2=A0=

--Cigdem=C2=A0=C2=A0
--00000000000077126105ad165677-- From nobody Mon Aug 17 11:16:49 2020 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 102E03A14E6; Mon, 17 Aug 2020 11:16:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham 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 K1q13VQ1wtdi; Mon, 17 Aug 2020 11:16:46 -0700 (PDT) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 529DC3A14E3; Mon, 17 Aug 2020 11:16:45 -0700 (PDT) Received: from Jude (73.180.8.170) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Mon, 17 Aug 2020 11:16:39 -0700 From: Jim Schaad To: 'Cigdem Sengul' CC: , 'Ace Wg' References: <00dd01d6734e$09020920$1b061b60$@augustcellars.com> <00f601d67409$4a3f04e0$debd0ea0$@augustcellars.com> <014901d674b3$d16e19b0$744a4d10$@augustcellars.com> In-Reply-To: Date: Mon, 17 Aug 2020 11:16:37 -0700 Message-ID: <015c01d674c2$8dd3be30$a97b3a90$@augustcellars.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_015D_01D67487.E1788FB0" X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQMqeFZNts+Ba8La03OrSbr3Xch6qAHBpxSwAaRV0WACqZVhnAIUe3k4Ad1+eg6mRIeHkA== Content-Language: en-us X-Originating-IP: [73.180.8.170] Archived-At: Subject: Re: [Ace] Review of draft-ietf-ace-mqtt-tls-profile-06 X-BeenThere: ace@ietf.org 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, 17 Aug 2020 18:16:48 -0000 ------=_NextPart_000_015D_01D67487.E1788FB0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable =20 =20 From: Cigdem Sengul =20 Sent: Monday, August 17, 2020 10:45 AM To: Jim Schaad Cc: draft-ietf-ace-mqtt-tls-profile@ietf.org; Ace Wg Subject: Re: [Ace] Review of draft-ietf-ace-mqtt-tls-profile-06 =20 =20 =20 I've got that from MQTT v5 spec: If a Client sets an Authentication Method in the CONNECT, the Client = MUST NOT send any packets other than AUTH or DISCONNECT packets until it = has received a CONNACK packet [MQTT-3.1.2-30]. and: If the Server rejects the CONNECT, it MUST NOT process any data sent by = the Client after the CONNECT packet except AUTH packets [MQTT-3.1.4-6].=20 =20 [JLS] I read this as the following would not do the publish CONNECT --> PUBLISH --> <-- AUTH AUTH --> <-- CONNACK fail The PUBLISH can be received but is not processed unless the CONNACK is = going to be a success. [/JLS] =20 [CS] I think this sequence should not happen, as Client MUST NOT send = PUBLISH before CONNACK. I did not know what brokers do if they receive PUBLISH (and still = processing a CONNECT) - drop or buffer until process. I quickly browsed = mosquitto src.=20 It looks like the broker sets a context flag to mark the session active = after CONNECT is processed and accepted.=20 If this flag is not set when processing publish, it goes to an error = state and doesn't look like it keeps the packet.=20 =20 [JLS] No, Clients are allowed to send further MQTT Control Packets = immediately after sending a CONNECT packet; Clients need not wait for a = CONNACK packet to arrive from the Server. =E2=80=93 this is the = preceding two sentences to requirement MQTT-3.1.4-6. I would agree that = this is going to be server specific. The following paragraph suggests = that clients SHOULD wait for the CONNACK but it is non-normative. I = think that I would write my client code to wait. I would have to work = really hard to figure out what my code base would do for this as I know = it does queue packets for later processing but I am not sure what it = would do for this case. =20 =20 [CS] Ok, this is confusing. I assumed that sentence regarding clients = about not having to wait was when no Authentication Method set.=20 Because there is: If a Client sets an Authentication Method in the = CONNECT, the Client MUST NOT send any packets other than AUTH or = DISCONNECT packets until it has received a CONNACK packet = [MQTT-3.1.2-30]. In the profile, we do set an authentication method in connect to "ace". = =20 [JLS] Looks like there might be some conflicting statements here. I = don=E2=80=99t know the best way to resolve it. Jim =20 =20 --Cigdem =20 ------=_NextPart_000_015D_01D67487.E1788FB0 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

 

 

From: Cigdem Sengul = <cigdem.sengul@gmail.com>
Sent: Monday, August 17, 2020 = 10:45 AM
To: Jim Schaad = <ietf@augustcellars.com>
Cc: = draft-ietf-ace-mqtt-tls-profile@ietf.org; Ace Wg = <ace@ietf.org>
Subject: Re: [Ace] Review of = draft-ietf-ace-mqtt-tls-profile-06

 

 

 <= /o:p>

I've got = that from MQTT v5 spec:

If a Client sets an Authentication Method in the CONNECT, = the Client MUST NOT send any packets other than AUTH or DISCONNECT = packets until it has received a CONNACK packet&nb= sp;[MQTT= -3.1.2-30].

&nb= sp;and:

If the Server rejects the CONNECT, it MUST NOT process = any data sent by the Client after the CONNECT packet except AUTH = packets&nb= sp;[MQTT= -3.1.4-6]. 

 <= /o:p>

[JLS] I = read this as the following would not do the publish

CONNECT = =C3=A0

PUBLISH = =C3=A0

  =             &= nbsp; =C3=9F = AUTH

AUTH =C3=A0

  =             &= nbsp; =C3=9F CONNACK = fail

The PUBLISH = can be received but is not processed unless the CONNACK is going to be a = success.

[/JLS]<= /o:p>

 <= /o:p>

[CS] I = think this sequence should not happen, as Client MUST NOT send PUBLISH = before CONNACK.

I did not = know what brokers do if they receive PUBLISH (and still processing a = CONNECT) - drop or buffer until process. I quickly browsed mosquitto = src. 

It looks = like the broker sets a context flag to mark the session active after = CONNECT is processed and accepted. 

If this = flag is not set when processing publish,  it goes to an error state = and doesn't look like it keeps the packet. 

 <= /o:p>

[JLS] No, = Clients are allowed to send further MQTT Control Packets immediately = after sending a CONNECT packet; Clients need not wait for a CONNACK = packet to arrive from the Server. =E2=80=93 this is the preceding two = sentences to requirement MQTT-3.1.4-6.  I would agree that this is = going to be server specific.  The following paragraph suggests that = clients SHOULD wait for the CONNACK but it is non-normative.  I = think that I would write my client code to wait.  I would have to = work really hard to figure out what my code base would do for this as I = know it does queue packets for later processing but I am not sure what = it would do for this case.

 <= /o:p>

 

[CS] Ok, this is confusing.  I assumed that = sentence regarding clients about not having to wait was when no = Authentication Method set. 

Because there is: If a Client sets an Authentication Method in the CONNECT, = the Client MUST NOT send any packets other than AUTH or DISCONNECT = packets until it has received a CONNACK packet&nb= sp;[MQTT= -3.1.2-30].

&nb= sp;In the profile, we do set an authentication method in connect to = "ace". 

 

[JLS] Looks like there might be some conflicting = statements here.=C2=A0 I don=E2=80=99t know the best way to resolve = it.

Jim

 

 

--Cigdem  

------=_NextPart_000_015D_01D67487.E1788FB0-- From nobody Mon Aug 17 14:25:20 2020 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A91803A11F2; Mon, 17 Aug 2020 14:25:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: 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=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 B737ScTgFhUn; Mon, 17 Aug 2020 14:25:17 -0700 (PDT) Received: from mail-vs1-xe2f.google.com (mail-vs1-xe2f.google.com [IPv6:2607:f8b0:4864:20::e2f]) (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 E441A3A11F1; Mon, 17 Aug 2020 14:25:16 -0700 (PDT) Received: by mail-vs1-xe2f.google.com with SMTP id k25so9025772vsm.11; Mon, 17 Aug 2020 14:25:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=+qi0860Q/e1Ncu3irLGMD5sBqNFEpFKYZQuzKvWeg6w=; b=CSaRamvb0E4dzeNacHyuVtEJ8E+sifIMW6M+jZrd0w9PuK9JNJyk7ozd240KMomQ2h bGzlVuyDCHu10mLs1Nt9MQIdHtzm3BkiP9b3K+1zAAugi93f8ptC1lA9COmBUSeFpLn3 pi7YBCNOo2L0xEJPMB8XAuy/5UOItKrEaCrwQHklkguwAkz7uCo7BxNurZnMWA4aeKMz v5GLsazk4FxedF+HSzIGxBOZy8E7QxwX63/HXsbFaDq2sq/a1zPESnSmU0NFBscvlqZy hRRzJCUpmsggDn53YZKva5ma8yTE1xRnXfa487K2B0lsdzF8dpwPcPa3w5fvfCXllDo+ PpMQ== 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=+qi0860Q/e1Ncu3irLGMD5sBqNFEpFKYZQuzKvWeg6w=; b=LMZo1I3e2MuggTRJzvAZ9fhIjEo41kvHA8D3AtmWKIwcIXEYDAwfA9ekMbhvN1yLmi Qo2OM0RdVanaq01bOM/hDf1JK+2H6ViiNQND7SHT2QT9yG0LlIP2+sPqzG0EwP7K8Iar stSl5E6hFcEiS05F+kKFQvdEWTS/PVBJjZ1vjLnpbuuBVuG/gq5exEMCgQGfPlWt5dQo JQ4Uo8bxH3no7rWvwl1zjA9oD/dE2pu52K6V96l3K7NoKBuzWe5L4S9cgL6GD9jP8dIX NuwpSMFz3XVYnHVtf3CORg4OZ9aLij8UxJ5YneE8V46lu7bjp6Gu63nkP8YEziEsiWsL OZog== X-Gm-Message-State: AOAM532/jMdF8aoU6DRP90DKnlYM39S23n67zOuKJe07eXLfxiUnorly htldWZU7vVIrKeORrfGgVkarYXlh8pEBKmByudF73pIy9YNlWg== X-Google-Smtp-Source: ABdhPJwP2udl9XvouQdSfLsirzRaor09b23cydQC4OFMInSH7dAweq9R4GLnJD0gq6qbLLzjVLyPDdQxGt+RRLEv/Eg= X-Received: by 2002:a67:e45:: with SMTP id 66mr9464334vso.191.1597699515804; Mon, 17 Aug 2020 14:25:15 -0700 (PDT) MIME-Version: 1.0 References: <00dd01d6734e$09020920$1b061b60$@augustcellars.com> <00f601d67409$4a3f04e0$debd0ea0$@augustcellars.com> <014901d674b3$d16e19b0$744a4d10$@augustcellars.com> <015c01d674c2$8dd3be30$a97b3a90$@augustcellars.com> In-Reply-To: <015c01d674c2$8dd3be30$a97b3a90$@augustcellars.com> From: Cigdem Sengul Date: Mon, 17 Aug 2020 22:25:04 +0100 Message-ID: To: Jim Schaad Cc: draft-ietf-ace-mqtt-tls-profile@ietf.org, Ace Wg Content-Type: multipart/alternative; boundary="00000000000018f06a05ad196866" Archived-At: Subject: Re: [Ace] Review of draft-ietf-ace-mqtt-tls-profile-06 X-BeenThere: ace@ietf.org 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, 17 Aug 2020 21:25:19 -0000 --00000000000018f06a05ad196866 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hello Jim, I understand that it's an optimization to improve message delay. I wonder also if a client then can do CONNECT - PUBLISH - DISCONNECT before receiving a CONNACK as a best-effort publish? assuming CONNECT succeeds... Should we just not cater to those cases? What about stating in 2.2.6.1 - after "the Broker MUST send a CONNACK message to the Client." (or maybe somewhere higher up): -> The client MUST NOT send any packets other than DISCONNECT or an AUTH in response to the broker AUTH's message until it has received a CONNACK. -> The server MUST NOT process any packets other than DISCONNECT or an AUTH in response to its AUTH message before it has sent a CONNACK. --Cigdem On Mon, Aug 17, 2020 at 7:16 PM Jim Schaad wrote: > > > > > *From:* Cigdem Sengul > *Sent:* Monday, August 17, 2020 10:45 AM > *To:* Jim Schaad > *Cc:* draft-ietf-ace-mqtt-tls-profile@ietf.org; Ace Wg > *Subject:* Re: [Ace] Review of draft-ietf-ace-mqtt-tls-profile-06 > > > > > > > > I've got that from MQTT v5 spec: > > If a Client sets an Authentication Method in the CONNECT, the Client MUST > NOT send any packets other than AUTH or DISCONNECT packets until it has > received a CONNACK packet [MQTT-3.1.2-30]. > > and: > > If the Server rejects the CONNECT, it MUST NOT process any data sent by > the Client after the CONNECT packet except AUTH packets [MQTT-3.1.4-6]. > > > > [JLS] I read this as the following would not do the publish > > CONNECT =C3=A0 > > PUBLISH =C3=A0 > > =C3=9F AUTH > > AUTH =C3=A0 > > =C3=9F CONNACK fail > > The PUBLISH can be received but is not processed unless the CONNACK is > going to be a success. > > [/JLS] > > > > [CS] I think this sequence should not happen, as Client MUST NOT send > PUBLISH before CONNACK. > > I did not know what brokers do if they receive PUBLISH (and still > processing a CONNECT) - drop or buffer until process. I quickly browsed > mosquitto src. > > It looks like the broker sets a context flag to mark the session active > after CONNECT is processed and accepted. > > If this flag is not set when processing publish, it goes to an error > state and doesn't look like it keeps the packet. > > > > [JLS] No, Clients are allowed to send further MQTT Control Packets > immediately after sending a CONNECT packet; Clients need not wait for a > CONNACK packet to arrive from the Server. =E2=80=93 this is the preceding= two > sentences to requirement MQTT-3.1.4-6. I would agree that this is going = to > be server specific. The following paragraph suggests that clients SHOULD > wait for the CONNACK but it is non-normative. I think that I would write > my client code to wait. I would have to work really hard to figure out > what my code base would do for this as I know it does queue packets for > later processing but I am not sure what it would do for this case. > > > > > > [CS] Ok, this is confusing. I assumed that sentence regarding clients > about not having to wait was when no Authentication Method set. > > Because there is: If a Client sets an Authentication Method in the > CONNECT, the Client MUST NOT send any packets other than AUTH or DISCONNE= CT > packets until it has received a CONNACK packet [MQTT-3.1.2-30]. > > In the profile, we do set an authentication method in connect to "ace". > > > > [JLS] Looks like there might be some conflicting statements here. I don= =E2=80=99t > know the best way to resolve it. > > Jim > > > > > > --Cigdem > --00000000000018f06a05ad196866 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello Jim,=C2=A0

I understand that it&#= 39;s an optimization to improve message delay. I wonder also if a client th= en can do CONNECT - PUBLISH - DISCONNECT before receiving a CONNACK as a be= st-effort publish? assuming CONNECT succeeds...
Should we just no= t cater to those cases?

What about stating in 2.2.6.= 1 - after "the Broker MUST
=C2=A0 =C2=A0send a CONNACK message to= the Client." (or maybe somewhere higher up):

->= The client MUST NOT send any packets other than DISCONNECT or an AUTH in r= esponse to the broker AUTH's message until it has received a CONNACK.
-> The server MUST NOT process any packets other than DISCONNEC= T or an AUTH in response to its AUTH message before it has sent a CONNACK.<= /div>

--Cigdem


<= br>

=C2=A0




On Mon, Aug 17, 2020 at 7:16 PM Jim Schaad <ietf@augustcellars.com> wrote:

=C2=A0

=C2=A0

From: Cigdem Sengul <cigdem.sengul@gmail.com>
Sent: Monday, Aug= ust 17, 2020 10:45 AM
To: Jim Schaad <ietf@augustcellars.com>
Cc= : draft-ietf-ace-mqtt-tls-profile@ietf.org; Ace Wg <ace@ietf.org>
Subje= ct: Re: [Ace] Review of draft-ietf-ace-mqtt-tls-profile-06

=C2=A0

=C2=A0

<= div>

=C2= =A0

I've got that fr= om MQTT v5 spec:

If a Client sets an Authentication Me= thod in the CONNECT, the Client MUST NOT send any packets other than AUTH o= r DISCONNECT packets until it has received a CONNACK packet=C2=A0[MQT= T-3.1.2-30].

=C2=A0and:

If the Server rejects the CONNECT, it MUST NOT proce= ss any data sent by the Client after the CONNECT packet except AUTH packets= =C2=A0[MQTT-3.1.4-6].=C2=A0

=C2=A0

[JLS] I read this = as the following would not do the publish

CONNECT =C3=A0

PUBLISH =C3=A0

=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C3=9F AUTH

AUTH =C3=A0

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C3=9F CONNACK fail

The PUBLISH can be received but is not processed unless the = CONNACK is going to be a success.

[= /JLS]

=C2=A0

[CS] I think this sequence should not happen, as Client MUST NOT send PUB= LISH before CONNACK.

I d= id not know what brokers do if they receive PUBLISH (and still processing a= CONNECT) - drop or buffer until process. I quickly browsed mosquitto src.= =C2=A0

It looks like the= broker sets a context flag to mark the session active after CONNECT is pro= cessed and accepted.=C2=A0

If this flag is not set when processing publish,=C2=A0 it goes to an err= or state and doesn't look like it keeps the packet.=C2=A0=

=C2=A0

[= JLS] No, Clients are allowed to send further MQTT Control Packets immediate= ly after sending a CONNECT packet; Clients need not wait for a CONNACK pack= et to arrive from the Server. =E2=80=93 this is the preceding two sentences= to requirement MQTT-3.1.4-6.=C2=A0 I would agree that this is going to be = server specific.=C2=A0 The following paragraph suggests that clients SHOULD= wait for the CONNACK but it is non-normative.=C2=A0 I think that I would w= rite my client code to wait.=C2=A0 I would have to work really hard to figu= re out what my code base would do for this as I know it does queue packets = for later processing but I am not sure what it would do for this case.

=C2=A0

=C2=A0=

[CS] Ok, this is confusing.=C2=A0 I a= ssumed that sentence regarding clients about not having to wait was when no= Authentication Method set.=C2=A0

Because there is:=C2=A0If a Client sets an Authent= ication Method in the CONNECT, the Client MUST NOT send any packets other t= han AUTH or DISCONNECT packets until it has received a CONNACK packet= =C2=A0[MQTT-3.1.2-30].

=C2=A0In the profile, we do set an authentication method in connec= t to "ace".=C2=A0

= =C2=A0

[JLS] Looks like there might be som= e conflicting statements here.=C2=A0 I don=E2=80=99t know the best way to r= esolve it.

Jim

=C2=A0

=C2=A0

--Cigdem=C2=A0= =C2=A0

--00000000000018f06a05ad196866-- From nobody Mon Aug 17 16:14:23 2020 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E9473A142D; Mon, 17 Aug 2020 16:14:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham 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 I2KbTUKiqxJw; Mon, 17 Aug 2020 16:14:19 -0700 (PDT) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0A5C23A142A; Mon, 17 Aug 2020 16:14:18 -0700 (PDT) Received: from Jude (73.180.8.170) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Mon, 17 Aug 2020 16:14:09 -0700 From: Jim Schaad To: 'Cigdem Sengul' CC: , 'Ace Wg' References: <00dd01d6734e$09020920$1b061b60$@augustcellars.com> <00f601d67409$4a3f04e0$debd0ea0$@augustcellars.com> <014901d674b3$d16e19b0$744a4d10$@augustcellars.com> <015c01d674c2$8dd3be30$a97b3a90$@augustcellars.com> In-Reply-To: Date: Mon, 17 Aug 2020 16:14:07 -0700 Message-ID: <017d01d674ec$1d3959d0$57ac0d70$@augustcellars.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_017E_01D674B1.70DCA4B0" X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQMqeFZNts+Ba8La03OrSbr3Xch6qAHBpxSwAaRV0WACqZVhnAIUe3k4Ad1+eg4B3yff1gLyNynuph5QA/A= Content-Language: en-us X-Originating-IP: [73.180.8.170] Archived-At: Subject: Re: [Ace] Review of draft-ietf-ace-mqtt-tls-profile-06 X-BeenThere: ace@ietf.org 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, 17 Aug 2020 23:14:22 -0000 ------=_NextPart_000_017E_01D674B1.70DCA4B0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable =20 =20 From: Cigdem Sengul =20 Sent: Monday, August 17, 2020 2:25 PM To: Jim Schaad Cc: draft-ietf-ace-mqtt-tls-profile@ietf.org; Ace Wg Subject: Re: [Ace] Review of draft-ietf-ace-mqtt-tls-profile-06 =20 Hello Jim,=20 =20 I understand that it's an optimization to improve message delay. I = wonder also if a client then can do CONNECT - PUBLISH - DISCONNECT = before receiving a CONNACK as a best-effort publish? assuming CONNECT = succeeds... Should we just not cater to those cases? =20 What about stating in 2.2.6.1 - after "the Broker MUST send a CONNACK message to the Client." (or maybe somewhere higher = up): =20 -> The client MUST NOT send any packets other than DISCONNECT or an AUTH = in response to the broker AUTH's message until it has received a = CONNACK. -> The server MUST NOT process any packets other than DISCONNECT or an = AUTH in response to its AUTH message before it has sent a CONNACK. =20 --Cigdem =20 =20 [JLS] I think that not catering to these cases is just fine. People who = really expect them to work probably shouldn=E2=80=99t. =20 Jim =20 =20 =20 =20 =20 =20 =20 On Mon, Aug 17, 2020 at 7:16 PM Jim Schaad > wrote: =20 =20 From: Cigdem Sengul >=20 Sent: Monday, August 17, 2020 10:45 AM To: Jim Schaad > Cc: draft-ietf-ace-mqtt-tls-profile@ietf.org = ; Ace Wg > Subject: Re: [Ace] Review of draft-ietf-ace-mqtt-tls-profile-06 =20 =20 =20 I've got that from MQTT v5 spec: If a Client sets an Authentication Method in the CONNECT, the Client = MUST NOT send any packets other than AUTH or DISCONNECT packets until it = has received a CONNACK packet [MQTT-3.1.2-30]. and: If the Server rejects the CONNECT, it MUST NOT process any data sent by = the Client after the CONNECT packet except AUTH packets [MQTT-3.1.4-6].=20 =20 [JLS] I read this as the following would not do the publish CONNECT --> PUBLISH --> <-- AUTH AUTH --> <-- CONNACK fail The PUBLISH can be received but is not processed unless the CONNACK is = going to be a success. [/JLS] =20 [CS] I think this sequence should not happen, as Client MUST NOT send = PUBLISH before CONNACK. I did not know what brokers do if they receive PUBLISH (and still = processing a CONNECT) - drop or buffer until process. I quickly browsed = mosquitto src.=20 It looks like the broker sets a context flag to mark the session active = after CONNECT is processed and accepted.=20 If this flag is not set when processing publish, it goes to an error = state and doesn't look like it keeps the packet.=20 =20 [JLS] No, Clients are allowed to send further MQTT Control Packets = immediately after sending a CONNECT packet; Clients need not wait for a = CONNACK packet to arrive from the Server. =E2=80=93 this is the = preceding two sentences to requirement MQTT-3.1.4-6. I would agree that = this is going to be server specific. The following paragraph suggests = that clients SHOULD wait for the CONNACK but it is non-normative. I = think that I would write my client code to wait. I would have to work = really hard to figure out what my code base would do for this as I know = it does queue packets for later processing but I am not sure what it = would do for this case. =20 =20 [CS] Ok, this is confusing. I assumed that sentence regarding clients = about not having to wait was when no Authentication Method set.=20 Because there is: If a Client sets an Authentication Method in the = CONNECT, the Client MUST NOT send any packets other than AUTH or = DISCONNECT packets until it has received a CONNACK packet = [MQTT-3.1.2-30]. In the profile, we do set an authentication method in connect to "ace". = =20 [JLS] Looks like there might be some conflicting statements here. I = don=E2=80=99t know the best way to resolve it. Jim =20 =20 --Cigdem =20 ------=_NextPart_000_017E_01D674B1.70DCA4B0 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

 

 

From: Cigdem Sengul = <cigdem.sengul@gmail.com>
Sent: Monday, August 17, 2020 = 2:25 PM
To: Jim Schaad = <ietf@augustcellars.com>
Cc: = draft-ietf-ace-mqtt-tls-profile@ietf.org; Ace Wg = <ace@ietf.org>
Subject: Re: [Ace] Review of = draft-ietf-ace-mqtt-tls-profile-06

 

Hello = Jim, 

 

I = understand that it's an optimization to improve message delay. I wonder = also if a client then can do CONNECT - PUBLISH - DISCONNECT before = receiving a CONNACK as a best-effort publish? assuming CONNECT = succeeds...

Should we just = not cater to those cases?

 

What about stating in 2.2.6.1 - after "the Broker = MUST

   send a = CONNACK message to the Client." (or maybe somewhere higher = up):

 

-> The client MUST NOT send any packets other than = DISCONNECT or an AUTH in response to the broker AUTH's message until it = has received a CONNACK.

-> The server MUST NOT process any packets other = than DISCONNECT or an AUTH in response to its AUTH message before it has = sent a CONNACK.

 

--Cigdem

 

 

[JLS] I think that not catering to these cases is just = fine.=C2=A0 People who really expect them to work probably = shouldn=E2=80=99t.

 

Jim

 

 

 

 

 

 

 

On = Mon, Aug 17, 2020 at 7:16 PM Jim Schaad <ietf@augustcellars.com> = wrote:

 <= /o:p>

 <= /o:p>

From:= Cigdem Sengul <cigdem.sengul@gmail.com>
Sent: = Monday, August 17, 2020 10:45 AM
To: Jim Schaad <ietf@augustcellars.com>
Cc: draft-ietf-ace-mqtt-tls-profile@ietf.org; Ace Wg = <ace@ietf.org>
Subject: Re: [Ace] = Review of draft-ietf-ace-mqtt-tls-profile-06

 <= /o:p>

 <= /o:p>

 <= /o:p>

I've got = that from MQTT v5 spec:

If a Client sets an Authentication Method in the CONNECT, = the Client MUST NOT send any packets other than AUTH or DISCONNECT = packets until it has received a CONNACK packet&nb= sp;[MQTT= -3.1.2-30].

&nb= sp;and:

If the Server rejects the CONNECT, it MUST NOT process = any data sent by the Client after the CONNECT packet except AUTH = packets&nb= sp;[MQTT= -3.1.4-6]. 

 <= /o:p>

[JLS] I = read this as the following would not do the publish

CONNECT = =C3=A0

PUBLISH = =C3=A0

  =             &= nbsp; =C3=9F = AUTH

AUTH =C3=A0

  =             &= nbsp; =C3=9F CONNACK = fail

The PUBLISH = can be received but is not processed unless the CONNACK is going to be a = success.

[/JLS]<= /o:p>

 <= /o:p>

[CS] I = think this sequence should not happen, as Client MUST NOT send PUBLISH = before CONNACK.

I did not = know what brokers do if they receive PUBLISH (and still processing a = CONNECT) - drop or buffer until process. I quickly browsed mosquitto = src. 

It looks = like the broker sets a context flag to mark the session active after = CONNECT is processed and accepted. 

If this = flag is not set when processing publish,  it goes to an error state = and doesn't look like it keeps the packet. 

 <= /o:p>

[JLS] No, = Clients are allowed to send further MQTT Control Packets immediately = after sending a CONNECT packet; Clients need not wait for a CONNACK = packet to arrive from the Server. =E2=80=93 this is the preceding two = sentences to requirement MQTT-3.1.4-6.  I would agree that this is = going to be server specific.  The following paragraph suggests that = clients SHOULD wait for the CONNACK but it is non-normative.  I = think that I would write my client code to wait.  I would have to = work really hard to figure out what my code base would do for this as I = know it does queue packets for later processing but I am not sure what = it would do for this case.

 <= /o:p>

 <= /o:p>

[CS] Ok, = this is confusing.  I assumed that sentence regarding clients about = not having to wait was when no Authentication Method = set. 

Because = there is: If a Client sets an Authentication Method in the CONNECT, = the Client MUST NOT send any packets other than AUTH or DISCONNECT = packets until it has received a CONNACK packet&nb= sp;[MQTT= -3.1.2-30].

&nb= sp;In the profile, we do set an authentication method in connect to = "ace". 

 <= /o:p>

[JLS] Looks = like there might be some conflicting statements here.  I = don=E2=80=99t know the best way to resolve it.

Jim

 <= /o:p>

 <= /o:p>

--Cigdem&nbs= p; 

<= /div> ------=_NextPart_000_017E_01D674B1.70DCA4B0-- From nobody Mon Aug 24 10:07:12 2020 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE0B63A114A; Mon, 24 Aug 2020 10:07:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.202 X-Spam-Level: X-Spam-Status: No, score=-0.202 tagged_above=-999 required=5 tests=[DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.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 ddrrtJ1zcaK0; Mon, 24 Aug 2020 10:07:03 -0700 (PDT) Received: from EUR05-VI1-obe.outbound.protection.outlook.com (mail-vi1eur05on2089.outbound.protection.outlook.com [40.107.21.89]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 596933A1181; Mon, 24 Aug 2020 10:07:02 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=RknEXXQC4/mOEDjP8t15SZFk1JNjWATC5dSMAH7QIBR94I/8WTxtWewpPA0zndY3mquQLqPw4RB/W7Aa7IGcCcCFykPvq+cXJEVltF9lVW11m5sbismiE/px8K4kedX4Ripy8MJXCwlgqGl/J3wc7CTim01tkma0qkUct1pEx1MuKAv/3f+PGXQyhKmzg3lWi1uK6fuA8Xhi6XEa82wDV1SR/t5jt4RNfjK3vejExyOtvcHzU4xTF+uyIcvRU+jUAE2NbsmHrgxbx0Lgb59L4WRxpctfISKXBbEODQDXpJa5UDnijvAJjhIAi95RX+2dF7do+e7czd1YGmXfZ3+r9w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=lyiPaa6m41EepKqsR0my4qQWveHA44F7lRPi0Os7Vy4=; b=l9hGkLfCk7vMz90dL/ZzFuROxxIMxh2Ad/yC7LQADUaGJQ7UeCu+tQL49SKX5Q/bVl64ncjB22Pdrt3UCS/j34lPrBwN00lleJIOCXOlCQuXMQ2FuZ0pEvcZ6wUO9rFPUo8CATKydw/RK5RiMDjsv31WbTvgDmgKbtgbj9hI0aXebai+BOXRNauew70IdDcqVLhn2CeZFxNxbhmne9DGocQoDcaH2vm5dkTOPiKHZSP6UFfqCxWzZ78z54+H73Fgsk1vJNC3CEkyImdX7Ik+qzrU1g734NBWGov9Qmtux11iMRGRTabcSezEeVi8BBncmhvr0NIPaTxMRvFoWyDzUw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=lyiPaa6m41EepKqsR0my4qQWveHA44F7lRPi0Os7Vy4=; b=rznMp26XvJnOyZ3mo/411Pt+ATGwg1y1/PmOf8zHW1hmpq5Vkv8buvynV9v2hs+zeOzdFTi5/SYtXIylID17xD4WGXw3f2AOIW63YitD6fDa3mhi2VXwLZw3JMzuM3x0aYLBd0LOCW3Fi9eaAIM6nAil9TGGS2XPrGzaikpW9kI= Received: from VI1PR07MB4477.eurprd07.prod.outlook.com (2603:10a6:803:74::33) by VI1PR07MB5536.eurprd07.prod.outlook.com (2603:10a6:803:b7::26) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3305.10; Mon, 24 Aug 2020 17:06:59 +0000 Received: from VI1PR07MB4477.eurprd07.prod.outlook.com ([fe80::cba:ac03:353c:2d1f]) by VI1PR07MB4477.eurprd07.prod.outlook.com ([fe80::cba:ac03:353c:2d1f%7]) with mapi id 15.20.3326.017; Mon, 24 Aug 2020 17:06:59 +0000 From: Francesca Palombini To: Elwyn Davies , "gen-art@ietf.org" CC: "draft-ietf-ace-oscore-profile.all@ietf.org" , "ace@ietf.org" , "last-call@ietf.org" Thread-Topic: Genart last call review of draft-ietf-ace-oscore-profile-11 Thread-Index: AQHWX7IkTd+c1UTuhkKyb48il2WBh6lH1BYA Date: Mon, 24 Aug 2020 17:06:59 +0000 Message-ID: References: <159537216772.11664.11256578694810978706@ietfa.amsl.com> In-Reply-To: <159537216772.11664.11256578694810978706@ietfa.amsl.com> Accept-Language: en-GB, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.40.20081000 authentication-results: dial.pipex.com; dkim=none (message not signed) header.d=none;dial.pipex.com; dmarc=none action=none header.from=ericsson.com; x-originating-ip: [158.174.219.143] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 621c1366-f8b1-4b70-05e0-08d848501d54 x-ms-traffictypediagnostic: VI1PR07MB5536: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: /R6BWlo6X92Yt6wMP3/7vODhYQVHB+6ZcNGCPsTjAOeRuu3GbwbF3FpQhtV+ki1Pke/KUSAOhQTPbwOpdP9+KC1vi2hIpGuUohLfqAFsvdtM4uSmzZri6zhGJy5AkbrrXLPXNVK9duIa46tkCPTJMA3y7FSUYElSz0zWXlaZKFg5OzYoRTseuFH3N7ckpyQjHTsmaHnOPzIrvGLTGbpZZiHrvJmPHwkIIsDYq/aSAVN+5y7/o7Qq7V53Zbv5BkP9F9Z3sNNvu2GMt5a1OrEwC9HoUi7zmDOeBl4IytrWo1QqD6luz1oGbdW2NdUAeBPK84MK+qRaSAxKCbs/AwBb8yU5LGLoa2UMeVoPtqMWajMi/JK3xMD/lH97ZtTgiWI5C5nJsNIbjmIDS3em4G5Qhw== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:VI1PR07MB4477.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(376002)(396003)(136003)(366004)(346002)(39860400002)(26005)(6506007)(2906002)(86362001)(66476007)(36756003)(8676002)(66556008)(83380400001)(4326008)(316002)(54906003)(53546011)(66946007)(66446008)(64756008)(71200400001)(2616005)(110136005)(44832011)(8936002)(76116006)(91956017)(5660300002)(33656002)(6512007)(186003)(966005)(6486002)(478600001); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: FpUV5lNLTGXdySXc4Q1efCx/XxMz3hVs9UdiFTrfK75zEpwyYkzrW+qqGTBIhOtL2H57syI0+3WsRCpwNCRvyoDE4jl7vhCX7pUZpN4IKJ3hkvw1rvf2xYNxOA7xkpl7HCpoN0tLMgzPpFpu7MomvizkibbMrdPwFcK4R3b+kFEiN7dZeIRcK79H8tm1dVAVbLnW67gZmkJgjtjIucg3L8+CAeQGERAzYHli+hIn10/ieRPSJaEGkdnSGeEwYFBeAtKP1uUElHUMqnm5YJZ5WzFjNPzYC/C+XOI3nj+8uhOp9P0pbeYm/AocKILIrGujK8Y+Fmmf9dTQV/Gxidoe4/kG3nGOu2v/QkPboFAVQ1e5a6vvBluNVB9Zw4pHnSivGbK7BE01MJOsTttS0e7Cn/nVuJpjJ6sDLZ4VrPf7SeAwiXyR0tQ92As0K9ZEiYMFxuJwlMLuF2ShTHRvhIVBgnkCczhviPSzfrYdS+Z2t0FyWgaN4B16VoDg8Z/D+3Qyr0rpn0UlwIvq2xFOyM/hMcS0LHdiqedLsa1DJhNW/L8NLWOGaLgWND49HRGyLriBq8TgQVKbsUmNDQbWXPBNiWnrXgHY0t4bjkPzjOkbnIaXQzD8jUZcHkeK1pZlmjE+6sGzPOlU0ShIVUs3NqQ3Dg== x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-ID: <06F81365A8058749BE39B48AF5768889@eurprd07.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: VI1PR07MB4477.eurprd07.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 621c1366-f8b1-4b70-05e0-08d848501d54 X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Aug 2020 17:06:59.8625 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: DDMbUwbldHoOS4yPWGu+F15HfzmJkNg+AvbMzjmI61KgFqC/ecKkF6ml79L//XvW7J+hwHKJxd021hz5vRKH6yt7LswBCAiBVcqTItoVMUPDvNcNl6jCDBpS3puDfRzU X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR07MB5536 Archived-At: Subject: Re: [Ace] Genart last call review of draft-ietf-ace-oscore-profile-11 X-BeenThere: ace@ietf.org 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, 24 Aug 2020 17:07:05 -0000 SGkgRWx3eW4sDQoNClRoYW5rIHlvdSBzbyBtdWNoIGZvciB5b3VyIHJldmlldy4gV2UgaGF2ZSBu b3cgd29ya2VkIG9uIGFsbCB5b3VyIGNvbW1lbnRzIGluIGEgcHVsbCByZXF1ZXN0LCBhbmQgd2ls bCBzb29uIHN1Ym1pdCBhbiB1cGRhdGUgdG8gdGhlIGRvY3VtZW50LiBBbGwgdGhlIG5pdHMgYXJl IGFkcmVzc2VkIGluIHR3byBjb21taXRzOiBodHRwczovL2dpdGh1Yi5jb20vYWNlLXdnL2FjZS1v c2NvcmUtcHJvZmlsZS9jb21taXQvYTdmOTQ4M2U5NjEwN2E2NzhiODAyMTdiYTBiMmQzZGNmYjQ4 ODE5MiAgYW5kIGh0dHBzOi8vZ2l0aHViLmNvbS9hY2Utd2cvYWNlLW9zY29yZS1wcm9maWxlL2Nv bW1pdC84NTVjMzQ4NjUxMjBhMWYwOWMyOGViZTZkY2U5M2FjZWRiMWYzZTA0IC4gRGV0YWlsZWQg Y29tbWVudHMgaW5saW5lLCBwcmVmYWNlZCB3aXRoIFtGUF0uDQoNClRoYW5rcyBhZ2FpbiBmb3Ig dGhlIGdvb2QgY29tbWVudHMsDQpGcmFuY2VzY2ENCg0KT24gMjIvMDcvMjAyMCwgMDA6NTYsICJF bHd5biBEYXZpZXMgdmlhIERhdGF0cmFja2VyIiA8bm9yZXBseUBpZXRmLm9yZz4gd3JvdGU6DQoN CiAgICBSZXZpZXdlcjogRWx3eW4gRGF2aWVzDQogICAgUmV2aWV3IHJlc3VsdDogQWxtb3N0IFJl YWR5DQoNCiAgICBJIGFtIHRoZSBhc3NpZ25lZCBHZW4tQVJUIHJldmlld2VyIGZvciB0aGlzIGRy YWZ0LiBUaGUgR2VuZXJhbCBBcmVhDQogICAgUmV2aWV3IFRlYW0gKEdlbi1BUlQpIHJldmlld3Mg YWxsIElFVEYgZG9jdW1lbnRzIGJlaW5nIHByb2Nlc3NlZA0KICAgIGJ5IHRoZSBJRVNHIGZvciB0 aGUgSUVURiBDaGFpci4gIFBsZWFzZSB0cmVhdCB0aGVzZSBjb21tZW50cyBqdXN0DQogICAgbGlr ZSBhbnkgb3RoZXIgbGFzdCBjYWxsIGNvbW1lbnRzLg0KDQogICAgRm9yIG1vcmUgaW5mb3JtYXRp b24sIHBsZWFzZSBzZWUgdGhlIEZBUSBhdA0KDQogICAgPGh0dHBzOi8vdHJhYy5pZXRmLm9yZy90 cmFjL2dlbi93aWtpL0dlbkFydGZhcT4uDQoNCiAgICBEb2N1bWVudDogZHJhZnQtaWV0Zi1hY2Ut b3Njb3JlLXByb2ZpbGUtMTENCiAgICBSZXZpZXdlcjogRWx3eW4gRGF2aWVzDQogICAgUmV2aWV3 IERhdGU6IDIwMjAtMDctMjENCiAgICBJRVRGIExDIEVuZCBEYXRlOiAyMDIwLTA3LTIwDQogICAg SUVTRyBUZWxlY2hhdCBkYXRlOiBOb3Qgc2NoZWR1bGVkIGZvciBhIHRlbGVjaGF0DQoNCiAgICBT dW1tYXJ5OiAgQWxtb3N0IHJlYWR5LiAgVGhlcmUgaXMgb25lIG1pbm9yIGlzc3VlIHRoYXQgbmVl ZHMgc29ydGluZyBvdXQgYW5kIGENCiAgICBmYWlyIG51bWJlciBvZiBuaXRzLiAgT3ZlcmFsbCBJ IGhhdmUgdG8gc2F5IHRoYXQgSSBmb3VuZCBpdCBkaWZmaWN1bHQgdG8ga2VlcA0KICAgIGNsZWFy IGluIG15IG1pbmQgd2hhdCBtZXNzYWdlcyB3ZXJlIGZ1bGx5IGVuY3J5cHRlZCBhbmQgd2hpY2gg b25lcyB3ZXJlIHNlbnQgZW4NCiAgICBjbGFpciBhbmQgd2hpY2ggYXJlIGluIHNvbWUgaW50ZXJt ZWRpYXRlIGNsYXNzLiAgVGhlIGF1dGhvcnMgbWlnaHQgd2lzaCB0byBnbw0KICAgIGJhY2sgb3Zl ciB0aGUgZG9jdW1lbnQgZnJvbSB0aGUgcG9pbnQgb2YgYSBuYWl2ZSByZWFkZXIgdG8gZW5zdXJl IHRoYXQgaXQgaXMNCiAgICBjbGVhciBmb3IgaW1wbGVtZW50ZXJzLg0KDQogICAgTWFqb3IgaXNz dWVzOg0KICAgIE5vbmUNCg0KICAgIE1pbm9yIGlzc3VlczoNCiAgICBzMiwgcGFyYSA1OiAgV2hl cmUgZG9lcyB0aGUgJ2lucHV0IHNhbHQnIGNvbWUgZnJvbT8gIFRoZSB0ZXJtIGlzIG5vdCB1c2Vk DQogICAgYW55d2hlcmUgZWxzZSBpbiB0aGlzIGRvY3VtZW50IGFuZCAgaXNuJ3QgZGVmaW5lZCBv ciBtZW50aW9uZWQgaW4gZWl0aGVyDQogICAgZHJlZnQtYWNlLW9hdXRoLWF1dGh6IG9yIFJGQyA4 NjEzLg0KDQpbRlBdOiBSaWdodCwgYXMgQmVuIG1lbnRpb25lZCwgdGhpcyB3YXMgdGhlIHJlc3Vs dCBvZiBhbiB1cGRhdGUgdG8gdGhlIG5hbWUgb2YgdGhlIHRlcm0uIFRoZSBpbnB1dCBzYWx0IGlz IHVzZWQgYXMgb25lIG9mIHRoZSBpbnB1dHMgdG8gdGhlIE9TQ09SRSBNYXN0ZXIgU2FsdC4gSSBo YXZlIG5vdyByZXBocmFzZWQgdG8gY2xhcmlmeSB0aGF0ICJzYWx0IiBjb250YWlucyBpbiBmYWN0 IGFuIGlucHV0IHRvIHRoZSBPU0NPUkUgTWFzdGVyIFNhbHQuIChodHRwczovL2dpdGh1Yi5jb20v YWNlLXdnL2FjZS1vc2NvcmUtcHJvZmlsZS9jb21taXQvMDdjZWQ2YTRmOTA4NDkxZDdkNzBjOGMy ZDZmY2E3NTk2ZTM4MDFkNCApDQoNCiAgICBOaXRzL2VkaXRvcmlhbCBjb21tZW50czoNCiAgICBz MTogIE5lZWQgdG8gZXhwYW5kIENvQVAgb24gZmlyc3QgdXNlLg0KDQpbRlBdOiBPay4gICAgDQoN CiAgICBzMTogTmVlZCB0byBleHBhbmQgQ0JPUiBvbiBmaXJzdCB1c2UuDQoNCltGUF06IEFjdHVh bGx5LCBiZWNhdXNlIENCT1IgYXBwZWFycyBvbiBmaXJzdCB1c2UgYXMgdGhlIGZpcnN0IHRlcm0g b2YgQ09TRSwgSSBoYXZlIG5vdCBleHBhbmRlZCBpdCBpbiB0aGlzIGxvY2F0aW9uLiBJIGhhdmUg YWRkZWQgYSBub3JtYXRpdmUgcmVmZXJlbmNlIHRvIENCT1IgaW4gdGhlIHRlcm1pbm9sb2d5IGFu ZCBleHBhbmRlZCBpdCB0aGVyZS4NCg0KICAgIHMxLjIsIENEREw6ICBJdCB3b3VsZCB1c2VmdWwg dG8gbWVudGlvbiB0aGF0IHRoZSBwcmVkZWZpbmVkIHR5cGUgbmFtZXMgZnJvbQ0KICAgIENEREws IGVzcGVjaWFsbHkgYnN0ciBmb3IgYnl0ZSBzdHJpbmdzIGFuZCB0c3RyIGZvciB0ZXh0IHN0cmlu Z3MsICBhcmUgdXNlZA0KICAgIGV4dGVuc2l2ZWx5IGluIHRoZSBkb2N1bWVudC4NCg0KW0ZQXTog VGhhbmtzIGZvciB0aGUgc3VnZ2VzdGlvbiwgbm93IGFkZGVkLg0KDQogICAgczIsIHBhcmEgMTog cy9vdmVydmlldyBvbiBob3cvb3ZlcnZpZXcgb2YgaG93Lw0KDQpbRlBdOiBPay4NCg0KICAgIHMy LCBwYXJhIDE6IHMvYXMgd2VsbCBhcyBPU0NPUkUgc2V0dXAvYXMgd2VsbCBhcyB0aGUgT1NDT1JF IHNldHVwLw0KDQpbRlBdOiBPay4NCg0KICAgIHMyLCBwYXJhIDI6IHMvdGhhdCdzL3RoYXQgaXMv DQoNCltGUF06IE9rLg0KDQogICAgczIsIHBhcmEgODogTmVlZCB0byBleHBhbmQgQUVBRCBvbiBm aXJzdCB1c2UuDQoNCltGUF06IE9rLg0KDQogICAgczIgYW5kIEZpZ3VyZSAxOiAgSXQgd291bGQg YmUgaGVscGZ1bCB0byB0aGUgcmVhZGVyIGlmIEZpZ3VyZSAxIGFuZCBpdHMNCiAgICBkZXNjcmlw dGl2ZSBwYXJhZ3JhcGggd2FzIHBsYWNlZCBjbG9zZXIgdG8gdGhlIGJlZ2lubmluZyBvZiBzMi4g IE90aGVyd2lzZQ0KICAgIHRoaW5ncyBsaWtlIENsaWVudCBDJyBuZWVkIG1vcmUgZXhwbGFuYXRp b24gdG8gcG9pbnQgdGhlIHJlYWRlciBhdCB0aGUgZmlndXJlLg0KDQpbRlBdOiBJIGhhdmUga2Vw dCBGaWd1cmUgMSBhdCB0aGUgZW5kIG9mIHRoZSBzZWN0aW9uLCBidXQgSSBoYXZlIG5vdyByZW1v dmVkIGFsbCBpbnN0YW5jZXMgb2YgIkNsaWVudCBDIiwgc2luY2UgdGhleSBkb24ndCBtYWtlIHNl bnNlIGJlZm9yZSBzZWVpbmcgdGhlIHBpY3R1cmUsIGFzIHlvdSByaWdodGx5IG5vdGVkLg0KDQog ICAgczIsIHBhcmEgMzoNCg0KICAgIFRoaXMgc2F5czoNCiAgICBUbyBkZXRlcm1pbmUgdGhlIEFT IGluIGNoYXJnZSBvZiBhIHJlc291cmNlIGhvc3RlZCBhdCB0aGUgUlMsIHRoZSBjbGllbnQgQyBN QVkNCiAgICBzZW5kIGFuIGluaXRpYWwgVW5hdXRob3JpemVkIFJlc291cmNlIFJlcXVlc3QgbWVz c2FnZSB0byB0aGUgUlMuIFRoZSBSUyB0aGVuDQogICAgZGVuaWVzIHRoZSByZXF1ZXN0IGFuZCBz ZW5kcyB0aGUgYWRkcmVzcyBvZiBpdHMgQVMgYmFjayB0byB0aGUgY2xpZW50IEMgYXMNCiAgICBz cGVjaWZpZWQgaW4gc2VjdGlvbiA1LjEgb2YgW0ktRC5pZXRmLWFjZS1vYXV0aC1hdXRoel0uIFRo ZSBhY2Nlc3MgdG9rZW4NCiAgICByZXF1ZXN0IGFuZCByZXNwb25zZSBNVVNUIGJlIGNvbmZpZGVu dGlhbGl0eS1wcm90ZWN0ZWQgYW5kIGVuc3VyZSBhdXRoZW50aWNpdHkNCg0KICAgIEkgZm91bmQg dGhlIGNvbWJpbmF0aW9uIG9mIHRoZSBVbmF1dGhvcml6ZWQgUmVxdXN0IGFuZCB0aGUNCiAgICBj b25maWRlbnRpYWxpdHktcHJvdGVjdGVkIGV0YyBjb25mdXNpbmcuICBJZiB0aGUgbGFzdCBzZW50 ZW5jZSBkb2VzIGFwcGx5IHRvDQogICAgdGhlIFVudXRob3JpemVkIFJlcXVlc3QgaXQgd291bGQg YmUgaGVscGZ1bCB0byBtYWtlIGl0IGNsZWFyIHRoYXQgdGhpcyBpcyBub3QNCiAgICBqdXN0IGEg Z2VuZXJpYyBzdGF0ZW1lbnQgYnV0IGRvZXMgYXBwbHkgdG8gdGhlIFVuYXV0aG9yaXplZCBSZXF1 ZXN0IGFzIHdlbGwuDQoNCltGUF06IE9rLCB0aGFuayB5b3UgZm9yIHBvaW50aW5nIGl0IG91dC4g SSBoYXZlIG5vdyBjbGFyaWZpZWQgaW4gdGhlIGJlZ2lubmluZyBvZiB0aGUgcGFyYWdyYXBoIHRo YXQgdGhlIGFjY2VzcyB0b2tlbiByZXF1ZXN0IGlzIGRpZmZlcmVudCBmcm9tIHRoZSBVbmF1dGhv cml6ZWQgUmVxdWVzdC4NCg0KICAgIEZpZ3VyZTE6ICBGb3IgY29uc2lzdGVuY3kgdGhlIGZpcnN0 IGxpbmUgc2hvdWxkIHNheSBVbmF1dGhvcml6ZWQgUnNvdXJjZQ0KICAgIFJlcXVlc3QuICBJIHdv dWxkIGFsc28gc3VnZ2VzdCBleHBsYWluaW5nIHRoZSBtYXBwaW5nIGJldHdlZW4gd2hhdCBpcyBz YWlkIGluDQogICAgdGhlIHRleHQgYW5kIHRoZSB0ZXJtcyAnQ2VhdGlvbiBIaW50cycgYW5kICdB Y2Nlc3MgSW5mb3JtYXRpb24nIHVzZWQgaW4gdGhlDQogICAgZmlndXJlLg0KDQpbRlBdOiBPayBh Ym91dCB0aGUgVW5hdXRob3JpemVkIFJlc291cmNlIFJlcXVlc3QuIEkgaGF2ZSBub3QgZXhwbGFp bmVkIGZ1cnRoZXIgYWJvdXQgdGhlIG1hcHBpbmcgYmV0d2VlbiB0aGUgb3ZlcnZpZXcgdGV4dCBh bmQgdGhlIGZpZ3VyZSwgYXMgSSBkbyBub3Qgd2FudCB0byBnbyBpbnRvIHRvbyBtdWNoIGRldGFp bCB0aGVyZSwgYnV0IEkgaGF2ZSBjbGFyaWZpZWQgdGhhdCB0aGUgbmFtZXMgb2YgbWVzc2FnZXMg Y29tZSBmcm9tIHRoZSBmcmFtZXdvcmsuDQoNCiAgICBzMy4xLCBwYXJhIGFmdGVyIEZpZ3VyZSAy OiAgVGhlIHRlcm0gJ2F1ZGllbmNlJyBhcHBlYXJzIGluIHRoaXMgcGFyYWdyYXBoDQogICAgd2l0 aG91dCBhbnkgY29udGV4dCBpbmRpY2F0aW5nIHdoYXQgaXQgbWVhbnMgLiAgTGF0ZXIgaW4gczMu MiBpdCBhcHBlYXJzIHRoYXQNCiAgICBhdWRpZW5jZSBpcyBhc3NvY2lhdGVkIHdpdGggQ0JPUiB3 ZWIgdG9rZW5zIChSRkMgODM5MikuICBCdXQgaXQgbWF5IGFsc28gbWlnaHQNCiAgICBhbHNvIGJl IHJlYWx0ZWQgdG8gZHJhZnQtb2F1dGgtdG9rZW4gZXhjaGFuZ2UuICBUaGUgYXBwcm9wcmlhdGUg cmVmZXJlbmNlDQogICAgYWhvdWxkIGJlIGFkZGVkIGFuZCBzaG91bGQgYmUgZXhwbGFpbmVkIGlu IHMzLjEuDQoNCltGUF06IE9rLCBhZGRlZCBhIHJlZmVyZW5jZSB0byB0aGUgcmlnaHQgc2VjdGlv biBpbiB0aGUgZnJhbWV3b3JrLg0KDQogICAgRmlndXJlIDM6ICBTaG91bGQgSWRDb250ZXh0IGJl IENvbnRleHRJZD8gIENvbnRleHRJZCBpcyB1c2VkIGV2cnl3aGVyZSBlbHNlLg0KDQpbRlBdOiBH b29kIGNhdGNoIQ0KDQogICAgczMuMjogRXhwYW5kIEhLREYgb24gZmlyc3QgdXNlICggaW4gc2Vj b25kIHNldCBvZiBidWxsZXRzKS4NCg0KW0ZQXTogT2suDQoNCiAgICBzMy4yLCBwYXJhIGFmdGVy IDJuZCBzZXQgb2YgYnVsbGV0czogIEkgdGhpbmsgdGhlIGZvdXIgaW5zdGFuY2VzIG9mICdtYXkn IA0KICAgIG91Z2h0IHRvIGJlICdNQVknLg0KDQpbRlBdOiBUaGVzZSBtYXkgd2VyZSBub3Qgbm9y bWF0aXZlIG9uIHB1cnBvc2UsIGFzIHRoZSBub3JtYXRpdmUgTUFZIGlzIHRoZSBvbmUgYWJvdmUg dGhlIGJ1bGxldCBsaXN0LiBJIGhhdmUgbm93IHJlcGhyYXNlZCB0byByZW1vdmUgIm1heSIgZnJv bSB0aGlzIHBhcmFncmFwaCwgdG8gYXZvaWQgY29uZnVzaW9uLg0KDQogICAgczMuMi4xOiAgSXQg d291bGQgYmUgaGVscGZ1bCB0byBwcm92aWRlIHJlZmVyZW5jZXMgdG8gdGhlIG9ubGluZSB2ZXJz aW9ucyBvZg0KICAgIHRoZSAgSUFOQSByZWdpc3RyaWVzICgzIHBsYWNlcykuDQoNCltGUF06IE9r Lg0KDQogICAgczQuMiwgcGFyYSAxOiAgIEEgZm93YXJkIHJlZmVyZW5jZSB0byBzNSB3aGVyZSB0 aGUgY29tdW5pY2F0aW9uIG1lY2hhbmlzbXMNCiAgICBuZWVkZWQgZm9yIGludHJvc3BlY3Rpb24g YXJlIGRlc2NyaWJlZC4NCg0KW0ZQXTogSSBhZGRlZCBhIHJlZmVyZW5jZSB0byB0aGUgc2VjdGlv biBvZiB0aGUgZnJhbWV3b3JrIHdoZXJlIGludHJvc3BlY3Rpb24gaXMgZGVzY3JpYmVkLg0KDQog ICAgczQuMSwgcGFyYSAyOiBzL2Zyb20gd2hhdCBkZXNjcmliZWQvZnJvbSB3aGF0IGlzIGRlc2Ny aWJlZC8NCg0KW0ZQXTogT2suDQoNCiAgICBzNC4yLCBwYXJhIDU6IHMvdGhhdCdzL3RoYXQgaXMv DQoNCltGUF06IE9rLg0KDQogICAgczQuMiwgbGFzdCBwYXJhOyBzL1RoaXMgc2ltcGxpZmllcyBm b3IgdGhlIFJTIHRyYWNrL1RoaXMgc2ltcGxpZXMgdGhlIHByb2Nlc3MNCiAgICBuZWVkZWQgYnkg dGhlIFJTIHRvIGtlZXAgdHJhY2svDQoNCltGUF06IE9rDQoNCiAgICBzOCwgcGFyYSA2OiBzL3Rh c2tlZCBvZi90YXNrZWQgd2l0aC8NCg0KW0ZQXTogT2sNCg0KICAgIHM5LjM6ICBJIGRvbid0IHRo aW5rIHRoZSBWYWx1ZSBUeXBlIGZvciBub25jZSBpcyAnSUVTRychIGxvbA0KDQpbRlBdOiBJbmRl ZWQhIFRoYW5rcy4NCg0KDQoNCg0K From nobody Mon Aug 24 10:07:21 2020 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 85DE13A11AA; Mon, 24 Aug 2020 10:07:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.202 X-Spam-Level: X-Spam-Status: No, score=-0.202 tagged_above=-999 required=5 tests=[DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.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 k6GMMLqI3Nq9; Mon, 24 Aug 2020 10:07:09 -0700 (PDT) Received: from EUR04-DB3-obe.outbound.protection.outlook.com (mail-eopbgr60067.outbound.protection.outlook.com [40.107.6.67]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 054F53A119B; Mon, 24 Aug 2020 10:07:07 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=TWgYkly8q5Ixizoh+ldrqBn41Dz1o+CBLpfAQIPt7aUe6ne3gzBMy1QVKmBcsSPb4iztnO6Q4/l5o/WqtWdst0tLGt+OEVdBr42F5o6tTlY/ubr+sZGQEptItks2aaZX4SOUZ68bHlBJaQ7HsSC/GEHUzJS2Mn6tTnUOhNty48n+Gek5rBXC7YiqPwJdzh48kUhyvwErreJ2vp/z9OG0MU02F/uE4gKC/JEHwHZp7KRKJH2m7ADBL1ZoziaD2kA/AMAC2mATebcVnEAfuLr8AdlVrSYlXqaoHFGJsD+qI135Xgy34USHd/0FC9KR5bgFmN1oxOwtjBQLuGY5/LIzkw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=YBpVK5tZEWWSgPxn2y9jVBWMVgQpT5xl9XesLQyGbII=; b=lVJsrBSoUXu+ffooFL9Xut6XSicOLr1s0ebb/VIHuT7rGxZ97gKF77M6vFICZ5IKbigVAFRbomO3VTDL88BBgXunwWTyZoSumc/DV+RfhqIRO3pySX4/Pq/P92QY9ku/4BR0/GQwfBB56RPOu4jnKwehNXkO8Hc0Abtm82o8qSLzNiw5cs4hfyh7M+Q2UI3OcVVtBnhceU2GdEZyofQeobRL3zth2X7DlnYF/5kePkUnzlbwHi4y/mYAp2HqfTZpXbEaR7y4oDKzoabhpeAbL9KSnbY95hUvdAJFSlgTNm9/cs0tsKuzmccb0IT+rRwRcdgxt7xu0/CeNiS9IwLwvQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=YBpVK5tZEWWSgPxn2y9jVBWMVgQpT5xl9XesLQyGbII=; b=itMTyVOHP1aksJ9gJKT2+RfQYHJQ2hsB7YAQtXtUc259wpnI/KyczcckaWGJrZaE3op2G1mTNplk3ya+518vV3MLF1xze5OJgBeD9X1kpqTuHZ9bQdDNUG6aZrp8B3Sle4RlShj6VjqnyguG111VQKi0zu4InO1oAafX9W2sbew= Received: from VI1PR07MB4477.eurprd07.prod.outlook.com (2603:10a6:803:74::33) by VI1PR07MB5536.eurprd07.prod.outlook.com (2603:10a6:803:b7::26) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3305.10; Mon, 24 Aug 2020 17:07:05 +0000 Received: from VI1PR07MB4477.eurprd07.prod.outlook.com ([fe80::cba:ac03:353c:2d1f]) by VI1PR07MB4477.eurprd07.prod.outlook.com ([fe80::cba:ac03:353c:2d1f%7]) with mapi id 15.20.3326.017; Mon, 24 Aug 2020 17:07:05 +0000 From: Francesca Palombini To: Benjamin Kaduk , Linda Dunbar CC: "ops-dir@ietf.org" , "draft-ietf-ace-oscore-profile.all@ietf.org" , "ace@ietf.org" , "last-call@ietf.org" Thread-Topic: Opsdir last call review of draft-ietf-ace-oscore-profile-11 Thread-Index: AQHWXkQm/2Ux8jIucECi5F3tZLHA3KkbxRsAgCwR3gA= Date: Mon, 24 Aug 2020 17:07:05 +0000 Message-ID: <5C8BDAEF-C8CF-433A-A093-2A9ACCD022EB@ericsson.com> References: <159521497745.9074.17834135527258230957@ietfa.amsl.com> <20200727180742.GG41010@kduck.mit.edu> In-Reply-To: <20200727180742.GG41010@kduck.mit.edu> Accept-Language: en-GB, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.40.20081000 authentication-results: mit.edu; dkim=none (message not signed) header.d=none;mit.edu; dmarc=none action=none header.from=ericsson.com; x-originating-ip: [158.174.219.143] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: d3256983-8e40-4dc4-e72e-08d8485020ae x-ms-traffictypediagnostic: VI1PR07MB5536: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: iAmdm+cbiFYk8l8b71R9vqALR9YWXEd/627wWZyW+oNQsh4tlTSfs05dkohIALtZPOoCmyPQJupNFTqXtiWJzE1Zj6/S0dj//E/zaqaJEcvWe1JmFJ+E3LDfwt5kFw82LJiiDqDn//9jDLosULturVuFN3rOGJNsaX6kYM4k0p1V1uvYl11pZepi2EYQFUZQdarLwvHKztHBejcg6lLFtAlYqcK7RnlNf9vWdmAmenXrW/gnJQYYgWf3TCEIT5JN4YYg4sRhWVKcjzQ7tbPqTyduP7QZDBIapo4j6Mwl+uW5D9GPU6j+X4kzOs2PELqCUET8sQNkJM2IwM8yi8aooH8atpZKsvbNrTTTMOMptz1Dz2qvFfTQW5N+eu+0xnHew+Tv7n2UEr7ESeiTduP9Xg== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:VI1PR07MB4477.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(376002)(396003)(136003)(366004)(346002)(39860400002)(26005)(6506007)(2906002)(86362001)(66476007)(36756003)(8676002)(66556008)(83380400001)(4326008)(316002)(54906003)(66946007)(66446008)(64756008)(71200400001)(2616005)(110136005)(44832011)(8936002)(76116006)(91956017)(5660300002)(33656002)(6512007)(186003)(966005)(6486002)(478600001); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: R8oWa+qs4GPKgbSD/3sJJIU8+i6jNfxMNoUGYuXPTG1TDGzavCfJMu0DN2rHJMSyB0Ac8Z4RWOFGApSZShOLDvXV+JS1rtUlGGV2LPUJhx8h/vx/llhgqeNMr5LCx32zqfNbFNo/omXm3qyIkqjA1hAWfvdhXmctWJvPusQZl9o1BYw2PLewoOo5UkLMauo4TFvfPVRw+fT3R1k7w+4yYYp9HFVmEqYUQna2Qu3ucoYKj3eR5xeVT7npuhn2yUEb22q6PQQYCrDLRcJgPltt225pRqHXe6Gb3KvM/mNRLu4tWLNaZjIJVO4L9voTMhzljwqMK/16uvyBtAi/DAKOOlgx+IEhPwR6OcEekyB8ok67MFBYKSyZc4n6+i/L1GrbmM8mLdxDL0bS893bkuELseZFq8Z/kWtlpEXDou6BQ29nJFMVkzlFJFS+LNL5RxaVb0hsYf6RHh9L5sVk3eVuk7IfHsgulwIT44penAKP9vta8TJ0NIRDWnrcsgaRu7VuUzxQpEbqIsjRotuz+VdRRxy0/vmNenAsbU3A8QJhOkjTNy3e1IYYCoP+++BVMoI2QdSQV+Arkx1Qj+M4xhuthLtD6OMSCn2PnyQDOSv3gpVkt+VvJpQy1IWVaEHBpN8ItL0TyoJlfKVH/fYG7+0bDQ== x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-ID: <378BF2A7B7C05441B0A9EEBCEB466497@eurprd07.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: VI1PR07MB4477.eurprd07.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: d3256983-8e40-4dc4-e72e-08d8485020ae X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Aug 2020 17:07:05.4223 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: ZcUpPfjvth/PlBe2cxZJBY0c4+nl/PekJoFWTwFq0xiH0Qeg8xslDg/3OjBQh2m+n9xGEWIBJkpQR4+SKFZrgPRfyj3hgf0jty6QHjhavBFGJQGGh0XeTuUUqvnnRQrS X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR07MB5536 Archived-At: Subject: Re: [Ace] Opsdir last call review of draft-ietf-ace-oscore-profile-11 X-BeenThere: ace@ietf.org 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, 24 Aug 2020 17:07:16 -0000 SGkgTGluZGEsDQoNClRoYW5rIHlvdSBmb3IgeW91ciByZXZpZXcuIEJlbiBoYXMgYWxyZWFkeSBj bGFyaWZpZWQgb3VyIGFpbSBmb3IgbW9zdCBvZiB5b3VyIHBvaW50cywgdGhhbmtzIEJlbi4gSSBq dXN0IHdhbnQgdG8gYWRkIHRoYXQgd2UgaGF2ZSBub3cgYWRkZWQgc29tZSB0ZXh0IHRvIGNsYXJp ZnkgdGhlIENCT1IgZm9ybWF0dGluZyBvZiBGaWd1cmUgNywgeW91IGNhbiBzZWUgdGhlIGRpZmYg aGVyZTogaHR0cHM6Ly9naXRodWIuY29tL2FjZS13Zy9hY2Utb3Njb3JlLXByb2ZpbGUvY29tbWl0 LzU1ZDUwMGE4OTIyYjU2OTRkZDgyMWQ0YjExMDljYzE2MjMxM2ZjMmYgVGhpcyB3aWxsIGJlIGlu Y2x1ZGVkIGluIHRoZSBuZXh0IHVwZGF0ZSBvZiB0aGUgZG9jdW1lbnQuDQoNClRoYW5rcywNCkZy YW5jZXNjYQ0KDQrvu79PbiAyNy8wNy8yMDIwLCAyMDowOCwgIkJlbmphbWluIEthZHVrIiA8a2Fk dWtAbWl0LmVkdT4gd3JvdGU6DQoNCiAgICBIaSBMaW5kYSwNCg0KICAgIE9uIFN1biwgSnVsIDE5 LCAyMDIwIGF0IDA4OjE2OjE3UE0gLTA3MDAsIExpbmRhIER1bmJhciB2aWEgRGF0YXRyYWNrZXIg d3JvdGU6DQogICAgPiBSZXZpZXdlcjogTGluZGEgRHVuYmFyDQogICAgPiBSZXZpZXcgcmVzdWx0 OiBIYXMgTml0cw0KICAgID4gDQogICAgPiBJIGhhdmUgcmV2aWV3ZWQgdGhpcyBkb2N1bWVudCBh cyBwYXJ0IG9mIHRoZSBPcHMgYXJlYSBkaXJlY3RvcmF0ZSdzIG9uZ29pbmcNCiAgICA+IGVmZm9y dCB0byByZXZpZXcgYWxsIElFVEYgZG9jdW1lbnRzIGJlaW5nIHByb2Nlc3NlZCBieSB0aGUgSUVT Ry4gIFRoZXNlDQogICAgPiBjb21tZW50cyB3ZXJlIHdyaXR0ZW4gcHJpbWFyaWx5IGZvciB0aGUg YmVuZWZpdCBvZiB0aGUgT3BzIGFyZWEgZGlyZWN0b3JzLg0KICAgID4gRG9jdW1lbnQgZWRpdG9y cyBhbmQgV0cgY2hhaXJzIHNob3VsZCB0cmVhdCB0aGVzZSBjb21tZW50cyBqdXN0IGxpa2UgYW55 IG90aGVyDQogICAgPiBsYXN0IGNhbGwgY29tbWVudHMuDQogICAgPiANCiAgICA+IFRoaXMgZG9j dW1lbnQgZGVzY3JpYmVzIGhvdyB0byBzZXQgc3BlY2lmaWMgcGFyYW1ldGVycyBpbiB1c2luZyAg dGhlDQogICAgPiBBdXRoZW50aWNhdGlvbiBhbmQgQXV0aG9yaXphdGlvbiBmb3IgQ29uc3RyYWlu ZWQgRW52aXJvbm1lbnRzIChBQ0UpIGZyYW1ld29yaw0KICAgID4gW0ktRC5pZXRmLWFjZS1vYXV0 aC1hdXRoel0uIFRoZSBkb2N1bWVudCBpcyB3cml0dGVuIGNsZWFyLCBleGNlcHQgc29tZSBtaW5v cg0KICAgID4gaXNzdWVzOg0KICAgID4gDQogICAgPiAgU2VjdGlvbiA0LjEuMSBzdGF0ZXMgdGhh dCBOb25jZSBQYXJhbWV0ZXIgbXVzdCBiZSBzZW50IGZyb20gdGhlIGNsaWVudCB0byBSUy4NCiAg ICA+ICBXaGF0IHdvdWxkIGJlIHRoZSBwcm9ibGVtIGlmIHRoZSBjbGllbnQgZG9lc24ndCBpbmNs dWRlIHRoZSAiTk9OQ0UiPw0KDQogICAgVGhlcmUncyBhIGxpdHRsZSBtb3JlIGRpc2N1c3Npb24g b2YgdGhlIE4xIGluIHRoZSBwcmV2aW91cyBzZWN0aW9uLCBidXQgaW4NCiAgICBlc3NlbmNlLCB0 aGlzIG5vbmNlIGlzIHJlcXVpcmVkIHRvIHByb3RlY3QgdGhlIGNsaWVudCBhZ2FpbnN0IHJlcGxh eWVkDQogICAgcmVzcG9uc2VzLiAgU2luY2UgdGhlIHRva2VuIGNvbnRlbnRzIChpbmNsdWRpbmcg a2V5IGRlcml2YXRpb24gbWF0ZXJpYWwpDQogICAgd291bGQgYmUgdW5jaGFuZ2VkIGFjcm9zcyBz ZWN1cml0eSBjb250ZXh0cywgdGhlIG5vbmNlIGlzIHVzZWQgdG8gbWFrZSBlYWNoDQogICAgb25l IGRpZmZlcmVudDsgaXQgaGFzIHRvIGJlIGNsaWVudC1nZW5lcmF0ZWQgc28gdGhhdCB0aGUgY2xp ZW50IGlzIHN1cmUNCiAgICB0aGF0IHRoaXMgc2VjdXJpdHkgY29udGV4dCBpcyAiZnJlc2giICh2 cy4gcmVwbGF5ZWQpLg0KDQogICAgPiBQYWdlIDEyOiBJdCBhc2tzIFJGQyBlZGl0b3IgdG8gdmFs aWRhdGUgdGhlIG51bWJlcnMgbGlzdGVkIGluIEZpZ3VyZSA3LiAgVGhlcmUNCiAgICA+IGlzIG5v IGV4cGxhbmF0aW9uIG9yIGNvbW1lbnRzIGZvciB0aG9zZSB2YWx1ZXMuIEl0IHdpbGwgYmUgdmVy eSBkaWZmaWN1bHQgZm9yDQogICAgPiBSRkMgZWRpdG9yIHRvIHZhbGlkYXRlLiBJdCBzZWVtcyB0 byBtZSB0aGVyZSBhcmUgNCBjb2x1bW5zIGJ1dCAgSSBjYW4ndA0KICAgID4gdW5kZXJzdGFuZCB0 aGUgbWVhbmluZyBvZiB0aGUgdmFsdWVzIHVuZGVyIDFzdCwgMm5kLCBhbmQgM3JkIGNvbHVtbnMu DQoNCiAgICBJIHRoaW5rIHRoaXMgaXMganVzdCBhIG5vdGUgdGhhdCB0aGUgUkZDIEVkaXRvciBz aG91bGQgbWFrZSBzdXJlIHRoYXQNCiAgICBzb21lb25lIGhhcyBjaGVja2VkIHRoZSB2YWx1ZXMg KGkuZS4sIHRoZSBhdXRob3JzKS4gIFRoZSBSRkMgRWRpdG9yIGRvZXMNCiAgICBub3QgbmVlZCB0 byBiZSB0aGUgb25lIGFjdHVhbGx5IGRvaW5nIHRoZSBjaGVja2luZy4NCg0KICAgIFRoYW5rcyBm b3IgdGhlIHJldmlldywNCg0KICAgIEJlbg0KDQogICAgPiBpdCBpcyBraW5kIG9mIGRpZmZpY3Vs dCB0byB2YWxpZGF0ZSB0aGUgY29ycmVjdG5lc3MgYnkganVzdCByZWFkaW5nIHRocm91Z2ggdGhl DQogICAgPiBkb2N1bWVudC4gIEl0IHdvdWxkIGJlIGJldHRlciB0byBoYXZlIGFuIGltcGxlbWVu dGF0aW9uIHJlcG9ydCBvZiB0aGUgcHJvcG9zZWQNCiAgICA+ICJQcm9maWxlIi4NCiAgICA+IA0K ICAgID4gQmVzdCBSZWdhcmRzLA0KICAgID4gIExpbmRhIER1bmJhcg0KICAgID4gDQogICAgPiAN CiAgICA+IA0KDQo= From nobody Mon Aug 24 10:07:31 2020 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0CE3F3A120C; Mon, 24 Aug 2020 10:07:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.202 X-Spam-Level: X-Spam-Status: No, score=-0.202 tagged_above=-999 required=5 tests=[DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.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 gKqr_F1e5e8c; Mon, 24 Aug 2020 10:07:23 -0700 (PDT) Received: from EUR05-VI1-obe.outbound.protection.outlook.com (mail-vi1eur05on2086.outbound.protection.outlook.com [40.107.21.86]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 36D083A11E6; Mon, 24 Aug 2020 10:07:21 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Xcq/qy8iL/dKztY//zehMftkzHG3y5ySIRxcNQvYxvzPAW5DSWdaSjbknbO6hbnjsoZNbkRuWGgucNRADoEtcgb7zBJiUW/hxcKoy/XUcG5zW9wBhMTKrxkAQWCl8CPeJhzjRzqHQDpsNCcQrd+dL8cOCdNQgIMwJB+8ReNfOyoNe8Xk/BXx9dYCXPqzoB81J3yYBwkm4KA5CIAxUYF/rs2ZsbtDwQMss1cMOumtt0b26zK/B8Y1DVv+Rtk1qOeeWY4D0aopAB2jty22pM/F67U/Qy9gNhw+gzzZgQGCY8Xg5gzHuG0M2G17N1A/zxttoOcOl4r56izsY2CJeOwZMQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=oGqn9zjxpYNbsV2UDFIpzAzt/pD3aOdwYOZFgn4nbWw=; b=Cl0hqRKXS/7YWqQOmmp7yXbpcZ2MDzTjejRqGdTmmpGysU91VNOShPRnaWdVAbnYB8qYWmUQMW378cixMn5x2E0aUZIGQlGw8eMRafadU0p4W8WmZAyZKRwRmYRRW4b5oDwrfbXwo6n+W5x62F1s2Aty+zyp6oLLflSlbxShMbZORSRn9xii7kNiLXKMQlXy6bSyXjyu5EtdhYFqhbNcIjMyb7UZAdXPoSIIQCgJzx6NHx8MtcjXICJYq2ajHL0VWLPzl41Hgd6z9KKisKFiwzwWcKWuiAcOMmxO5+OzuT+jXn+VOZK7qePWmYEwiJ1olfRYPOgu4sgRY8odwPqy6A== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=oGqn9zjxpYNbsV2UDFIpzAzt/pD3aOdwYOZFgn4nbWw=; b=t3ySd5dF9WM3hfCbrOl3Rx9R8J29vRwfwoJ4YtWR5rEd0wQEINl1czrrLaNKRkHAUBfkUGueb8k+JAGpqIEldjG44Xs3n3hEO/HIC3TySjT8Vg4Hafl577E5GJaMtUxkLKYp5Ier+205uullDX9vAxq5yqeuvp3zWG7nmZ5wOvQ= Received: from VI1PR07MB4477.eurprd07.prod.outlook.com (2603:10a6:803:74::33) by VI1PR07MB5536.eurprd07.prod.outlook.com (2603:10a6:803:b7::26) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3305.10; Mon, 24 Aug 2020 17:07:11 +0000 Received: from VI1PR07MB4477.eurprd07.prod.outlook.com ([fe80::cba:ac03:353c:2d1f]) by VI1PR07MB4477.eurprd07.prod.outlook.com ([fe80::cba:ac03:353c:2d1f%7]) with mapi id 15.20.3326.017; Mon, 24 Aug 2020 17:07:11 +0000 From: Francesca Palombini To: Ace Wg CC: "ace-chairs@ietf.org" Thread-Topic: OSCORE profile update Thread-Index: AQHWejkBmDA4YAwm4U+IrXZL8lfsDA== Date: Mon, 24 Aug 2020 17:07:11 +0000 Message-ID: <34F92E00-8A32-4A57-AE7A-4BC68C670580@ericsson.com> Accept-Language: en-GB, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.40.20081000 authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=ericsson.com; x-originating-ip: [158.174.219.143] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: cd2c1e35-6032-4878-3870-08d848502415 x-ms-traffictypediagnostic: VI1PR07MB5536: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:5797; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: dh6d12lY27yridAqUthqrqoqWF/STz55UW0xExydl0x7BirBAHs06gm16wRkwu9ROIx/mRd/1Y4t5cK4J4Q8B64RT1LcitJ+bqkk1W87wIYhDkBRb7Gvn4g9ejXtgAJ3bsAo/8b9GbloJmuzip0jRijd96KxfgNBuFT7oxmmMGBVBXFljFFPRY3m0GtWjWxCaYOEYKDI0Ym7ubLq3G5UODqckn0mCJzwuhhaft9eEbOsnImttFbxBwSxLvQuCrNsT7berUFrVOpuVSm/Yq1R+oX+yaOOCQvBkwpQrgg0fvVmnk04zOWd0/n1RFnhElqx1Pin98Rq4MSM0LKKtDR423odBVdivRdzLzTJYBYPUgeHLb7a/BMhtnWx/0jvjezwDIu94z3Vz1uLR6JM8P4TQw== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:VI1PR07MB4477.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(376002)(396003)(136003)(366004)(346002)(39860400002)(26005)(6506007)(3480700007)(2906002)(6916009)(86362001)(66476007)(36756003)(8676002)(66556008)(83380400001)(4326008)(316002)(66946007)(66446008)(64756008)(71200400001)(2616005)(450100002)(7116003)(15650500001)(44832011)(8936002)(76116006)(91956017)(5660300002)(33656002)(6512007)(186003)(966005)(6486002)(478600001); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: j0CtKznDMPS/NpOt7cj4Ejq7Q4TcYg60OkmBPRadcwV8cGF4f1Z6UKMuw3vq4wDEYnYaRp6NbodqW33IXiFbv49Xat9fTyrxyKeCR1jF5VhcafSWtJsv7LYhNpW7AVvaxdYgSSKe/S6sKRnarKRDcZwQSqn8pmgL4O+EC74b8KqPSMNC+m4vbMc93Mul/9TkJBQPgH/fXsUuwKhUXh1FBzSmvrRnhJ4az6jYQAbd/t6H4PGfSTBYWMBoKvlOQRwGuEEa7WTOyxwR+NXpNOy4zoQlY3V6zGvnkbpLrgQnOEgAyjiNBalfv8yA/LEcyelydEPDfqo15J2btI7ZQd/j0wkOZphzhdDFMHT9cmiWspbWlbDTCmYKcBCbNA+XtRqSES9MQ6jY1OcMl+TzB+24R8eOoTAal9eBr7W1lGo77+F/O/XCau6FniP3HOTSQAanWkRQ+ZnCFnQk+X/e0TNF69WpLjTqJJdC/7cXRIpGtVuLeCW6lLyk+mGTBitkeYNbYMnzVAgfx1XY915DVkMhH8ioOA7/TKMrAzss4CdOjITbEnHMP3llqQ0S29cypWodEOqUm08Y/OoovHJ8wLNbJE7Gu470focSevLK+tZeXQfJrQ5KJcxecIMPCs15CBAleiJN4hpMIgP7Rvf8RtpSzA== x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-ID: <40F8A3CCDB1B8642B0A5DA9EC00D1531@eurprd07.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: VI1PR07MB4477.eurprd07.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: cd2c1e35-6032-4878-3870-08d848502415 X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Aug 2020 17:07:11.1879 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: ZggWZM20GZQjbCYkIyGl6rVuhG0CKgHAi+8B3rUAAUn17bvPi13UNzVQAUjPHaSHtFZ7B9kaj4XTirls+cEkUEvfXmz7INDEqed+VHnxCwEvT3lShjbAoE63+EK9ntv6 X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR07MB5536 Archived-At: Subject: [Ace] OSCORE profile update X-BeenThere: ace@ietf.org 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, 24 Aug 2020 17:07:29 -0000 SGksDQoNClRoaXMgbWFpbCBpcyB0byBub3RpZnkgdGhlIFdHIG9mIGEgbWlub3IgY2hhbmdlIHRv IHRoZSBPU0NPUkUgcHJvZmlsZS4gSXQgd2FzIGJyb3VnaHQgdXAgaW4gdGhlIGdpdGh1YiBpc3N1 ZXMgYnkgQ2hyaXN0aWFuIChzZWU6IGh0dHBzOi8vZ2l0aHViLmNvbS9hY2Utd2cvYWNlLW9zY29y ZS1wcm9maWxlL2lzc3Vlcy80MCApIGFuZCBkaXNjdXNzZWQgb2ZmbGluZSBkdXJpbmcgSUVURjEw OCB0aGF0IHRoZSBwcm9maWxlIGFkZHMgYSByZXF1aXJlbWVudCBvZiB0aGUgdG9rZW4gYWx3YXlz IGJlaW5nIGVuY3J5cHRlZCwgdGhhdCBpcyBub3QgaW5oZXJpdGVkIGZyb20gdGhlIGZyYW1ld29y ay4gVGhlIHJlYXNvbiBmb3IgdGhpcyBhZGRpdGlvbmFsIHJlcXVpcmVtZW50IHdhcyB0aGF0IHRo ZSBhdXRob3JzIGFzc3VtZWQgdGhlIHRva2VuIHRvIGFsd2F5cyBiZSBzZWxmLWNvbnRhaW5lZC4g QWZ0ZXIgZGlzY3Vzc2lvbiwgd2UgaGF2ZSBjb21lIHRvIHRoZSBjb25jbHVzaW9uIHRoYXQgdGhp cyByZXF1aXJlbWVudHMgZG9lcyBub3QgbmVlZCB0byBiZSBpbiB0aGUgcHJvZmlsZSwgYW5kIHdl IGhhdmUgcmVtb3ZlZCBpdDogaHR0cHM6Ly9naXRodWIuY29tL2FjZS13Zy9hY2Utb3Njb3JlLXBy b2ZpbGUvY29tbWl0L2RkN2E5YjVhMzBkYWNkMGNhNTVhMWViNDJiMjZjZDEzZDEwNDhkNTcgDQoN CldlIGRvIG5vdCB0aGluayB0aGlzIGlzIGEgbWFqb3IgY2hhbmdlLCBidXQgcmF0aGVyIGEgZml4 LCBzbyB3ZSBkb24ndCB0aGluayB3ZSBuZWVkIHRvIG1vdmUgYmFjayB0byB0aGUgV0csIGJ1dCB0 aGUgY2hhaXJzL0FEIGNhbiBsZXQgdXMga25vdyBpZiB0aGF0J3Mgbm90IHRoZSBjYXNlLiBXZSBh cmUgcmVhZHkgdG8gc3VibWl0IGEgdi0xMSBpbmNsdWRpbmcgdGhpcyBjaGFuZ2UgYW5kIHVwZGF0 ZXMgZm9sbG93aW5nIExhc3QgQ2FsbCByZXZpZXdzIGFuZCBJQU5BIHJldmlldywgYXNzdW1pbmcg dGhlcmUgaXMgbm8gb2JqZWN0aW9uLiBQdWxsIHJlcXVlc3QgaW5jbHVkaW5nIGFsbCBjaGFuZ2Vz IGlzIGhlcmU6IGh0dHBzOi8vZ2l0aHViLmNvbS9hY2Utd2cvYWNlLW9zY29yZS1wcm9maWxlL3B1 bGwvNDIgDQoNCk9uY2Ugdi0xMSBpcyB1cCwgd2UgY29uc2lkZXIgYWxsIGNvbW1lbnRzIGFkZHJl c3NlZCwgYW5kIGFyZSByZWFkeSBmb3IgdGhlIG5leHQgc3RlcC4NCg0KVGhhbmtzLA0KRnJhY2Vz Y2ENCg0K From nobody Mon Aug 24 10:11:42 2020 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ECE653A1181; Mon, 24 Aug 2020 10:11:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.19 X-Spam-Level: X-Spam-Status: No, score=-0.19 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H2=-0.001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=futurewei.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 QjzH6pOQj87K; Mon, 24 Aug 2020 10:11:27 -0700 (PDT) Received: from NAM11-BN8-obe.outbound.protection.outlook.com (mail-bn8nam11on2113.outbound.protection.outlook.com [40.107.236.113]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8F3FC3A12F7; Mon, 24 Aug 2020 10:10:32 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=XyePcW1YvmcKvgI9R61WgFmsy+nIZChPeC5lnzC9lSgHg6N7ILTaqjrsCrwVLbsgQZ912XCVhBxVWBP8MaedIIY/AHZESx6Jr+cgVIjM2rbDaKN7U3G/lvg1PpQU59gyaKpGxgQLtHqsvGzqLN1+RPel0mvnARHVW++1wwayYI6fcLi83kdhghNL0CCzUsKFbAtSdJK2FvTWIwlyaYvyVLPT9ykZZyt4M5CR+zdA4azyaF2aQeGH0OtHxPpqunFTzNhVIEJ2ylcLxw3wMJBtV9AcGwDDAumBPcvqVCK4BbbLB16NzZFocO0PstKWU6lwrOQ2tm1QMoYym0s46Lf+aA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=n00Qwlh0dlSQys6SPzKy3KllTf0F0E4nJ0f41TpCRVY=; b=fY8rpyikgq9fzkGNQ3zrPuF6R8g67PCFdp+VETKPI8J+4vbqQyD+8HbNgcp1fswiZ7BWORXuLXG0EphwNfaXEj1CmyO6BNR3q2NWlQmzCioijzfmnUOilJ9uZEEyr0cXEZME4SEjfB9BnkK0iC0go5HZjBHiFERzBeF8uJkwnEwpDXZ5uPAKU9SvVjiKYlSb//4gMBTDOrOJ1sKkJqITDEaJhuanCi6e+3cfahcjhJKjx9E2YmORzYS4yG4F0NTcsSOATd+EFpg1UwGElnflhjn8PswcTPwOJR8R6/dvFnIzvvPKoojFPBQT2/h/e7LK0f2ViLnXxAVcY66Fd+Tx9w== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=futurewei.com; dmarc=pass action=none header.from=futurewei.com; dkim=pass header.d=futurewei.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Futurewei.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=n00Qwlh0dlSQys6SPzKy3KllTf0F0E4nJ0f41TpCRVY=; b=tcVK2kV6JOIVHSx4zJoFNJqq51lAQw8F7SKagWO/1y3AEoRHVGVRGMRx67GFDqkvI34VqE30+pAYeKu3tZyI+gpb5LTtM37GaJoYc27JEivnGLD03D1oWF00jISAZxpg8c/l5JLnufaMzsi53LKxO7RvlEkgRaWDkUgxem2ua+E= Received: from SN6PR13MB2334.namprd13.prod.outlook.com (2603:10b6:805:55::16) by SN6PR13MB2432.namprd13.prod.outlook.com (2603:10b6:805:5f::24) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3326.10; Mon, 24 Aug 2020 17:10:29 +0000 Received: from SN6PR13MB2334.namprd13.prod.outlook.com ([fe80::44e5:1f97:c5a9:4346]) by SN6PR13MB2334.namprd13.prod.outlook.com ([fe80::44e5:1f97:c5a9:4346%3]) with mapi id 15.20.3326.017; Mon, 24 Aug 2020 17:10:29 +0000 From: Linda Dunbar To: Francesca Palombini , Benjamin Kaduk CC: "ops-dir@ietf.org" , "draft-ietf-ace-oscore-profile.all@ietf.org" , "ace@ietf.org" , "last-call@ietf.org" Thread-Topic: Opsdir last call review of draft-ietf-ace-oscore-profile-11 Thread-Index: AQHWZEDWIy6YV6PwqEKL0dnPbMXHIKlHqXqAgAAAzrA= Date: Mon, 24 Aug 2020 17:10:29 +0000 Message-ID: References: <159521497745.9074.17834135527258230957@ietfa.amsl.com> <20200727180742.GG41010@kduck.mit.edu> <5C8BDAEF-C8CF-433A-A093-2A9ACCD022EB@ericsson.com> In-Reply-To: <5C8BDAEF-C8CF-433A-A093-2A9ACCD022EB@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ericsson.com; dkim=none (message not signed) header.d=none; ericsson.com; dmarc=none action=none header.from=futurewei.com; x-originating-ip: [72.180.73.64] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 5e0aa81f-b2a9-4783-fba0-08d848509a5c x-ms-traffictypediagnostic: SN6PR13MB2432: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 6Zi38ekC/NKmwP5QwUY5CLWkInokCLJt6SdjF3rbm9AGkSjQp+UUPbxV3jfXBkKRQjrxVMJy5NCJ4aBo3dL9v8fX43QhySG9DOxVD9CX9rDTkexGg1kEzfUS5XfScK5BlXpOgyW6Zi3g/l/r63CJMbKNOq9s5b4P/LWotYwoGQzdVNAYxo3QIOmYv9VLw0UwEnh09X14k3lXqsllyw/6gtCIstdaogRcr9gQMo+tEBd/Xyy6X1GjDOmslSZ6/xjS00M5GR0zx/5vc1TBeYgQlfXWcbVuMmgUF+GEAzTXsBn4HzMp5qp+MmI0shvdpZR2VeXFPgm8r5WSXFYDpWfcKdTh65dFNhALvltHDhoNLzwQK7I2bGW9cIXpfT6TmQzyRp6PQs6wSIuYM5oasdpxdw== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:SN6PR13MB2334.namprd13.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(396003)(376002)(136003)(366004)(346002)(39840400004)(54906003)(110136005)(478600001)(316002)(9686003)(186003)(26005)(966005)(71200400001)(86362001)(45080400002)(44832011)(4326008)(66946007)(76116006)(7696005)(8676002)(66476007)(2906002)(66446008)(64756008)(66556008)(5660300002)(52536014)(53546011)(33656002)(6506007)(55016002)(83380400001)(8936002); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: mMNp3c6fRzYuDkIGPbIZPcFxeRHD+rU8j68s1eQt3w/TIff64Lhek/Cn6hBaF8zDnjiOQPSJ3knAFCzgreKH3cgcI4kt639u28S1hp4PPE8XUoN34Li1Fu26+F+Zw5PH2DKEEEERz2khh5x/ua3LgMPAE4K6l7p25FLgsee6aCGMv4dr/Unsl58D+e2P85n3uXx/gyylD8lpmke0DpRU38NDes1ZI/YT429xT2Zj5I385tWlgyZ/y2M4PX1MDkxRXJSjddNM3DMWIXcLFqcSQKeD+KC7d0jEPRZV8GuJvELDCDkBtPhjZobQ+5RpgBRCE3nxH2JtSoRuVfsdIRVaCJD5AaH4Gnt2m9supB73qoWIoAJTCdgxqqrRvBs0PU6/df2cgXa1l7V1GzBM2d8Y4rxhLlE5tuEpUrCjwQoRSs3E+bYLe6Y0IAnaQa56FrQUweupCTQRh8lcW0AHttW5gW6nxVJLfYzRSgrxGbomQu8y/Z9OlUVgvR1CfBXjpClhN1CGpiFnsvDPN9AKTB8S3pWFHVWS8B5jzHQSq9FvwxMrVY57sAXdh0eVMR0vx0DNeV/7kDBv/Wca74jJ6y6SmYli3FPzPkChnQ88+AnmP267XaLG3eP/bXT4hvzNddKQxczed/hhxlSngrA1/bo/LA== x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: Futurewei.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: SN6PR13MB2334.namprd13.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 5e0aa81f-b2a9-4783-fba0-08d848509a5c X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Aug 2020 17:10:29.5714 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 0fee8ff2-a3b2-4018-9c75-3a1d5591fedc X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: KXlN030+cAUDn/PQ5jxqg8izj1gUMimoJpON8jS7JawdIFMkfYyCBJ4u17Bsb3D/ERulD5TUhRzx2fMa1l8Q3g== X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN6PR13MB2432 Archived-At: Subject: Re: [Ace] Opsdir last call review of draft-ietf-ace-oscore-profile-11 X-BeenThere: ace@ietf.org 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, 24 Aug 2020 17:11:31 -0000 RnJhbmNlc2NhLCANCg0KVGhhbmsgeW91IHZlcnkgbXVjaCBmb3IgYWRkcmVzc2luZyB0aGUgY29t bWVudHMuIA0KDQpMaW5kYQ0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogRnJh bmNlc2NhIFBhbG9tYmluaSA8ZnJhbmNlc2NhLnBhbG9tYmluaUBlcmljc3Nvbi5jb20+IA0KU2Vu dDogTW9uZGF5LCBBdWd1c3QgMjQsIDIwMjAgMTI6MDcgUE0NClRvOiBCZW5qYW1pbiBLYWR1ayA8 a2FkdWtAbWl0LmVkdT47IExpbmRhIER1bmJhciA8bGluZGEuZHVuYmFyQGZ1dHVyZXdlaS5jb20+ DQpDYzogb3BzLWRpckBpZXRmLm9yZzsgZHJhZnQtaWV0Zi1hY2Utb3Njb3JlLXByb2ZpbGUuYWxs QGlldGYub3JnOyBhY2VAaWV0Zi5vcmc7IGxhc3QtY2FsbEBpZXRmLm9yZw0KU3ViamVjdDogUmU6 IE9wc2RpciBsYXN0IGNhbGwgcmV2aWV3IG9mIGRyYWZ0LWlldGYtYWNlLW9zY29yZS1wcm9maWxl LTExDQoNCkhpIExpbmRhLA0KDQpUaGFuayB5b3UgZm9yIHlvdXIgcmV2aWV3LiBCZW4gaGFzIGFs cmVhZHkgY2xhcmlmaWVkIG91ciBhaW0gZm9yIG1vc3Qgb2YgeW91ciBwb2ludHMsIHRoYW5rcyBC ZW4uIEkganVzdCB3YW50IHRvIGFkZCB0aGF0IHdlIGhhdmUgbm93IGFkZGVkIHNvbWUgdGV4dCB0 byBjbGFyaWZ5IHRoZSBDQk9SIGZvcm1hdHRpbmcgb2YgRmlndXJlIDcsIHlvdSBjYW4gc2VlIHRo ZSBkaWZmIGhlcmU6IGh0dHBzOi8vbmFtMTEuc2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9vay5j b20vP3VybD1odHRwcyUzQSUyRiUyRmdpdGh1Yi5jb20lMkZhY2Utd2clMkZhY2Utb3Njb3JlLXBy b2ZpbGUlMkZjb21taXQlMkY1NWQ1MDBhODkyMmI1Njk0ZGQ4MjFkNGIxMTA5Y2MxNjIzMTNmYzJm JmFtcDtkYXRhPTAyJTdDMDElN0NsaW5kYS5kdW5iYXIlNDBmdXR1cmV3ZWkuY29tJTdDZmI5MjIw ZWE3NmZiNDEwNGU1NTQwOGQ4NDg1MDIyNmMlN0MwZmVlOGZmMmEzYjI0MDE4OWM3NTNhMWQ1NTkx ZmVkYyU3QzElN0MxJTdDNjM3MzM4ODU2MzA0NTUyNzA3JmFtcDtzZGF0YT04YyUyQiUyRm5Kc1o5 ZFM4S085WCUyRmNhSW0wTHhOODBmS1hnUFpTelhrZnIxYWFjJTNEJmFtcDtyZXNlcnZlZD0wIFRo aXMgd2lsbCBiZSBpbmNsdWRlZCBpbiB0aGUgbmV4dCB1cGRhdGUgb2YgdGhlIGRvY3VtZW50Lg0K DQpUaGFua3MsDQpGcmFuY2VzY2ENCg0K77u/T24gMjcvMDcvMjAyMCwgMjA6MDgsICJCZW5qYW1p biBLYWR1ayIgPGthZHVrQG1pdC5lZHU+IHdyb3RlOg0KDQogICAgSGkgTGluZGEsDQoNCiAgICBP biBTdW4sIEp1bCAxOSwgMjAyMCBhdCAwODoxNjoxN1BNIC0wNzAwLCBMaW5kYSBEdW5iYXIgdmlh IERhdGF0cmFja2VyIHdyb3RlOg0KICAgID4gUmV2aWV3ZXI6IExpbmRhIER1bmJhcg0KICAgID4g UmV2aWV3IHJlc3VsdDogSGFzIE5pdHMNCiAgICA+IA0KICAgID4gSSBoYXZlIHJldmlld2VkIHRo aXMgZG9jdW1lbnQgYXMgcGFydCBvZiB0aGUgT3BzIGFyZWEgZGlyZWN0b3JhdGUncyBvbmdvaW5n DQogICAgPiBlZmZvcnQgdG8gcmV2aWV3IGFsbCBJRVRGIGRvY3VtZW50cyBiZWluZyBwcm9jZXNz ZWQgYnkgdGhlIElFU0cuICBUaGVzZQ0KICAgID4gY29tbWVudHMgd2VyZSB3cml0dGVuIHByaW1h cmlseSBmb3IgdGhlIGJlbmVmaXQgb2YgdGhlIE9wcyBhcmVhIGRpcmVjdG9ycy4NCiAgICA+IERv Y3VtZW50IGVkaXRvcnMgYW5kIFdHIGNoYWlycyBzaG91bGQgdHJlYXQgdGhlc2UgY29tbWVudHMg anVzdCBsaWtlIGFueSBvdGhlcg0KICAgID4gbGFzdCBjYWxsIGNvbW1lbnRzLg0KICAgID4gDQog ICAgPiBUaGlzIGRvY3VtZW50IGRlc2NyaWJlcyBob3cgdG8gc2V0IHNwZWNpZmljIHBhcmFtZXRl cnMgaW4gdXNpbmcgIHRoZQ0KICAgID4gQXV0aGVudGljYXRpb24gYW5kIEF1dGhvcml6YXRpb24g Zm9yIENvbnN0cmFpbmVkIEVudmlyb25tZW50cyAoQUNFKSBmcmFtZXdvcmsNCiAgICA+IFtJLUQu aWV0Zi1hY2Utb2F1dGgtYXV0aHpdLiBUaGUgZG9jdW1lbnQgaXMgd3JpdHRlbiBjbGVhciwgZXhj ZXB0IHNvbWUgbWlub3INCiAgICA+IGlzc3VlczoNCiAgICA+IA0KICAgID4gIFNlY3Rpb24gNC4x LjEgc3RhdGVzIHRoYXQgTm9uY2UgUGFyYW1ldGVyIG11c3QgYmUgc2VudCBmcm9tIHRoZSBjbGll bnQgdG8gUlMuDQogICAgPiAgV2hhdCB3b3VsZCBiZSB0aGUgcHJvYmxlbSBpZiB0aGUgY2xpZW50 IGRvZXNuJ3QgaW5jbHVkZSB0aGUgIk5PTkNFIj8NCg0KICAgIFRoZXJlJ3MgYSBsaXR0bGUgbW9y ZSBkaXNjdXNzaW9uIG9mIHRoZSBOMSBpbiB0aGUgcHJldmlvdXMgc2VjdGlvbiwgYnV0IGluDQog ICAgZXNzZW5jZSwgdGhpcyBub25jZSBpcyByZXF1aXJlZCB0byBwcm90ZWN0IHRoZSBjbGllbnQg YWdhaW5zdCByZXBsYXllZA0KICAgIHJlc3BvbnNlcy4gIFNpbmNlIHRoZSB0b2tlbiBjb250ZW50 cyAoaW5jbHVkaW5nIGtleSBkZXJpdmF0aW9uIG1hdGVyaWFsKQ0KICAgIHdvdWxkIGJlIHVuY2hh bmdlZCBhY3Jvc3Mgc2VjdXJpdHkgY29udGV4dHMsIHRoZSBub25jZSBpcyB1c2VkIHRvIG1ha2Ug ZWFjaA0KICAgIG9uZSBkaWZmZXJlbnQ7IGl0IGhhcyB0byBiZSBjbGllbnQtZ2VuZXJhdGVkIHNv IHRoYXQgdGhlIGNsaWVudCBpcyBzdXJlDQogICAgdGhhdCB0aGlzIHNlY3VyaXR5IGNvbnRleHQg aXMgImZyZXNoIiAodnMuIHJlcGxheWVkKS4NCg0KICAgID4gUGFnZSAxMjogSXQgYXNrcyBSRkMg ZWRpdG9yIHRvIHZhbGlkYXRlIHRoZSBudW1iZXJzIGxpc3RlZCBpbiBGaWd1cmUgNy4gIFRoZXJl DQogICAgPiBpcyBubyBleHBsYW5hdGlvbiBvciBjb21tZW50cyBmb3IgdGhvc2UgdmFsdWVzLiBJ dCB3aWxsIGJlIHZlcnkgZGlmZmljdWx0IGZvcg0KICAgID4gUkZDIGVkaXRvciB0byB2YWxpZGF0 ZS4gSXQgc2VlbXMgdG8gbWUgdGhlcmUgYXJlIDQgY29sdW1ucyBidXQgIEkgY2FuJ3QNCiAgICA+ IHVuZGVyc3RhbmQgdGhlIG1lYW5pbmcgb2YgdGhlIHZhbHVlcyB1bmRlciAxc3QsIDJuZCwgYW5k IDNyZCBjb2x1bW5zLg0KDQogICAgSSB0aGluayB0aGlzIGlzIGp1c3QgYSBub3RlIHRoYXQgdGhl IFJGQyBFZGl0b3Igc2hvdWxkIG1ha2Ugc3VyZSB0aGF0DQogICAgc29tZW9uZSBoYXMgY2hlY2tl ZCB0aGUgdmFsdWVzIChpLmUuLCB0aGUgYXV0aG9ycykuICBUaGUgUkZDIEVkaXRvciBkb2VzDQog ICAgbm90IG5lZWQgdG8gYmUgdGhlIG9uZSBhY3R1YWxseSBkb2luZyB0aGUgY2hlY2tpbmcuDQoN CiAgICBUaGFua3MgZm9yIHRoZSByZXZpZXcsDQoNCiAgICBCZW4NCg0KICAgID4gaXQgaXMga2lu ZCBvZiBkaWZmaWN1bHQgdG8gdmFsaWRhdGUgdGhlIGNvcnJlY3RuZXNzIGJ5IGp1c3QgcmVhZGlu ZyB0aHJvdWdoIHRoZQ0KICAgID4gZG9jdW1lbnQuICBJdCB3b3VsZCBiZSBiZXR0ZXIgdG8gaGF2 ZSBhbiBpbXBsZW1lbnRhdGlvbiByZXBvcnQgb2YgdGhlIHByb3Bvc2VkDQogICAgPiAiUHJvZmls ZSIuDQogICAgPiANCiAgICA+IEJlc3QgUmVnYXJkcywNCiAgICA+ICBMaW5kYSBEdW5iYXINCiAg ICA+IA0KICAgID4gDQogICAgPiANCg0K From nobody Tue Aug 25 13:55:36 2020 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0624C3A0BC4; Tue, 25 Aug 2020 13:55:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.002 X-Spam-Level: X-Spam-Status: No, score=0.002 tagged_above=-999 required=5 tests=[HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham 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 WKQXMtu6AN3W; Tue, 25 Aug 2020 13:55:31 -0700 (PDT) Received: from authenticated.a-painless.mh.aa.net.uk (a-painless.mh.aa.net.uk [IPv6:2001:8b0:0:30::51]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 854523A0BB0; Tue, 25 Aug 2020 13:55:31 -0700 (PDT) Received: from f.2.6.a.0.b.2.9.2.5.c.1.4.e.c.8.1.0.0.0.f.b.0.0.0.b.8.0.1.0.0.2.ip6.arpa ([2001:8b0:bf:1:8ce4:1c52:92b0:a62f]) by a-painless.mh.aa.net.uk with esmtpsa (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1kAfY0-0001Lp-G7; Tue, 25 Aug 2020 21:28:00 +0100 SavedFromEmail: elwynd@folly.org.uk Date: Tue, 25 Aug 2020 21:27:52 +0100 In-Reply-To: Importance: normal From: elwynd To: Francesca Palombini , Elwyn Davies , "gen-art@ietf.org" Cc: "last-call@ietf.org" , "draft-ietf-ace-oscore-profile.all@ietf.org" , "ace@ietf.org" MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--_com.samsung.android.email_9092192126283160" Message-ID: Archived-At: Subject: Re: [Ace] [Gen-art] Genart last call review of draft-ietf-ace-oscore-profile-11 X-BeenThere: ace@ietf.org 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: Tue, 25 Aug 2020 20:55:35 -0000 ----_com.samsung.android.email_9092192126283160 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 CkhpLCBGcmFuY2VzY2EuVGhpcyBhbGwgbG9va3MgZ29vZC7CoCBEaWQgeW91IGhhdmUgYW55IHRo b3VnaHRzIGFib3V0IGJlaW5nIGNsZWFyZXIgYWJvdXQgdGhlIGVuY3J5cHRpb24vYXV0aCBzdGF0 dXMgb2YgdGhlIHZhcmlvdXMgbWVzc2FnZXM/wqAgwqBJdCB3b3VsZCBoYXZlIGhlbHBlZCBtZSxD aGVlcnMsRWx3eW5TZW50IGZyb20gU2Ftc3VuZyB0YWJsZXQuCi0tLS0tLS0tIE9yaWdpbmFsIG1l c3NhZ2UgLS0tLS0tLS1Gcm9tOiBGcmFuY2VzY2EgUGFsb21iaW5pIDxmcmFuY2VzY2EucGFsb21i aW5pPTQwZXJpY3Nzb24uY29tQGRtYXJjLmlldGYub3JnPiBEYXRlOiAyNC8wOC8yMDIwICAxODow NyAgKEdNVCswMDowMCkgVG86IEVsd3luIERhdmllcyA8ZWx3eW5kQGRpYWwucGlwZXguY29tPiwg Z2VuLWFydEBpZXRmLm9yZyBDYzogbGFzdC1jYWxsQGlldGYub3JnLCBkcmFmdC1pZXRmLWFjZS1v c2NvcmUtcHJvZmlsZS5hbGxAaWV0Zi5vcmcsIGFjZUBpZXRmLm9yZyBTdWJqZWN0OiBSZTogW0dl bi1hcnRdIEdlbmFydCBsYXN0IGNhbGwgcmV2aWV3IG9mCsKgIGRyYWZ0LWlldGYtYWNlLW9zY29y ZS1wcm9maWxlLTExIEhpIEVsd3luLFRoYW5rIHlvdSBzbyBtdWNoIGZvciB5b3VyIHJldmlldy4g V2UgaGF2ZSBub3cgd29ya2VkIG9uIGFsbCB5b3VyIGNvbW1lbnRzIGluIGEgcHVsbCByZXF1ZXN0 LCBhbmQgd2lsbCBzb29uIHN1Ym1pdCBhbiB1cGRhdGUgdG8gdGhlIGRvY3VtZW50LiBBbGwgdGhl IG5pdHMgYXJlIGFkcmVzc2VkIGluIHR3byBjb21taXRzOiBodHRwczovL2dpdGh1Yi5jb20vYWNl LXdnL2FjZS1vc2NvcmUtcHJvZmlsZS9jb21taXQvYTdmOTQ4M2U5NjEwN2E2NzhiODAyMTdiYTBi MmQzZGNmYjQ4ODE5MsKgIGFuZCBodHRwczovL2dpdGh1Yi5jb20vYWNlLXdnL2FjZS1vc2NvcmUt cHJvZmlsZS9jb21taXQvODU1YzM0ODY1MTIwYTFmMDljMjhlYmU2ZGNlOTNhY2VkYjFmM2UwNCAu IERldGFpbGVkIGNvbW1lbnRzIGlubGluZSwgcHJlZmFjZWQgd2l0aCBbRlBdLlRoYW5rcyBhZ2Fp biBmb3IgdGhlIGdvb2QgY29tbWVudHMsRnJhbmNlc2NhT24gMjIvMDcvMjAyMCwgMDA6NTYsICJF bHd5biBEYXZpZXMgdmlhIERhdGF0cmFja2VyIiA8bm9yZXBseUBpZXRmLm9yZz4gd3JvdGU6wqDC oMKgIFJldmlld2VyOiBFbHd5biBEYXZpZXPCoMKgwqAgUmV2aWV3IHJlc3VsdDogQWxtb3N0IFJl YWR5wqDCoMKgIEkgYW0gdGhlIGFzc2lnbmVkIEdlbi1BUlQgcmV2aWV3ZXIgZm9yIHRoaXMgZHJh ZnQuIFRoZSBHZW5lcmFsIEFyZWHCoMKgwqAgUmV2aWV3IFRlYW0gKEdlbi1BUlQpIHJldmlld3Mg YWxsIElFVEYgZG9jdW1lbnRzIGJlaW5nIHByb2Nlc3NlZMKgwqDCoCBieSB0aGUgSUVTRyBmb3Ig dGhlIElFVEYgQ2hhaXIuwqAgUGxlYXNlIHRyZWF0IHRoZXNlIGNvbW1lbnRzIGp1c3TCoMKgwqAg bGlrZSBhbnkgb3RoZXIgbGFzdCBjYWxsIGNvbW1lbnRzLsKgwqDCoCBGb3IgbW9yZSBpbmZvcm1h dGlvbiwgcGxlYXNlIHNlZSB0aGUgRkFRIGF0wqDCoMKgIDxodHRwczovL3RyYWMuaWV0Zi5vcmcv dHJhYy9nZW4vd2lraS9HZW5BcnRmYXE+LsKgwqDCoCBEb2N1bWVudDogZHJhZnQtaWV0Zi1hY2Ut b3Njb3JlLXByb2ZpbGUtMTHCoMKgwqAgUmV2aWV3ZXI6IEVsd3luIERhdmllc8KgwqDCoCBSZXZp ZXcgRGF0ZTogMjAyMC0wNy0yMcKgwqDCoCBJRVRGIExDIEVuZCBEYXRlOiAyMDIwLTA3LTIwwqDC oMKgIElFU0cgVGVsZWNoYXQgZGF0ZTogTm90IHNjaGVkdWxlZCBmb3IgYSB0ZWxlY2hhdMKgwqDC oCBTdW1tYXJ5OsKgIEFsbW9zdCByZWFkeS7CoCBUaGVyZSBpcyBvbmUgbWlub3IgaXNzdWUgdGhh dCBuZWVkcyBzb3J0aW5nIG91dCBhbmQgYcKgwqDCoCBmYWlyIG51bWJlciBvZiBuaXRzLsKgIE92 ZXJhbGwgSSBoYXZlIHRvIHNheSB0aGF0IEkgZm91bmQgaXQgZGlmZmljdWx0IHRvIGtlZXDCoMKg wqAgY2xlYXIgaW4gbXkgbWluZCB3aGF0IG1lc3NhZ2VzIHdlcmUgZnVsbHkgZW5jcnlwdGVkIGFu ZCB3aGljaCBvbmVzIHdlcmUgc2VudCBlbsKgwqDCoCBjbGFpciBhbmQgd2hpY2ggYXJlIGluIHNv bWUgaW50ZXJtZWRpYXRlIGNsYXNzLsKgIFRoZSBhdXRob3JzIG1pZ2h0IHdpc2ggdG8gZ2/CoMKg wqAgYmFjayBvdmVyIHRoZSBkb2N1bWVudCBmcm9tIHRoZSBwb2ludCBvZiBhIG5haXZlIHJlYWRl ciB0byBlbnN1cmUgdGhhdCBpdCBpc8KgwqDCoCBjbGVhciBmb3IgaW1wbGVtZW50ZXJzLsKgwqDC oCBNYWpvciBpc3N1ZXM6wqDCoMKgIE5vbmXCoMKgwqAgTWlub3IgaXNzdWVzOsKgwqDCoCBzMiwg cGFyYSA1OsKgIFdoZXJlIGRvZXMgdGhlICdpbnB1dCBzYWx0JyBjb21lIGZyb20/wqAgVGhlIHRl cm0gaXMgbm90IHVzZWTCoMKgwqAgYW55d2hlcmUgZWxzZSBpbiB0aGlzIGRvY3VtZW50IGFuZMKg IGlzbid0IGRlZmluZWQgb3IgbWVudGlvbmVkIGluIGVpdGhlcsKgwqDCoCBkcmVmdC1hY2Utb2F1 dGgtYXV0aHogb3IgUkZDIDg2MTMuW0ZQXTogUmlnaHQsIGFzIEJlbiBtZW50aW9uZWQsIHRoaXMg d2FzIHRoZSByZXN1bHQgb2YgYW4gdXBkYXRlIHRvIHRoZSBuYW1lIG9mIHRoZSB0ZXJtLiBUaGUg aW5wdXQgc2FsdCBpcyB1c2VkIGFzIG9uZSBvZiB0aGUgaW5wdXRzIHRvIHRoZSBPU0NPUkUgTWFz dGVyIFNhbHQuIEkgaGF2ZSBub3cgcmVwaHJhc2VkIHRvIGNsYXJpZnkgdGhhdCAic2FsdCIgY29u dGFpbnMgaW4gZmFjdCBhbiBpbnB1dCB0byB0aGUgT1NDT1JFIE1hc3RlciBTYWx0LiAoaHR0cHM6 Ly9naXRodWIuY29tL2FjZS13Zy9hY2Utb3Njb3JlLXByb2ZpbGUvY29tbWl0LzA3Y2VkNmE0Zjkw ODQ5MWQ3ZDcwYzhjMmQ2ZmNhNzU5NmUzODAxZDQgKcKgwqDCoCBOaXRzL2VkaXRvcmlhbCBjb21t ZW50czrCoMKgwqAgczE6wqAgTmVlZCB0byBleHBhbmQgQ29BUCBvbiBmaXJzdCB1c2UuW0ZQXTog T2suwqDCoMKgIMKgwqDCoCBzMTogTmVlZCB0byBleHBhbmQgQ0JPUiBvbiBmaXJzdCB1c2UuW0ZQ XTogQWN0dWFsbHksIGJlY2F1c2UgQ0JPUiBhcHBlYXJzIG9uIGZpcnN0IHVzZSBhcyB0aGUgZmly c3QgdGVybSBvZiBDT1NFLCBJIGhhdmUgbm90IGV4cGFuZGVkIGl0IGluIHRoaXMgbG9jYXRpb24u IEkgaGF2ZSBhZGRlZCBhIG5vcm1hdGl2ZSByZWZlcmVuY2UgdG8gQ0JPUiBpbiB0aGUgdGVybWlu b2xvZ3kgYW5kIGV4cGFuZGVkIGl0IHRoZXJlLsKgwqDCoCBzMS4yLCBDRERMOsKgIEl0IHdvdWxk IHVzZWZ1bCB0byBtZW50aW9uIHRoYXQgdGhlIHByZWRlZmluZWQgdHlwZSBuYW1lcyBmcm9twqDC oMKgIENEREwsIGVzcGVjaWFsbHkgYnN0ciBmb3IgYnl0ZSBzdHJpbmdzIGFuZCB0c3RyIGZvciB0 ZXh0IHN0cmluZ3MswqAgYXJlIHVzZWTCoMKgwqAgZXh0ZW5zaXZlbHkgaW4gdGhlIGRvY3VtZW50 LltGUF06IFRoYW5rcyBmb3IgdGhlIHN1Z2dlc3Rpb24sIG5vdyBhZGRlZC7CoMKgwqAgczIsIHBh cmEgMTogcy9vdmVydmlldyBvbiBob3cvb3ZlcnZpZXcgb2YgaG93L1tGUF06IE9rLsKgwqDCoCBz MiwgcGFyYSAxOiBzL2FzIHdlbGwgYXMgT1NDT1JFIHNldHVwL2FzIHdlbGwgYXMgdGhlIE9TQ09S RSBzZXR1cC9bRlBdOiBPay7CoMKgwqAgczIsIHBhcmEgMjogcy90aGF0J3MvdGhhdCBpcy9bRlBd OiBPay7CoMKgwqAgczIsIHBhcmEgODogTmVlZCB0byBleHBhbmQgQUVBRCBvbiBmaXJzdCB1c2Uu W0ZQXTogT2suwqDCoMKgIHMyIGFuZCBGaWd1cmUgMTrCoCBJdCB3b3VsZCBiZSBoZWxwZnVsIHRv IHRoZSByZWFkZXIgaWYgRmlndXJlIDEgYW5kIGl0c8KgwqDCoCBkZXNjcmlwdGl2ZSBwYXJhZ3Jh cGggd2FzIHBsYWNlZCBjbG9zZXIgdG8gdGhlIGJlZ2lubmluZyBvZiBzMi7CoCBPdGhlcndpc2XC oMKgwqAgdGhpbmdzIGxpa2UgQ2xpZW50IEMnIG5lZWQgbW9yZSBleHBsYW5hdGlvbiB0byBwb2lu dCB0aGUgcmVhZGVyIGF0IHRoZSBmaWd1cmUuW0ZQXTogSSBoYXZlIGtlcHQgRmlndXJlIDEgYXQg dGhlIGVuZCBvZiB0aGUgc2VjdGlvbiwgYnV0IEkgaGF2ZSBub3cgcmVtb3ZlZCBhbGwgaW5zdGFu Y2VzIG9mICJDbGllbnQgQyIsIHNpbmNlIHRoZXkgZG9uJ3QgbWFrZSBzZW5zZSBiZWZvcmUgc2Vl aW5nIHRoZSBwaWN0dXJlLCBhcyB5b3UgcmlnaHRseSBub3RlZC7CoMKgwqAgczIsIHBhcmEgMzrC oMKgwqAgVGhpcyBzYXlzOsKgwqDCoCBUbyBkZXRlcm1pbmUgdGhlIEFTIGluIGNoYXJnZSBvZiBh IHJlc291cmNlIGhvc3RlZCBhdCB0aGUgUlMsIHRoZSBjbGllbnQgQyBNQVnCoMKgwqAgc2VuZCBh biBpbml0aWFsIFVuYXV0aG9yaXplZCBSZXNvdXJjZSBSZXF1ZXN0IG1lc3NhZ2UgdG8gdGhlIFJT LiBUaGUgUlMgdGhlbsKgwqDCoCBkZW5pZXMgdGhlIHJlcXVlc3QgYW5kIHNlbmRzIHRoZSBhZGRy ZXNzIG9mIGl0cyBBUyBiYWNrIHRvIHRoZSBjbGllbnQgQyBhc8KgwqDCoCBzcGVjaWZpZWQgaW4g c2VjdGlvbiA1LjEgb2YgW0ktRC5pZXRmLWFjZS1vYXV0aC1hdXRoel0uIFRoZSBhY2Nlc3MgdG9r ZW7CoMKgwqAgcmVxdWVzdCBhbmQgcmVzcG9uc2UgTVVTVCBiZSBjb25maWRlbnRpYWxpdHktcHJv dGVjdGVkIGFuZCBlbnN1cmUgYXV0aGVudGljaXR5wqDCoMKgIEkgZm91bmQgdGhlIGNvbWJpbmF0 aW9uIG9mIHRoZSBVbmF1dGhvcml6ZWQgUmVxdXN0IGFuZCB0aGXCoMKgwqAgY29uZmlkZW50aWFs aXR5LXByb3RlY3RlZCBldGMgY29uZnVzaW5nLsKgIElmIHRoZSBsYXN0IHNlbnRlbmNlIGRvZXMg YXBwbHkgdG/CoMKgwqAgdGhlIFVudXRob3JpemVkIFJlcXVlc3QgaXQgd291bGQgYmUgaGVscGZ1 bCB0byBtYWtlIGl0IGNsZWFyIHRoYXQgdGhpcyBpcyBub3TCoMKgwqAganVzdCBhIGdlbmVyaWMg c3RhdGVtZW50IGJ1dCBkb2VzIGFwcGx5IHRvIHRoZSBVbmF1dGhvcml6ZWQgUmVxdWVzdCBhcyB3 ZWxsLltGUF06IE9rLCB0aGFuayB5b3UgZm9yIHBvaW50aW5nIGl0IG91dC4gSSBoYXZlIG5vdyBj bGFyaWZpZWQgaW4gdGhlIGJlZ2lubmluZyBvZiB0aGUgcGFyYWdyYXBoIHRoYXQgdGhlIGFjY2Vz cyB0b2tlbiByZXF1ZXN0IGlzIGRpZmZlcmVudCBmcm9tIHRoZSBVbmF1dGhvcml6ZWQgUmVxdWVz dC7CoMKgwqAgRmlndXJlMTrCoCBGb3IgY29uc2lzdGVuY3kgdGhlIGZpcnN0IGxpbmUgc2hvdWxk IHNheSBVbmF1dGhvcml6ZWQgUnNvdXJjZcKgwqDCoCBSZXF1ZXN0LsKgIEkgd291bGQgYWxzbyBz dWdnZXN0IGV4cGxhaW5pbmcgdGhlIG1hcHBpbmcgYmV0d2VlbiB3aGF0IGlzIHNhaWQgaW7CoMKg wqAgdGhlIHRleHQgYW5kIHRoZSB0ZXJtcyAnQ2VhdGlvbiBIaW50cycgYW5kICdBY2Nlc3MgSW5m b3JtYXRpb24nIHVzZWQgaW4gdGhlwqDCoMKgIGZpZ3VyZS5bRlBdOiBPayBhYm91dCB0aGUgVW5h dXRob3JpemVkIFJlc291cmNlIFJlcXVlc3QuIEkgaGF2ZSBub3QgZXhwbGFpbmVkIGZ1cnRoZXIg YWJvdXQgdGhlIG1hcHBpbmcgYmV0d2VlbiB0aGUgb3ZlcnZpZXcgdGV4dCBhbmQgdGhlIGZpZ3Vy ZSwgYXMgSSBkbyBub3Qgd2FudCB0byBnbyBpbnRvIHRvbyBtdWNoIGRldGFpbCB0aGVyZSwgYnV0 IEkgaGF2ZSBjbGFyaWZpZWQgdGhhdCB0aGUgbmFtZXMgb2YgbWVzc2FnZXMgY29tZSBmcm9tIHRo ZSBmcmFtZXdvcmsuwqDCoMKgIHMzLjEsIHBhcmEgYWZ0ZXIgRmlndXJlIDI6wqAgVGhlIHRlcm0g J2F1ZGllbmNlJyBhcHBlYXJzIGluIHRoaXMgcGFyYWdyYXBowqDCoMKgIHdpdGhvdXQgYW55IGNv bnRleHQgaW5kaWNhdGluZyB3aGF0IGl0IG1lYW5zIC7CoCBMYXRlciBpbiBzMy4yIGl0IGFwcGVh cnMgdGhhdMKgwqDCoCBhdWRpZW5jZSBpcyBhc3NvY2lhdGVkIHdpdGggQ0JPUiB3ZWIgdG9rZW5z IChSRkMgODM5MikuwqAgQnV0IGl0IG1heSBhbHNvIG1pZ2h0wqDCoMKgIGFsc28gYmUgcmVhbHRl ZCB0byBkcmFmdC1vYXV0aC10b2tlbiBleGNoYW5nZS7CoCBUaGUgYXBwcm9wcmlhdGUgcmVmZXJl bmNlwqDCoMKgIGFob3VsZCBiZSBhZGRlZCBhbmQgc2hvdWxkIGJlIGV4cGxhaW5lZCBpbiBzMy4x LltGUF06IE9rLCBhZGRlZCBhIHJlZmVyZW5jZSB0byB0aGUgcmlnaHQgc2VjdGlvbiBpbiB0aGUg ZnJhbWV3b3JrLsKgwqDCoCBGaWd1cmUgMzrCoCBTaG91bGQgSWRDb250ZXh0IGJlIENvbnRleHRJ ZD/CoCBDb250ZXh0SWQgaXMgdXNlZCBldnJ5d2hlcmUgZWxzZS5bRlBdOiBHb29kIGNhdGNoIcKg wqDCoCBzMy4yOiBFeHBhbmQgSEtERiBvbiBmaXJzdCB1c2UgKCBpbiBzZWNvbmQgc2V0IG9mIGJ1 bGxldHMpLltGUF06IE9rLsKgwqDCoCBzMy4yLCBwYXJhIGFmdGVyIDJuZCBzZXQgb2YgYnVsbGV0 czrCoCBJIHRoaW5rIHRoZSBmb3VyIGluc3RhbmNlcyBvZiAnbWF5JyDCoMKgwqAgb3VnaHQgdG8g YmUgJ01BWScuW0ZQXTogVGhlc2UgbWF5IHdlcmUgbm90IG5vcm1hdGl2ZSBvbiBwdXJwb3NlLCBh cyB0aGUgbm9ybWF0aXZlIE1BWSBpcyB0aGUgb25lIGFib3ZlIHRoZSBidWxsZXQgbGlzdC4gSSBo YXZlIG5vdyByZXBocmFzZWQgdG8gcmVtb3ZlICJtYXkiIGZyb20gdGhpcyBwYXJhZ3JhcGgsIHRv IGF2b2lkIGNvbmZ1c2lvbi7CoMKgwqAgczMuMi4xOsKgIEl0IHdvdWxkIGJlIGhlbHBmdWwgdG8g cHJvdmlkZSByZWZlcmVuY2VzIHRvIHRoZSBvbmxpbmUgdmVyc2lvbnMgb2bCoMKgwqAgdGhlwqAg SUFOQSByZWdpc3RyaWVzICgzIHBsYWNlcykuW0ZQXTogT2suwqDCoMKgIHM0LjIsIHBhcmEgMTrC oMKgIEEgZm93YXJkIHJlZmVyZW5jZSB0byBzNSB3aGVyZSB0aGUgY29tdW5pY2F0aW9uIG1lY2hh bmlzbXPCoMKgwqAgbmVlZGVkIGZvciBpbnRyb3NwZWN0aW9uIGFyZSBkZXNjcmliZWQuW0ZQXTog SSBhZGRlZCBhIHJlZmVyZW5jZSB0byB0aGUgc2VjdGlvbiBvZiB0aGUgZnJhbWV3b3JrIHdoZXJl IGludHJvc3BlY3Rpb24gaXMgZGVzY3JpYmVkLsKgwqDCoCBzNC4xLCBwYXJhIDI6IHMvZnJvbSB3 aGF0IGRlc2NyaWJlZC9mcm9tIHdoYXQgaXMgZGVzY3JpYmVkL1tGUF06IE9rLsKgwqDCoCBzNC4y LCBwYXJhIDU6IHMvdGhhdCdzL3RoYXQgaXMvW0ZQXTogT2suwqDCoMKgIHM0LjIsIGxhc3QgcGFy YTsgcy9UaGlzIHNpbXBsaWZpZXMgZm9yIHRoZSBSUyB0cmFjay9UaGlzIHNpbXBsaWVzIHRoZSBw cm9jZXNzwqDCoMKgIG5lZWRlZCBieSB0aGUgUlMgdG8ga2VlcCB0cmFjay9bRlBdOiBPa8KgwqDC oCBzOCwgcGFyYSA2OiBzL3Rhc2tlZCBvZi90YXNrZWQgd2l0aC9bRlBdOiBPa8KgwqDCoCBzOS4z OsKgIEkgZG9uJ3QgdGhpbmsgdGhlIFZhbHVlIFR5cGUgZm9yIG5vbmNlIGlzICdJRVNHJyEgbG9s W0ZQXTogSW5kZWVkISBUaGFua3MuX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19HZW4tYXJ0IG1haWxpbmcgbGlzdEdlbi1hcnRAaWV0Zi5vcmdodHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2dlbi1hcnQ= ----_com.samsung.android.email_9092192126283160 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: base64 PGh0bWw+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0 L2h0bWw7IGNoYXJzZXQ9VVRGLTgiPjwvaGVhZD48Ym9keSBkaXI9ImF1dG8iPgo8ZGl2IGRpcj0i YXV0byI+SGksIEZyYW5jZXNjYS48L2Rpdj48ZGl2IGRpcj0iYXV0byI+PGJyPjwvZGl2PjxkaXYg ZGlyPSJhdXRvIj5UaGlzIGFsbCBsb29rcyBnb29kLiZuYnNwOyBEaWQgeW91IGhhdmUgYW55IHRo b3VnaHRzIGFib3V0IGJlaW5nIGNsZWFyZXIgYWJvdXQgdGhlIGVuY3J5cHRpb24vYXV0aCBzdGF0 dXMgb2YgdGhlIHZhcmlvdXMgbWVzc2FnZXM/Jm5ic3A7ICZuYnNwO0l0IHdvdWxkIGhhdmUgaGVs cGVkIG1lLDwvZGl2PjxkaXYgZGlyPSJhdXRvIj48YnI+PC9kaXY+PGRpdiBkaXI9ImF1dG8iPkNo ZWVycyw8L2Rpdj48ZGl2IGRpcj0iYXV0byI+RWx3eW48L2Rpdj48ZGl2IGRpcj0iYXV0byI+PGJy PjwvZGl2PjxkaXYgZGlyPSJhdXRvIj48YnI+PC9kaXY+PGRpdiBpZD0iY29tcG9zZXJfc2lnbmF0 dXJlIiBkaXI9ImF1dG8iPjxkaXYgc3R5bGU9ImZvbnQtc2l6ZTo4NSU7Y29sb3I6IzU3NTc1NyIg ZGlyPSJhdXRvIj5TZW50IGZyb20gU2Ftc3VuZyB0YWJsZXQuPC9kaXY+PC9kaXY+PGRpdiBkaXI9 ImF1dG8iPjxicj48L2Rpdj48ZGl2Pjxicj48L2Rpdj48ZGl2IGRpcj0iYXV0byIgc3R5bGU9ImZv bnQtc2l6ZToxMDAlO2NvbG9yOiMwMDAwMDAiPjxkaXY+LS0tLS0tLS0gT3JpZ2luYWwgbWVzc2Fn ZSAtLS0tLS0tLTwvZGl2PjxkaXY+RnJvbTogRnJhbmNlc2NhIFBhbG9tYmluaSAmbHQ7ZnJhbmNl c2NhLnBhbG9tYmluaT00MGVyaWNzc29uLmNvbUBkbWFyYy5pZXRmLm9yZyZndDsgPC9kaXY+PGRp dj5EYXRlOiAyNC8wOC8yMDIwICAxODowNyAgKEdNVCswMDowMCkgPC9kaXY+PGRpdj5UbzogRWx3 eW4gRGF2aWVzICZsdDtlbHd5bmRAZGlhbC5waXBleC5jb20mZ3Q7LCBnZW4tYXJ0QGlldGYub3Jn IDwvZGl2PjxkaXY+Q2M6IGxhc3QtY2FsbEBpZXRmLm9yZywgZHJhZnQtaWV0Zi1hY2Utb3Njb3Jl LXByb2ZpbGUuYWxsQGlldGYub3JnLCBhY2VAaWV0Zi5vcmcgPC9kaXY+PGRpdj5TdWJqZWN0OiBS ZTogW0dlbi1hcnRdIEdlbmFydCBsYXN0IGNhbGwgcmV2aWV3IG9mCiZuYnNwOyBkcmFmdC1pZXRm LWFjZS1vc2NvcmUtcHJvZmlsZS0xMSA8L2Rpdj48ZGl2Pjxicj48L2Rpdj48L2Rpdj5IaSBFbHd5 biw8YnI+PGJyPlRoYW5rIHlvdSBzbyBtdWNoIGZvciB5b3VyIHJldmlldy4gV2UgaGF2ZSBub3cg d29ya2VkIG9uIGFsbCB5b3VyIGNvbW1lbnRzIGluIGEgcHVsbCByZXF1ZXN0LCBhbmQgd2lsbCBz b29uIHN1Ym1pdCBhbiB1cGRhdGUgdG8gdGhlIGRvY3VtZW50LiBBbGwgdGhlIG5pdHMgYXJlIGFk cmVzc2VkIGluIHR3byBjb21taXRzOiBodHRwczovL2dpdGh1Yi5jb20vYWNlLXdnL2FjZS1vc2Nv cmUtcHJvZmlsZS9jb21taXQvYTdmOTQ4M2U5NjEwN2E2NzhiODAyMTdiYTBiMmQzZGNmYjQ4ODE5 MiZuYnNwOyBhbmQgaHR0cHM6Ly9naXRodWIuY29tL2FjZS13Zy9hY2Utb3Njb3JlLXByb2ZpbGUv Y29tbWl0Lzg1NWMzNDg2NTEyMGExZjA5YzI4ZWJlNmRjZTkzYWNlZGIxZjNlMDQgLiBEZXRhaWxl ZCBjb21tZW50cyBpbmxpbmUsIHByZWZhY2VkIHdpdGggW0ZQXS48YnI+PGJyPlRoYW5rcyBhZ2Fp biBmb3IgdGhlIGdvb2QgY29tbWVudHMsPGJyPkZyYW5jZXNjYTxicj48YnI+T24gMjIvMDcvMjAy MCwgMDA6NTYsICJFbHd5biBEYXZpZXMgdmlhIERhdGF0cmFja2VyIiAmbHQ7bm9yZXBseUBpZXRm Lm9yZyZndDsgd3JvdGU6PGJyPjxicj4mbmJzcDsmbmJzcDsmbmJzcDsgUmV2aWV3ZXI6IEVsd3lu IERhdmllczxicj4mbmJzcDsmbmJzcDsmbmJzcDsgUmV2aWV3IHJlc3VsdDogQWxtb3N0IFJlYWR5 PGJyPjxicj4mbmJzcDsmbmJzcDsmbmJzcDsgSSBhbSB0aGUgYXNzaWduZWQgR2VuLUFSVCByZXZp ZXdlciBmb3IgdGhpcyBkcmFmdC4gVGhlIEdlbmVyYWwgQXJlYTxicj4mbmJzcDsmbmJzcDsmbmJz cDsgUmV2aWV3IFRlYW0gKEdlbi1BUlQpIHJldmlld3MgYWxsIElFVEYgZG9jdW1lbnRzIGJlaW5n IHByb2Nlc3NlZDxicj4mbmJzcDsmbmJzcDsmbmJzcDsgYnkgdGhlIElFU0cgZm9yIHRoZSBJRVRG IENoYWlyLiZuYnNwOyBQbGVhc2UgdHJlYXQgdGhlc2UgY29tbWVudHMganVzdDxicj4mbmJzcDsm bmJzcDsmbmJzcDsgbGlrZSBhbnkgb3RoZXIgbGFzdCBjYWxsIGNvbW1lbnRzLjxicj48YnI+Jm5i c3A7Jm5ic3A7Jm5ic3A7IEZvciBtb3JlIGluZm9ybWF0aW9uLCBwbGVhc2Ugc2VlIHRoZSBGQVEg YXQ8YnI+PGJyPiZuYnNwOyZuYnNwOyZuYnNwOyAmbHQ7aHR0cHM6Ly90cmFjLmlldGYub3JnL3Ry YWMvZ2VuL3dpa2kvR2VuQXJ0ZmFxJmd0Oy48YnI+PGJyPiZuYnNwOyZuYnNwOyZuYnNwOyBEb2N1 bWVudDogZHJhZnQtaWV0Zi1hY2Utb3Njb3JlLXByb2ZpbGUtMTE8YnI+Jm5ic3A7Jm5ic3A7Jm5i c3A7IFJldmlld2VyOiBFbHd5biBEYXZpZXM8YnI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IFJldmlldyBE YXRlOiAyMDIwLTA3LTIxPGJyPiZuYnNwOyZuYnNwOyZuYnNwOyBJRVRGIExDIEVuZCBEYXRlOiAy MDIwLTA3LTIwPGJyPiZuYnNwOyZuYnNwOyZuYnNwOyBJRVNHIFRlbGVjaGF0IGRhdGU6IE5vdCBz Y2hlZHVsZWQgZm9yIGEgdGVsZWNoYXQ8YnI+PGJyPiZuYnNwOyZuYnNwOyZuYnNwOyBTdW1tYXJ5 OiZuYnNwOyBBbG1vc3QgcmVhZHkuJm5ic3A7IFRoZXJlIGlzIG9uZSBtaW5vciBpc3N1ZSB0aGF0 IG5lZWRzIHNvcnRpbmcgb3V0IGFuZCBhPGJyPiZuYnNwOyZuYnNwOyZuYnNwOyBmYWlyIG51bWJl ciBvZiBuaXRzLiZuYnNwOyBPdmVyYWxsIEkgaGF2ZSB0byBzYXkgdGhhdCBJIGZvdW5kIGl0IGRp ZmZpY3VsdCB0byBrZWVwPGJyPiZuYnNwOyZuYnNwOyZuYnNwOyBjbGVhciBpbiBteSBtaW5kIHdo YXQgbWVzc2FnZXMgd2VyZSBmdWxseSBlbmNyeXB0ZWQgYW5kIHdoaWNoIG9uZXMgd2VyZSBzZW50 IGVuPGJyPiZuYnNwOyZuYnNwOyZuYnNwOyBjbGFpciBhbmQgd2hpY2ggYXJlIGluIHNvbWUgaW50 ZXJtZWRpYXRlIGNsYXNzLiZuYnNwOyBUaGUgYXV0aG9ycyBtaWdodCB3aXNoIHRvIGdvPGJyPiZu YnNwOyZuYnNwOyZuYnNwOyBiYWNrIG92ZXIgdGhlIGRvY3VtZW50IGZyb20gdGhlIHBvaW50IG9m IGEgbmFpdmUgcmVhZGVyIHRvIGVuc3VyZSB0aGF0IGl0IGlzPGJyPiZuYnNwOyZuYnNwOyZuYnNw OyBjbGVhciBmb3IgaW1wbGVtZW50ZXJzLjxicj48YnI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IE1ham9y IGlzc3Vlczo8YnI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IE5vbmU8YnI+PGJyPiZuYnNwOyZuYnNwOyZu YnNwOyBNaW5vciBpc3N1ZXM6PGJyPiZuYnNwOyZuYnNwOyZuYnNwOyBzMiwgcGFyYSA1OiZuYnNw OyBXaGVyZSBkb2VzIHRoZSAnaW5wdXQgc2FsdCcgY29tZSBmcm9tPyZuYnNwOyBUaGUgdGVybSBp cyBub3QgdXNlZDxicj4mbmJzcDsmbmJzcDsmbmJzcDsgYW55d2hlcmUgZWxzZSBpbiB0aGlzIGRv Y3VtZW50IGFuZCZuYnNwOyBpc24ndCBkZWZpbmVkIG9yIG1lbnRpb25lZCBpbiBlaXRoZXI8YnI+ Jm5ic3A7Jm5ic3A7Jm5ic3A7IGRyZWZ0LWFjZS1vYXV0aC1hdXRoeiBvciBSRkMgODYxMy48YnI+ PGJyPltGUF06IFJpZ2h0LCBhcyBCZW4gbWVudGlvbmVkLCB0aGlzIHdhcyB0aGUgcmVzdWx0IG9m IGFuIHVwZGF0ZSB0byB0aGUgbmFtZSBvZiB0aGUgdGVybS4gVGhlIGlucHV0IHNhbHQgaXMgdXNl ZCBhcyBvbmUgb2YgdGhlIGlucHV0cyB0byB0aGUgT1NDT1JFIE1hc3RlciBTYWx0LiBJIGhhdmUg bm93IHJlcGhyYXNlZCB0byBjbGFyaWZ5IHRoYXQgInNhbHQiIGNvbnRhaW5zIGluIGZhY3QgYW4g aW5wdXQgdG8gdGhlIE9TQ09SRSBNYXN0ZXIgU2FsdC4gKGh0dHBzOi8vZ2l0aHViLmNvbS9hY2Ut d2cvYWNlLW9zY29yZS1wcm9maWxlL2NvbW1pdC8wN2NlZDZhNGY5MDg0OTFkN2Q3MGM4YzJkNmZj YTc1OTZlMzgwMWQ0ICk8YnI+PGJyPiZuYnNwOyZuYnNwOyZuYnNwOyBOaXRzL2VkaXRvcmlhbCBj b21tZW50czo8YnI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IHMxOiZuYnNwOyBOZWVkIHRvIGV4cGFuZCBD b0FQIG9uIGZpcnN0IHVzZS48YnI+PGJyPltGUF06IE9rLiZuYnNwOyZuYnNwOyZuYnNwOyA8YnI+ PGJyPiZuYnNwOyZuYnNwOyZuYnNwOyBzMTogTmVlZCB0byBleHBhbmQgQ0JPUiBvbiBmaXJzdCB1 c2UuPGJyPjxicj5bRlBdOiBBY3R1YWxseSwgYmVjYXVzZSBDQk9SIGFwcGVhcnMgb24gZmlyc3Qg dXNlIGFzIHRoZSBmaXJzdCB0ZXJtIG9mIENPU0UsIEkgaGF2ZSBub3QgZXhwYW5kZWQgaXQgaW4g dGhpcyBsb2NhdGlvbi4gSSBoYXZlIGFkZGVkIGEgbm9ybWF0aXZlIHJlZmVyZW5jZSB0byBDQk9S IGluIHRoZSB0ZXJtaW5vbG9neSBhbmQgZXhwYW5kZWQgaXQgdGhlcmUuPGJyPjxicj4mbmJzcDsm bmJzcDsmbmJzcDsgczEuMiwgQ0RETDombmJzcDsgSXQgd291bGQgdXNlZnVsIHRvIG1lbnRpb24g dGhhdCB0aGUgcHJlZGVmaW5lZCB0eXBlIG5hbWVzIGZyb208YnI+Jm5ic3A7Jm5ic3A7Jm5ic3A7 IENEREwsIGVzcGVjaWFsbHkgYnN0ciBmb3IgYnl0ZSBzdHJpbmdzIGFuZCB0c3RyIGZvciB0ZXh0 IHN0cmluZ3MsJm5ic3A7IGFyZSB1c2VkPGJyPiZuYnNwOyZuYnNwOyZuYnNwOyBleHRlbnNpdmVs eSBpbiB0aGUgZG9jdW1lbnQuPGJyPjxicj5bRlBdOiBUaGFua3MgZm9yIHRoZSBzdWdnZXN0aW9u LCBub3cgYWRkZWQuPGJyPjxicj4mbmJzcDsmbmJzcDsmbmJzcDsgczIsIHBhcmEgMTogcy9vdmVy dmlldyBvbiBob3cvb3ZlcnZpZXcgb2YgaG93Lzxicj48YnI+W0ZQXTogT2suPGJyPjxicj4mbmJz cDsmbmJzcDsmbmJzcDsgczIsIHBhcmEgMTogcy9hcyB3ZWxsIGFzIE9TQ09SRSBzZXR1cC9hcyB3 ZWxsIGFzIHRoZSBPU0NPUkUgc2V0dXAvPGJyPjxicj5bRlBdOiBPay48YnI+PGJyPiZuYnNwOyZu YnNwOyZuYnNwOyBzMiwgcGFyYSAyOiBzL3RoYXQncy90aGF0IGlzLzxicj48YnI+W0ZQXTogT2su PGJyPjxicj4mbmJzcDsmbmJzcDsmbmJzcDsgczIsIHBhcmEgODogTmVlZCB0byBleHBhbmQgQUVB RCBvbiBmaXJzdCB1c2UuPGJyPjxicj5bRlBdOiBPay48YnI+PGJyPiZuYnNwOyZuYnNwOyZuYnNw OyBzMiBhbmQgRmlndXJlIDE6Jm5ic3A7IEl0IHdvdWxkIGJlIGhlbHBmdWwgdG8gdGhlIHJlYWRl ciBpZiBGaWd1cmUgMSBhbmQgaXRzPGJyPiZuYnNwOyZuYnNwOyZuYnNwOyBkZXNjcmlwdGl2ZSBw YXJhZ3JhcGggd2FzIHBsYWNlZCBjbG9zZXIgdG8gdGhlIGJlZ2lubmluZyBvZiBzMi4mbmJzcDsg T3RoZXJ3aXNlPGJyPiZuYnNwOyZuYnNwOyZuYnNwOyB0aGluZ3MgbGlrZSBDbGllbnQgQycgbmVl ZCBtb3JlIGV4cGxhbmF0aW9uIHRvIHBvaW50IHRoZSByZWFkZXIgYXQgdGhlIGZpZ3VyZS48YnI+ PGJyPltGUF06IEkgaGF2ZSBrZXB0IEZpZ3VyZSAxIGF0IHRoZSBlbmQgb2YgdGhlIHNlY3Rpb24s IGJ1dCBJIGhhdmUgbm93IHJlbW92ZWQgYWxsIGluc3RhbmNlcyBvZiAiQ2xpZW50IEMiLCBzaW5j ZSB0aGV5IGRvbid0IG1ha2Ugc2Vuc2UgYmVmb3JlIHNlZWluZyB0aGUgcGljdHVyZSwgYXMgeW91 IHJpZ2h0bHkgbm90ZWQuPGJyPjxicj4mbmJzcDsmbmJzcDsmbmJzcDsgczIsIHBhcmEgMzo8YnI+ PGJyPiZuYnNwOyZuYnNwOyZuYnNwOyBUaGlzIHNheXM6PGJyPiZuYnNwOyZuYnNwOyZuYnNwOyBU byBkZXRlcm1pbmUgdGhlIEFTIGluIGNoYXJnZSBvZiBhIHJlc291cmNlIGhvc3RlZCBhdCB0aGUg UlMsIHRoZSBjbGllbnQgQyBNQVk8YnI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IHNlbmQgYW4gaW5pdGlh bCBVbmF1dGhvcml6ZWQgUmVzb3VyY2UgUmVxdWVzdCBtZXNzYWdlIHRvIHRoZSBSUy4gVGhlIFJT IHRoZW48YnI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IGRlbmllcyB0aGUgcmVxdWVzdCBhbmQgc2VuZHMg dGhlIGFkZHJlc3Mgb2YgaXRzIEFTIGJhY2sgdG8gdGhlIGNsaWVudCBDIGFzPGJyPiZuYnNwOyZu YnNwOyZuYnNwOyBzcGVjaWZpZWQgaW4gc2VjdGlvbiA1LjEgb2YgW0ktRC5pZXRmLWFjZS1vYXV0 aC1hdXRoel0uIFRoZSBhY2Nlc3MgdG9rZW48YnI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IHJlcXVlc3Qg YW5kIHJlc3BvbnNlIE1VU1QgYmUgY29uZmlkZW50aWFsaXR5LXByb3RlY3RlZCBhbmQgZW5zdXJl IGF1dGhlbnRpY2l0eTxicj48YnI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IEkgZm91bmQgdGhlIGNvbWJp bmF0aW9uIG9mIHRoZSBVbmF1dGhvcml6ZWQgUmVxdXN0IGFuZCB0aGU8YnI+Jm5ic3A7Jm5ic3A7 Jm5ic3A7IGNvbmZpZGVudGlhbGl0eS1wcm90ZWN0ZWQgZXRjIGNvbmZ1c2luZy4mbmJzcDsgSWYg dGhlIGxhc3Qgc2VudGVuY2UgZG9lcyBhcHBseSB0bzxicj4mbmJzcDsmbmJzcDsmbmJzcDsgdGhl IFVudXRob3JpemVkIFJlcXVlc3QgaXQgd291bGQgYmUgaGVscGZ1bCB0byBtYWtlIGl0IGNsZWFy IHRoYXQgdGhpcyBpcyBub3Q8YnI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IGp1c3QgYSBnZW5lcmljIHN0 YXRlbWVudCBidXQgZG9lcyBhcHBseSB0byB0aGUgVW5hdXRob3JpemVkIFJlcXVlc3QgYXMgd2Vs bC48YnI+PGJyPltGUF06IE9rLCB0aGFuayB5b3UgZm9yIHBvaW50aW5nIGl0IG91dC4gSSBoYXZl IG5vdyBjbGFyaWZpZWQgaW4gdGhlIGJlZ2lubmluZyBvZiB0aGUgcGFyYWdyYXBoIHRoYXQgdGhl IGFjY2VzcyB0b2tlbiByZXF1ZXN0IGlzIGRpZmZlcmVudCBmcm9tIHRoZSBVbmF1dGhvcml6ZWQg UmVxdWVzdC48YnI+PGJyPiZuYnNwOyZuYnNwOyZuYnNwOyBGaWd1cmUxOiZuYnNwOyBGb3IgY29u c2lzdGVuY3kgdGhlIGZpcnN0IGxpbmUgc2hvdWxkIHNheSBVbmF1dGhvcml6ZWQgUnNvdXJjZTxi cj4mbmJzcDsmbmJzcDsmbmJzcDsgUmVxdWVzdC4mbmJzcDsgSSB3b3VsZCBhbHNvIHN1Z2dlc3Qg ZXhwbGFpbmluZyB0aGUgbWFwcGluZyBiZXR3ZWVuIHdoYXQgaXMgc2FpZCBpbjxicj4mbmJzcDsm bmJzcDsmbmJzcDsgdGhlIHRleHQgYW5kIHRoZSB0ZXJtcyAnQ2VhdGlvbiBIaW50cycgYW5kICdB Y2Nlc3MgSW5mb3JtYXRpb24nIHVzZWQgaW4gdGhlPGJyPiZuYnNwOyZuYnNwOyZuYnNwOyBmaWd1 cmUuPGJyPjxicj5bRlBdOiBPayBhYm91dCB0aGUgVW5hdXRob3JpemVkIFJlc291cmNlIFJlcXVl c3QuIEkgaGF2ZSBub3QgZXhwbGFpbmVkIGZ1cnRoZXIgYWJvdXQgdGhlIG1hcHBpbmcgYmV0d2Vl biB0aGUgb3ZlcnZpZXcgdGV4dCBhbmQgdGhlIGZpZ3VyZSwgYXMgSSBkbyBub3Qgd2FudCB0byBn byBpbnRvIHRvbyBtdWNoIGRldGFpbCB0aGVyZSwgYnV0IEkgaGF2ZSBjbGFyaWZpZWQgdGhhdCB0 aGUgbmFtZXMgb2YgbWVzc2FnZXMgY29tZSBmcm9tIHRoZSBmcmFtZXdvcmsuPGJyPjxicj4mbmJz cDsmbmJzcDsmbmJzcDsgczMuMSwgcGFyYSBhZnRlciBGaWd1cmUgMjombmJzcDsgVGhlIHRlcm0g J2F1ZGllbmNlJyBhcHBlYXJzIGluIHRoaXMgcGFyYWdyYXBoPGJyPiZuYnNwOyZuYnNwOyZuYnNw OyB3aXRob3V0IGFueSBjb250ZXh0IGluZGljYXRpbmcgd2hhdCBpdCBtZWFucyAuJm5ic3A7IExh dGVyIGluIHMzLjIgaXQgYXBwZWFycyB0aGF0PGJyPiZuYnNwOyZuYnNwOyZuYnNwOyBhdWRpZW5j ZSBpcyBhc3NvY2lhdGVkIHdpdGggQ0JPUiB3ZWIgdG9rZW5zIChSRkMgODM5MikuJm5ic3A7IEJ1 dCBpdCBtYXkgYWxzbyBtaWdodDxicj4mbmJzcDsmbmJzcDsmbmJzcDsgYWxzbyBiZSByZWFsdGVk IHRvIGRyYWZ0LW9hdXRoLXRva2VuIGV4Y2hhbmdlLiZuYnNwOyBUaGUgYXBwcm9wcmlhdGUgcmVm ZXJlbmNlPGJyPiZuYnNwOyZuYnNwOyZuYnNwOyBhaG91bGQgYmUgYWRkZWQgYW5kIHNob3VsZCBi ZSBleHBsYWluZWQgaW4gczMuMS48YnI+PGJyPltGUF06IE9rLCBhZGRlZCBhIHJlZmVyZW5jZSB0 byB0aGUgcmlnaHQgc2VjdGlvbiBpbiB0aGUgZnJhbWV3b3JrLjxicj48YnI+Jm5ic3A7Jm5ic3A7 Jm5ic3A7IEZpZ3VyZSAzOiZuYnNwOyBTaG91bGQgSWRDb250ZXh0IGJlIENvbnRleHRJZD8mbmJz cDsgQ29udGV4dElkIGlzIHVzZWQgZXZyeXdoZXJlIGVsc2UuPGJyPjxicj5bRlBdOiBHb29kIGNh dGNoITxicj48YnI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IHMzLjI6IEV4cGFuZCBIS0RGIG9uIGZpcnN0 IHVzZSAoIGluIHNlY29uZCBzZXQgb2YgYnVsbGV0cykuPGJyPjxicj5bRlBdOiBPay48YnI+PGJy PiZuYnNwOyZuYnNwOyZuYnNwOyBzMy4yLCBwYXJhIGFmdGVyIDJuZCBzZXQgb2YgYnVsbGV0czom bmJzcDsgSSB0aGluayB0aGUgZm91ciBpbnN0YW5jZXMgb2YgJ21heScgPGJyPiZuYnNwOyZuYnNw OyZuYnNwOyBvdWdodCB0byBiZSAnTUFZJy48YnI+PGJyPltGUF06IFRoZXNlIG1heSB3ZXJlIG5v dCBub3JtYXRpdmUgb24gcHVycG9zZSwgYXMgdGhlIG5vcm1hdGl2ZSBNQVkgaXMgdGhlIG9uZSBh Ym92ZSB0aGUgYnVsbGV0IGxpc3QuIEkgaGF2ZSBub3cgcmVwaHJhc2VkIHRvIHJlbW92ZSAibWF5 IiBmcm9tIHRoaXMgcGFyYWdyYXBoLCB0byBhdm9pZCBjb25mdXNpb24uPGJyPjxicj4mbmJzcDsm bmJzcDsmbmJzcDsgczMuMi4xOiZuYnNwOyBJdCB3b3VsZCBiZSBoZWxwZnVsIHRvIHByb3ZpZGUg cmVmZXJlbmNlcyB0byB0aGUgb25saW5lIHZlcnNpb25zIG9mPGJyPiZuYnNwOyZuYnNwOyZuYnNw OyB0aGUmbmJzcDsgSUFOQSByZWdpc3RyaWVzICgzIHBsYWNlcykuPGJyPjxicj5bRlBdOiBPay48 YnI+PGJyPiZuYnNwOyZuYnNwOyZuYnNwOyBzNC4yLCBwYXJhIDE6Jm5ic3A7Jm5ic3A7IEEgZm93 YXJkIHJlZmVyZW5jZSB0byBzNSB3aGVyZSB0aGUgY29tdW5pY2F0aW9uIG1lY2hhbmlzbXM8YnI+ Jm5ic3A7Jm5ic3A7Jm5ic3A7IG5lZWRlZCBmb3IgaW50cm9zcGVjdGlvbiBhcmUgZGVzY3JpYmVk Ljxicj48YnI+W0ZQXTogSSBhZGRlZCBhIHJlZmVyZW5jZSB0byB0aGUgc2VjdGlvbiBvZiB0aGUg ZnJhbWV3b3JrIHdoZXJlIGludHJvc3BlY3Rpb24gaXMgZGVzY3JpYmVkLjxicj48YnI+Jm5ic3A7 Jm5ic3A7Jm5ic3A7IHM0LjEsIHBhcmEgMjogcy9mcm9tIHdoYXQgZGVzY3JpYmVkL2Zyb20gd2hh dCBpcyBkZXNjcmliZWQvPGJyPjxicj5bRlBdOiBPay48YnI+PGJyPiZuYnNwOyZuYnNwOyZuYnNw OyBzNC4yLCBwYXJhIDU6IHMvdGhhdCdzL3RoYXQgaXMvPGJyPjxicj5bRlBdOiBPay48YnI+PGJy PiZuYnNwOyZuYnNwOyZuYnNwOyBzNC4yLCBsYXN0IHBhcmE7IHMvVGhpcyBzaW1wbGlmaWVzIGZv ciB0aGUgUlMgdHJhY2svVGhpcyBzaW1wbGllcyB0aGUgcHJvY2Vzczxicj4mbmJzcDsmbmJzcDsm bmJzcDsgbmVlZGVkIGJ5IHRoZSBSUyB0byBrZWVwIHRyYWNrLzxicj48YnI+W0ZQXTogT2s8YnI+ PGJyPiZuYnNwOyZuYnNwOyZuYnNwOyBzOCwgcGFyYSA2OiBzL3Rhc2tlZCBvZi90YXNrZWQgd2l0 aC88YnI+PGJyPltGUF06IE9rPGJyPjxicj4mbmJzcDsmbmJzcDsmbmJzcDsgczkuMzombmJzcDsg SSBkb24ndCB0aGluayB0aGUgVmFsdWUgVHlwZSBmb3Igbm9uY2UgaXMgJ0lFU0cnISBsb2w8YnI+ PGJyPltGUF06IEluZGVlZCEgVGhhbmtzLjxicj48YnI+PGJyPjxicj48YnI+X19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+R2VuLWFydCBtYWlsaW5nIGxp c3Q8YnI+R2VuLWFydEBpZXRmLm9yZzxicj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL2dlbi1hcnQ8YnI+PC9ib2R5PjwvaHRtbD4= ----_com.samsung.android.email_9092192126283160-- From nobody Tue Aug 25 15:25:46 2020 Return-Path: X-Original-To: ace@ietf.org Delivered-To: ace@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5664F3A0770; Tue, 25 Aug 2020 15:25:45 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: ace@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.14.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: ace@ietf.org Message-ID: <159839434527.27686.1218816010237174588@ietfa.amsl.com> Date: Tue, 25 Aug 2020 15:25:45 -0700 Archived-At: Subject: [Ace] I-D Action: draft-ietf-ace-mqtt-tls-profile-07.txt X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.29 List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Aug 2020 22:25:45 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Authentication and Authorization for Constrained Environments WG of the IETF. Title : Message Queuing Telemetry Transport (MQTT)-TLS profile of Authentication and Authorization for Constrained Environments (ACE) Framework Authors : Cigdem Sengul Anthony Kirby Paul Fremantle Filename : draft-ietf-ace-mqtt-tls-profile-07.txt Pages : 31 Date : 2020-08-25 Abstract: This document specifies a profile for the ACE (Authentication and Authorization for Constrained Environments) framework to enable authorization in an Message Queuing Telemetry Transport (MQTT)-based publish-subscribe messaging system. Proof-of-possession keys, bound to OAuth2.0 access tokens, are used to authenticate and authorize MQTT Clients. The protocol relies on TLS for confidentiality and MQTT server (broker) authentication. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ace-mqtt-tls-profile/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-ace-mqtt-tls-profile-07 https://datatracker.ietf.org/doc/html/draft-ietf-ace-mqtt-tls-profile-07 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-ace-mqtt-tls-profile-07 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Aug 25 15:30:46 2020 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D7F413A0B57 for ; Tue, 25 Aug 2020 15:30:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.197 X-Spam-Level: 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: 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 6Zl5waYKNfJ8 for ; Tue, 25 Aug 2020 15:30:41 -0700 (PDT) Received: from mail-vk1-xa33.google.com (mail-vk1-xa33.google.com [IPv6:2607:f8b0:4864:20::a33]) (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 5CA213A0928 for ; Tue, 25 Aug 2020 15:30:34 -0700 (PDT) Received: by mail-vk1-xa33.google.com with SMTP id x142so119733vke.0 for ; Tue, 25 Aug 2020 15:30:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=ut2kIv2TbsfUwghcCIx2drcfgJaxdGKkINiTQ77nH7c=; b=cg8iA64mYQpwz4yzhkIYxRHedG5oqsLBSaD/dAgr2ySJi1tVS3zynWWQNFk35H7Egp 9tAdR5P6LyswxzjaAsgdz18rDA5Qk+rCfnHALtfrUqGtDEFmSXiJGlfOUinPwy4p3BKM nhhJwFKDqhUirQ5lINThnbn+HRqHfI/p4curIEHHM4zPWImx1WPYWYq3tFG1xfyHOaJV PK/fX3z3D6KD9q+JBw8aUbc7bFi8kjL/rL3fZcy7D1ljQIu4Ae0dsVeI16nt7P769hP9 fgACYTsSUeRbalgaLbrGBqYhVYKTG/zCpkC7qlDpTRoDS4vJpe3MpLL7mkWbW6oWoV7Z zy6w== 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; bh=ut2kIv2TbsfUwghcCIx2drcfgJaxdGKkINiTQ77nH7c=; b=B/kCJzsBzLRjuvl1ADwRfr12gWlGf3rmdecpnLxE3qLwYbCUljj4exL9KptKaw9MTm ibn2YlR2fqvhh5ZTDSGKCRZmpt8JxwszlCjU6Vji9KGJAzcAnFSiTCSmV78Frci3KN/E fk6aiPobBadDIHz5omnS85Op9oklQuMtRqLFlSOZdMGpnssPKpx7Y6fiUE2MCVuSY9wQ G0JBFvAaPWic5S7NBm5hd8QbHi5GD/dM6fUHurPQ1KppVwCeTfQVebsEh80/hwbmIetG S/ncsyIPl1ccn5ATmxH8wVLAg68LtREryue20ccNnLpGfK8elLisMpvcmpJLvMCgtpSS vflA== X-Gm-Message-State: AOAM533bu/KHMXEPre4UfczKSk0jaSiTdnRmy/vqs9ZuuofyaKCstXJv xov0AdiabdDjzIg1ZLmmd+wN+kg+ypet8LCMStavPk0gHqu1yA== X-Google-Smtp-Source: ABdhPJx2jE0azHHtdLNgz8qXnHPAWZaTljXadpQiMMhsTXW8l98IOlpEqY7/TZBZk4Nppo6r12DcgQIXAQrlIdcooYc= X-Received: by 2002:a1f:f28f:: with SMTP id q137mr7563832vkh.44.1598394632956; Tue, 25 Aug 2020 15:30:32 -0700 (PDT) MIME-Version: 1.0 References: <159839434527.27686.1218816010237174588@ietfa.amsl.com> In-Reply-To: <159839434527.27686.1218816010237174588@ietfa.amsl.com> From: Cigdem Sengul Date: Tue, 25 Aug 2020 23:30:23 +0100 Message-ID: To: Ace Wg Content-Type: multipart/alternative; boundary="0000000000004eef7905adbb4072" Archived-At: Subject: Re: [Ace] I-D Action: draft-ietf-ace-mqtt-tls-profile-07.txt X-BeenThere: ace@ietf.org 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: Tue, 25 Aug 2020 22:30:45 -0000 --0000000000004eef7905adbb4072 Content-Type: text/plain; charset="UTF-8" Dear Ace, As discussed in the last IETF meeting, I've submitted a new version that hopefully addresses the issues raised in the meeting and Jim's latest review: In Section 2.2.3, added the constraint on which packets the Client can send, and the server can process after CONNECT before CONNACK. In Section 2.2.3, clarified that session state is identified by Client Identifier, and listed its content. In Section 2.2.3, clarified the issue of Client Identifier collision when the broker supports session continuation. Corrected the buggy scope example in Section 3.1. Regards, --Cigdem On Tue, Aug 25, 2020 at 11:25 PM wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Authentication and Authorization for > Constrained Environments WG of the IETF. > > Title : Message Queuing Telemetry Transport (MQTT)-TLS > profile of Authentication and Authorization for Constrained Environments > (ACE) Framework > Authors : Cigdem Sengul > Anthony Kirby > Paul Fremantle > Filename : draft-ietf-ace-mqtt-tls-profile-07.txt > Pages : 31 > Date : 2020-08-25 > > Abstract: > This document specifies a profile for the ACE (Authentication and > Authorization for Constrained Environments) framework to enable > authorization in an Message Queuing Telemetry Transport (MQTT)-based > publish-subscribe messaging system. Proof-of-possession keys, bound > to OAuth2.0 access tokens, are used to authenticate and authorize > MQTT Clients. The protocol relies on TLS for confidentiality and > MQTT server (broker) authentication. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-ace-mqtt-tls-profile/ > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-ace-mqtt-tls-profile-07 > https://datatracker.ietf.org/doc/html/draft-ietf-ace-mqtt-tls-profile-07 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-ace-mqtt-tls-profile-07 > > > Please note that it may take a couple of minutes from the time of > submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > > _______________________________________________ > Ace mailing list > Ace@ietf.org > https://www.ietf.org/mailman/listinfo/ace > --0000000000004eef7905adbb4072 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Dear Ace,=C2=A0
As discussed in the l= ast IETF meeting, I've submitted a new version that hopefully=C2=A0addr= esses the issues raised in the meeting and Jim's latest review:
In Section 2.2.3, added the constraint on which packets the Client can s= end, and the server can process after CONNECT before CONNACK. In Section 2.= 2.3, clarified that session state is identified by Client Identifier, and l= isted its content.=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 In Section 2.2.3, clarifie= d the issue of Client Identifier collision when the broker supports session= continuation.=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Corrected the buggy scope example= in Section 3.1.=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0

Regards,
--Cigdem

On Tue, Aug 25, 2020 at 11:25 PM <internet-drafts@ietf.org> wr= ote:

A New Internet-Draft is available from the on-line Internet-Drafts director= ies.
This draft is a work item of the Authentication and Authorization for Const= rained Environments WG of the IETF.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= Message Queuing Telemetry Transport (MQTT)-TLS profile of Authentication a= nd Authorization for Constrained Environments (ACE) Framework
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Authors=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: Cigd= em Sengul
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Anthony Kirby
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Paul Fremantle
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-iet= f-ace-mqtt-tls-profile-07.txt
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= 31
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 := 2020-08-25

Abstract:
=C2=A0 =C2=A0This document specifies a profile for the ACE (Authentication = and
=C2=A0 =C2=A0Authorization for Constrained Environments) framework to enabl= e
=C2=A0 =C2=A0authorization in an Message Queuing Telemetry Transport (MQTT)= -based
=C2=A0 =C2=A0publish-subscribe messaging system.=C2=A0 Proof-of-possession = keys, bound
=C2=A0 =C2=A0to OAuth2.0 access tokens, are used to authenticate and author= ize
=C2=A0 =C2=A0MQTT Clients.=C2=A0 The protocol relies on TLS for confidentia= lity and
=C2=A0 =C2=A0MQTT server (broker) authentication.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/dr= aft-ietf-ace-mqtt-tls-profile/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf= -ace-mqtt-tls-profile-07
https://datatracker.ietf.org= /doc/html/draft-ietf-ace-mqtt-tls-profile-07

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?u= rl2=3Ddraft-ietf-ace-mqtt-tls-profile-07


Please note that it may take a couple of minutes from the time of submissio= n
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


_______________________________________________
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace
--0000000000004eef7905adbb4072-- From nobody Thu Aug 27 13:05:56 2020 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC1F43A129C for ; Thu, 27 Aug 2020 13:05:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.894 X-Spam-Level: X-Spam-Status: No, score=-1.894 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham 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 WmDmP2I-Y1KH for ; Thu, 27 Aug 2020 13:05:51 -0700 (PDT) Received: from p3plsmtpa08-07.prod.phx3.secureserver.net (p3plsmtpa08-07.prod.phx3.secureserver.net [173.201.193.108]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0D2953A129A for ; Thu, 27 Aug 2020 13:05:51 -0700 (PDT) Received: from [192.168.1.78] ([76.167.193.86]) by :SMTPAUTH: with ESMTPA id BO9dkjp3eFItaBO9dkaITh; Thu, 27 Aug 2020 13:05:50 -0700 X-CMAE-Analysis: v=2.3 cv=aOKOVo1m c=1 sm=1 tr=0 a=t2DvPg6iSvRzsOFYbaV4uQ==:117 a=t2DvPg6iSvRzsOFYbaV4uQ==:17 a=48vgC7mUAAAA:8 a=VrHXGImtAAAA:8 a=K6EGIJCdAAAA:8 a=Eqp6jkYgQ34o3N5TpJAA:9 a=SyrdsgEqa-XJUW_k:21 a=vFFfuvnHeaAGb_Vv:21 a=QEXdDO2ut3YA:10 a=ZZLNv0RtSJYDGVn108QA:9 a=uSGSoO5p8o597y66:21 a=8ZSD_EyMHTX0iJQT:21 a=_FPemj0bJg9INCJ5:21 a=_W_S_7VecoQA:10 a=w1C3t2QeGrPiZgrLijVG:22 a=rjybpTLx1R2UrS7S5igv:22 a=L6pVIi0Kn1GYQfi8-iRI:22 X-SECURESERVER-ACCT: lgl@island-resort.com From: Laurence Lundblade Message-Id: <1EEB1097-5E9E-4987-BA7B-29A71B3A120B@island-resort.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_BF215473-5BB2-4E56-ACBB-C2C8DC26BADE" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.15\)) Date: Thu, 27 Aug 2020 13:05:49 -0700 In-Reply-To: <00d201d67333$d8449d30$88cdd790$@augustcellars.com> Cc: Ace Wg , cose To: Jim Schaad References: <004201d66f79$3d95ed10$b8c1c730$@augustcellars.com> <66829A45-EDC1-4317-AA0A-FD335B6CF820@island-resort.com> <00af01d6728b$27579480$7606bd80$@augustcellars.com> <39135152-A5D8-48AB-B882-B29DCE5E3811@island-resort.com> <00d201d67333$d8449d30$88cdd790$@augustcellars.com> X-Mailer: Apple Mail (2.3445.104.15) X-CMAE-Envelope: MS4wfBO+VgS/fmQsDM4Ijhh6yMJYC/vj4NsvK8ckaWYDTx0svJRC7hH5RCDCN4dPDfC9is0UdWsr/t70EPCXrMZld97XLDP20JMwPExLTj6X4lVRMrfdmMaY yQCk1E+DfS93EEyhJN7vhbTSsZVUDIp+KvwZ/+NixfCvdB9DPvYqwajABwXbVUlej9d5cEr4yvk7u/HTt7/lDhz20K9TxVve6WknHa5jxAGEt9tQr3M+r7nq Archived-At: Subject: Re: [Ace] [COSE] Gap in registration of application/cwt? X-BeenThere: ace@ietf.org 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: Thu, 27 Aug 2020 20:05:54 -0000 --Apple-Mail=_BF215473-5BB2-4E56-ACBB-C2C8DC26BADE Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 In a CBOR thread it became clear (to me anyway) that in the context of = CBOR a =E2=80=9Ctag" is not a prefix, badge, identifier or such. It is = the combination of the identifier and the content. In the CBOR context = when you say =E2=80=9Ctag 1=E2=80=9D or =E2=80=9Cepoch-based date tag=E2=80= =9D you mean the major type 6 and the number content. The encoded CBOR = for a tag 1 with value for Jan 1, 1970 would be 0xc1 0x00. RFC 8392 uses the terminology incorrectly in section 5 = . It refers to the tag as = a prefix. Maybe errata should be filed on this? Going back to the identification of a CWT and/or COSE, my understanding = is that a =E2=80=9CCWT=E2=80=9D is a protocol message. A =E2=80=9CCWT = Tag=E2=80=9D is a type 6 item value 61 and the CWT protocol message. = The definition of the CWT protocol message stands apart from the = definition of tag 61. (This is not true of a tag 1 epoch date; the = definition of the date is intwined with the definition of tag 1). I believe the definition of the CWT protocol message allows the type of = COSE used to secure it to be identified in many ways. You can do it with = CBOR tags or you can do with externally such as my Application/CWT; = cose-type=3DCOSE_Sign1 content type example. Further, I think nesting of COSE works as follows. It doesn=E2=80=99t = have to be identified with COSE tags. Several levels of COSE can be = required by some top level media type or even by some CBOR tag that is = not a COSE defined tag. For example, I could define = application/very-secure-string as follows. - Start with string of bytes - Encrypt it with COSE_Encrypt (the string of bytes is the payload) = (note that this is not COSE_Encrypt_Tagged) - Sign it COSE_Sign1 (the COSE_Encrypt is the payload) (note that this = is not COSE_Sign1_Tagged - Mac it with COSE_Mac0 (the COSE_Sign1 is the payload) (note that = this is not COSE_Mac0_Tagged) I could make the payload at some level in this example some newly = defined tag that requires a COSE_Sign1 with EdDSA and indicates = something about its payload format. LL > On Aug 15, 2020, at 11:42 AM, Jim Schaad = wrote: >=20 > =20 > =20 > From: Laurence Lundblade >=20 > Sent: Saturday, August 15, 2020 10:58 AM > To: Jim Schaad > > Cc: cose >; Ace Wg > > Subject: Re: [Ace] [COSE] Gap in registration of application/cwt? > =20 > =20 >=20 >=20 >> On Aug 14, 2020, at 3:35 PM, Jim Schaad > wrote: >> =20 >> =20 >> =20 >> From: Laurence Lundblade >=20 >> Sent: Friday, August 14, 2020 1:59 PM >> To: Jim Schaad > >> Cc: Ace Wg >; cose > >> Subject: Re: [COSE] Gap in registration of application/cwt? >> =20 >> Here=E2=80=99s a series of scenarios that I think are legal CWT. = These are allowed by RFC 8392, right? >> =20 >> 1) Explicitly tagged, no external type info needed >> - Has CWT tag >> - Has COSE type tag >> [JLS] Yes >> =20 >> 2) CWT identification by label, COSE type tagged >> - The CWT is a CBOR data item with a label. The definition of the = label says the contents of the label are always CWT >> - No CWT tag necessary as it is implied by the label >> - Has a COSE type tag >> [JLS] Yes, the label could be internal to the CBOR object or external = such as an media-type > =20 > I was being very specific with the term label, meaning a label/key = identifying an item in a CBOR map. >=20 >=20 >> =20 >> 3) CWT and COSE by label >> - The CWT is an item with a label. The definition of the label says = the contents of the label are always CWT and of a specific COSE type >> - No tags necessary >> [JLS] Yes that would be fine >> =20 >> 4) Application/CWT identifies content as CWT, tagging for COSE type >> - No CWT tag >> - Has a COSE tag >> [JLS] This is the same as 2? I don=E2=80=99t think that it would be = restricted to just that media type. > =20 > You mean there could be other media types that also identify the = content as CWT? > [JLS] Yes this could be done in the future. One would normally = expect this to be an application specific profile, but funny things = happen. >> =20 >> 5) Application/CWT identifies content as CWT >> - Has CWT tag even though it is redundant=20 >> - Has a COSE tag >> [JLS] Yes > =20 > Additionally, one might interpret CBORbis 4.2.2 to say the the CWT tag = should not be present. > [JLS] For deterministic encoding, but not for general encoding. >> =20 >> 6) Application/CWT; cose-type=3DCOSE_Sign1 (or Mac0 or =E2=80=A6) >> - No tags are used >> - Identification is completely by the MIME type header >> - (I understand that the cose-type MIME parameter is not defined, but = it could be. 8392 doesn=E2=80=99t forbid it) >> [JLS] Yes you could do that, and as I stated in a previous mail this = is not a good idea for the CoAP world. >> =20 >> 7) A protocol like FIDO identifies a protocol element that is an = attention type the type of which is CWT with COSE_Sign1 >> - No tags are used >> [JLS] yes >> =20 >> 8) A protocol like FIDO identifies a protocol element that is an = attention type the type of which is CWT; the COSE type is determined by = tag >> - No CWT tag >> - Has a COSE tag >> [JLS] yes >> =20 >> The one thing you can=E2=80=99t do is have a CWT tag without a COSE = type tag. 8392 section 6 forbids this. >> =20 >> [JLS] There however is a set of nested cases that you might need to = look at. That is 6.CWT ( COSE_Encrypt_Tagged ( COSE_Sign )) You would = also need to think about the requirements for nested COSE layers. > =20 > All but the most outer COSE type are always identified by a tag, per = 7.1 step 5 and 7.2 step 6, right? > [JLS] Yes I guess that is true. I think my code is more generous that = this in terms of what is accepted. > Jim > =20 > =20 > LL > =20 >=20 >=20 >> =20 >> Jim >> =20 >> =20 >> LL >> =20 >> =20 >> =20 >> =20 >>=20 >>=20 >>=20 >>> On Aug 11, 2020, at 12:20 PM, Laurence Lundblade = > wrote: >>> =20 >>> =20 >>>=20 >>>=20 >>>=20 >>>> On Aug 10, 2020, at 5:49 PM, Jim Schaad > wrote: >>>> =20 >>>> This is all based on my understanding that the surrounding protocol = for must specify exactly when CBOR tags are to be used and when they are = not to be used and that the surrounding protocol must not leave it as an = optional implementation choice. In this case application/cwt is the = supporting protocol. >>>> =20 >>>> [JLS] What is the text that says that this is true. This would be = a surprising statement for me. >>>=20 >>> =20 >>> Here=E2=80=99s three things that lead me to this. >>> =20 >>>> CBORbis >>>> The sentence of the first paragraph in 4.2.2 = = very clearly states this, though this is only for deterministic = encoding. >>>> =20 >>>> Typical CDDL >>>> Most CDDL that describes tagged data describes it only as tagged or = untagged, not as optionally tagged. COSE is one example of this.=20 >>>> =20 >>>> Email threads >>>> This thread = and this thread = . >>>> =20 >>>> I summarized this behavior in this email = = and no where in the rest of the thread was it indicated differently. >>>> =20 >>> So, it is not a hard requirement because 4.2.2 is only for = deterministic encoding, but seems like a =E2=80=9Cshould" in spirit. It = is the preferred way to design a CBOR protocol. >>> =20 >>> However you slice it, I think it is up to the surrounding protocol = to say whether a tag is always required, never required or optionally = required. If the protocol doesn=E2=80=99t say, then it defaults to = optionally required. >>> =20 >>> Defaulting or explicitly allowing optional tagging means the = receiver has to allow for all the tagging scenarios and makes possible = the error case where the surrounding protocol says the data is of one = type and the tag conflicts with it. (e.g. an application/cwt that = contains a tagged CoSWID). >>> =20 >>> I don=E2=80=99t think optional tagging is of any advantage in a = protocol design. It doesn=E2=80=99t enable anything. >>> =20 >>> It has some disadvantage because it introduces error conditions and = potential confusion. >>> =20 >>> I think there are several scenarios with section 6 and = application/cwt that could be more clear. >>> =20 >>>> Can you use tag 61 or not? I think the current answer is that in = application/cwt, tag 61 is optional. >>>> =20 >>>> How do you know what the COSE type is? It is somewhat obvious that = COSE tags will work, but there is no requirement to use them. A MIME = parameter or other is entirely allowed here. >>>> =20 >>>> Section 6 does say that determination that something is a CWT is = application dependent, but doesn=E2=80=99t say that the COSE type is = also application dependent. Section 7 does address this. >>> =20 >>> Said another way, my fully general CWT decoder that is called by = some application needs an input parameter to indicate the COSE type = because there is no requirement in 8392 that a CWT indicate which COSE = type is in use. Sometimes the caller will be able to provide the COSE = type and sometimes they won=E2=80=99t. Sometimes there will be an error = of conflicting COSE type and sometimes the error will be that the COSE = type can=E2=80=99t be determined. >>> =20 >>> I think it would have been cleanest if CWT always indicated the COSE = type be used and the tagging optionality didn=E2=80=99t span two = protocol layers, but that would be an incompatible change. Maybe a = recommendation that CWT=E2=80=99s SHOULD always indicate their COSE = type? >>> =20 >>> LL >>=20 >> =20 >> _______________________________________________ >> Ace mailing list >> Ace@ietf.org >> https://www.ietf.org/mailman/listinfo/ace = > =20 > _______________________________________________ > Ace mailing list > Ace@ietf.org > https://www.ietf.org/mailman/listinfo/ace --Apple-Mail=_BF215473-5BB2-4E56-ACBB-C2C8DC26BADE Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
In a CBOR thread it became clear (to me anyway) that in the = context of CBOR a =E2=80=9Ctag" is not a prefix, badge, identifier or = such. It is the combination of the identifier and the content. In the = CBOR context when you say =E2=80=9Ctag 1=E2=80=9D or =E2=80=9Cepoch-based = date tag=E2=80=9D you mean the major type 6 and the = number content.  The encoded CBOR for a tag 1 with value for Jan 1, = 1970 would be 0xc1 0x00.

RFC 8392 uses the terminology incorrectly in section = 5. It refers to the tag as a prefix. Maybe errata should be filed on = this?


Going back to the identification of a = CWT and/or COSE, my understanding is that a =E2=80=9CCWT=E2=80=9D is a = protocol message. A =E2=80=9CCWT Tag=E2=80=9D is a type 6 item value 61 = and the CWT protocol message.  The definition of = the CWT protocol message stands apart from the definition of tag 61. = (This is not true of a tag 1 epoch date; the definition of the date is = intwined with the definition of tag 1).

I believe the definition of the CWT = protocol message allows the type of COSE used to secure it to be = identified in many ways. You can do it with CBOR tags or you can do with = externally such as my Application/CWT; cose-type=3DCOSE_Sign1 content = type example.

Further, I think nesting of COSE works as follows. It = doesn=E2=80=99t have to be identified with COSE tags. Several levels of = COSE can be required by some top level media type or even by some CBOR = tag that is not a COSE defined tag. For example, I could define = application/very-secure-string as follows.
  - = Start with string of bytes
  - Encrypt it with = COSE_Encrypt (the string of bytes is the payload) (note that this is = not COSE_Encrypt_Tagged)
  - Sign it = COSE_Sign1 (the COSE_Encrypt is the payload) (note that this is = not COSE_Sign1_Tagged
  - Mac it with COSE_Mac0 = (the COSE_Sign1 is the payload) (note that this is = not COSE_Mac0_Tagged)

I could make the payload at some level in this example some = newly defined tag that requires a COSE_Sign1 with EdDSA and = indicates something about its payload format.

LL





On Aug 15, 2020, at 11:42 AM, = Jim Schaad <ietf@augustcellars.com> wrote:

 
 
From: Laurence Lundblade <lgl@island-resort.com> 
Sent: Saturday, August 15, 2020 = 10:58 AM
To: Jim Schaad <ietf@augustcellars.com>
Cc: cose <cose@ietf.org>; Ace Wg <ace@ietf.org>
Subject: Re: [Ace] [COSE] Gap in = registration of application/cwt?
 
 


On Aug 14, 2020, at = 3:35 PM, Jim Schaad <ietf@augustcellars.com> wrote:
 
 
 
From: Laurence Lundblade <lgl@island-resort.com> 
Sent: Friday, August 14, 2020 = 1:59 PM
To: Jim Schaad <ietf@augustcellars.com>
Cc: Ace Wg <ace@ietf.org>; cose <cose@ietf.org>
Subject: Re: [COSE] Gap in = registration of application/cwt?
 
Here=E2=80=99s a series of = scenarios that I think are legal CWT. These are allowed by RFC 8392, = right?
 
1) Explicitly tagged, no external type info = needed
- Has CWT tag
- Has COSE type tag
[JLS] = Yes
 
2) CWT identification by label, COSE type = tagged
- The CWT is a CBOR data item with a = label. The definition of the label says the contents of the label are = always CWT
- No CWT tag necessary as it is implied = by the label
- Has a COSE type tag
[JLS] = Yes, the label could be internal to the CBOR object or external such as = an media-type
 
I was being very specific with the term = label, meaning a label/key identifying an item in a CBOR map.


 
3) CWT and COSE by label
- The CWT is an item with a label. The = definition of the label says the contents of the label are always CWT = and of a specific COSE type
- No tags necessary
[JLS] Yes = that would be fine
 
4) Application/CWT identifies content as CWT, = tagging for COSE type
- No CWT tag
- Has a COSE tag
[JLS] = This is the same as 2?  I don=E2=80=99t think that it would be = restricted to just that media type.
 
You mean there could be other media = types that also identify the content as CWT?
[JLS] Yes this could be = done in the future.   One would normally expect this to be an = application specific profile, but funny things happen.
 
5) Application/CWT identifies content = as CWT
- Has CWT tag even though it is = redundant 
- Has a COSE tag
[JLS] = Yes
 
Additionally, one might interpret CBORbis 4.2.2 to say the = the CWT tag should not be present.
[JLS] For deterministic encoding, but not =  for general encoding.
 
6) Application/CWT; = cose-type=3DCOSE_Sign1 (or Mac0 or =E2=80=A6)
- No tags are used
- Identification is completely by the MIME type = header
- (I understand that the cose-type MIME = parameter is not defined, but it could be. 8392 doesn=E2=80=99t forbid = it)
[JLS]= Yes you could do that, and as I stated in a previous mail this is not a = good idea for the CoAP world.
 
7) A protocol like FIDO identifies a protocol = element that is an attention type the type of which is CWT with = COSE_Sign1
- No tags are used
[JLS] = yes
 
8) A protocol like FIDO identifies a = protocol element that is an attention type the type of which is CWT; the = COSE type is determined by tag
- No CWT tag
- Has a COSE tag
[JLS] = yes
 
The one thing you can=E2=80=99t do is have a CWT = tag without a COSE type tag. 8392 section 6 forbids this.
 
[JLS] = There however is a set of nested cases that you might need to look = at.  That is 6.CWT ( COSE_Encrypt_Tagged ( COSE_Sign ))  You = would also need to think about the requirements for nested COSE = layers.
 
All = but the most outer COSE type are always identified by a tag, per 7.1 = step 5 and 7.2 step 6, right?
[JLS] Yes I guess that is true.  I think my = code is more generous that this in terms of what is accepted.
Jim
 
 
LL
 


 
Jim
 
 
LL
 
 
 
 



On Aug 11, 2020, at 12:20 PM, Laurence = Lundblade <lgl@island-resort.com> wrote:
 
 



On Aug 10, 2020, at 5:49 PM, Jim Schaad = <ietf@augustcellars.com> = wrote:
 
This is = all based on my understanding that the surrounding protocol for must = specify exactly when CBOR tags are to be used and when they are not to = be used and that the surrounding protocol must not leave it as an = optional implementation choice. In this case application/cwt is the = supporting protocol.
 
[JLS] What is the text that says that this is = true.  This would be a surprising statement for me.
 
Here=E2=80=99s three things that lead me to = this.
 
CBORbis
The sentence of the first paragraph in 4.2.2 very clearly states this, though this is only = for deterministic encoding.
 
Typical CDDL
Most CDDL that describes tagged data describes = it only as tagged or untagged, not as optionally tagged.  COSE is = one example of this. 
 
Email threads
This thread and this thread.
 
I summarized this behavior = in this email and no where in the rest of the thread was it = indicated differently.
 
So, it is not a hard requirement because 4.2.2 = is only for deterministic encoding, but seems like a =E2=80=9Cshould" in = spirit. It is the preferred way to design a CBOR protocol.
 
However you slice it, I = think it is up to the surrounding protocol to say whether a tag is = always required, never required or optionally required. If the protocol = doesn=E2=80=99t say, then it defaults to optionally required.
 
Defaulting or explicitly = allowing optional tagging means the receiver has to allow for all the = tagging scenarios and makes possible the error case where the = surrounding protocol says the data is of one type and the tag conflicts = with it. (e.g. an application/cwt that contains a tagged CoSWID).
 
I don=E2=80=99t think = optional tagging is of any advantage in a protocol design. It doesn=E2=80=99= t enable anything.
 
It has some disadvantage because it introduces = error conditions and potential confusion.
 
I think there are several = scenarios with section 6 and application/cwt that could be more = clear.
 
Can you use tag 61 or not? I think the current = answer is that in application/cwt, tag 61 is optional.
 
How do you know what the = COSE type is? It is somewhat obvious that COSE tags will work, but there = is no requirement to use them. A MIME parameter or other is entirely = allowed here.
 
Section 6 does say that determination that = something is a CWT is application dependent, but doesn=E2=80=99t say = that the COSE type is also application dependent. Section 7 does address = this.
 
Said another way, my fully general CWT decoder = that is called by some application needs an input parameter to indicate = the COSE type because there is no requirement in 8392 that a CWT = indicate which COSE type is in use. Sometimes the caller will be able to = provide the COSE type and sometimes they won=E2=80=99t. Sometimes there = will be an error of conflicting COSE type and sometimes the error will = be that the COSE type can=E2=80=99t be determined.
 
I think it would have been = cleanest if CWT always indicated the COSE type be used and the tagging = optionality didn=E2=80=99t span two protocol layers, but that would be = an incompatible change.  Maybe a recommendation that CWT=E2=80=99s = SHOULD always indicate their COSE type?
 
LL
 
_______________________________________________
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace
 
_______________________________________________
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace
= --Apple-Mail=_BF215473-5BB2-4E56-ACBB-C2C8DC26BADE-- From nobody Thu Aug 27 15:19:25 2020 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 39BF03A13BA; Thu, 27 Aug 2020 15:19:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham 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 V0xICBXrggDd; Thu, 27 Aug 2020 15:19:17 -0700 (PDT) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 92CF23A13BE; Thu, 27 Aug 2020 15:19:08 -0700 (PDT) Received: from Jude (73.180.8.170) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Thu, 27 Aug 2020 15:19:00 -0700 From: Jim Schaad To: 'Laurence Lundblade' CC: 'Ace Wg' , 'cose' References: <004201d66f79$3d95ed10$b8c1c730$@augustcellars.com> <66829A45-EDC1-4317-AA0A-FD335B6CF820@island-resort.com> <00af01d6728b$27579480$7606bd80$@augustcellars.com> <39135152-A5D8-48AB-B882-B29DCE5E3811@island-resort.com> <00d201d67333$d8449d30$88cdd790$@augustcellars.com> <1EEB1097-5E9E-4987-BA7B-29A71B3A120B@island-resort.com> In-Reply-To: <1EEB1097-5E9E-4987-BA7B-29A71B3A120B@island-resort.com> Date: Thu, 27 Aug 2020 15:18:59 -0700 Message-ID: <00c401d67cc0$11b18520$35148f60$@augustcellars.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00C5_01D67C85.6555E170" X-Mailer: Microsoft Outlook 16.0 Content-Language: en-us Thread-Index: AQEQxPObADvrQueaMVqePLeeIeR2QAJXtPJSAea5GecCGLJowAJ+XblxAdxq5xAB1lY1dwLytqwvqlweVpA= X-Originating-IP: [73.180.8.170] Archived-At: Subject: Re: [Ace] [COSE] Gap in registration of application/cwt? X-BeenThere: ace@ietf.org 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: Thu, 27 Aug 2020 22:19:20 -0000 ------=_NextPart_000_00C5_01D67C85.6555E170 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable =20 =20 From: Laurence Lundblade =20 Sent: Thursday, August 27, 2020 1:06 PM To: Jim Schaad Cc: Ace Wg ; cose Subject: Re: [Ace] [COSE] Gap in registration of application/cwt? =20 In a CBOR thread it became clear (to me anyway) that in the context of = CBOR a =E2=80=9Ctag" is not a prefix, badge, identifier or such. It is = the combination of the identifier and the content. In the CBOR context = when you say =E2=80=9Ctag 1=E2=80=9D or =E2=80=9Cepoch-based date = tag=E2=80=9D you mean the major type 6 and the number content. The = encoded CBOR for a tag 1 with value for Jan 1, 1970 would be 0xc1 0x00. =20 RFC 8392 uses the terminology incorrectly in section 5 = . It refers to the tag = as a prefix. Maybe errata should be filed on this? =20 [JLS] I would be fine with you filing an errata to this effect. It = would get marked, probably, as editorial not technical but that should = be fine. =20 Jim =20 =20 =20 Going back to the identification of a CWT and/or COSE, my understanding = is that a =E2=80=9CCWT=E2=80=9D is a protocol message. A =E2=80=9CCWT = Tag=E2=80=9D is a type 6 item value 61 and the CWT protocol message. = The definition of the CWT protocol message stands apart from the = definition of tag 61. (This is not true of a tag 1 epoch date; the = definition of the date is intwined with the definition of tag 1). =20 I believe the definition of the CWT protocol message allows the type of = COSE used to secure it to be identified in many ways. You can do it with = CBOR tags or you can do with externally such as my Application/CWT; = cose-type=3DCOSE_Sign1 content type example. =20 Further, I think nesting of COSE works as follows. It doesn=E2=80=99t = have to be identified with COSE tags. Several levels of COSE can be = required by some top level media type or even by some CBOR tag that is = not a COSE defined tag. For example, I could define = application/very-secure-string as follows. - Start with string of bytes - Encrypt it with COSE_Encrypt (the string of bytes is the payload) = (note that this is not COSE_Encrypt_Tagged) - Sign it COSE_Sign1 (the COSE_Encrypt is the payload) (note that this = is not COSE_Sign1_Tagged - Mac it with COSE_Mac0 (the COSE_Sign1 is the payload) (note that = this is not COSE_Mac0_Tagged) =20 I could make the payload at some level in this example some newly = defined tag that requires a COSE_Sign1 with EdDSA and indicates = something about its payload format. =20 LL =20 =20 =20 =20 On Aug 15, 2020, at 11:42 AM, Jim Schaad > wrote: =20 =20 =20 From: Laurence Lundblade >=20 Sent: Saturday, August 15, 2020 10:58 AM To: Jim Schaad > Cc: cose >; Ace Wg > Subject: Re: [Ace] [COSE] Gap in registration of application/cwt? =20 =20 On Aug 14, 2020, at 3:35 PM, Jim Schaad > wrote: =20 =20 =20 From: Laurence Lundblade >=20 Sent: Friday, August 14, 2020 1:59 PM To: Jim Schaad > Cc: Ace Wg >; cose > Subject: Re: [COSE] Gap in registration of application/cwt? =20 Here=E2=80=99s a series of scenarios that I think are legal CWT. These = are allowed by RFC 8392, right? =20 1) Explicitly tagged, no external type info needed - Has CWT tag - Has COSE type tag [JLS] Yes =20 2) CWT identification by label, COSE type tagged - The CWT is a CBOR data item with a label. The definition of the label = says the contents of the label are always CWT - No CWT tag necessary as it is implied by the label - Has a COSE type tag [JLS] Yes, the label could be internal to the CBOR object or external = such as an media-type =20 I was being very specific with the term label, meaning a label/key = identifying an item in a CBOR map. =20 3) CWT and COSE by label - The CWT is an item with a label. The definition of the label says the = contents of the label are always CWT and of a specific COSE type - No tags necessary [JLS] Yes that would be fine =20 4) Application/CWT identifies content as CWT, tagging for COSE type - No CWT tag - Has a COSE tag [JLS] This is the same as 2? I don=E2=80=99t think that it would be = restricted to just that media type. =20 You mean there could be other media types that also identify the content = as CWT? [JLS] Yes this could be done in the future. One would normally expect = this to be an application specific profile, but funny things happen. =20 5) Application/CWT identifies content as CWT - Has CWT tag even though it is redundant=20 - Has a COSE tag [JLS] Yes =20 Additionally, one might interpret CBORbis 4.2.2 to say the the CWT tag = should not be present. [JLS] For deterministic encoding, but not for general encoding. =20 6) Application/CWT; cose-type=3DCOSE_Sign1 (or Mac0 or =E2=80=A6) - No tags are used - Identification is completely by the MIME type header - (I understand that the cose-type MIME parameter is not defined, but it = could be. 8392 doesn=E2=80=99t forbid it) [JLS] Yes you could do that, and as I stated in a previous mail this is = not a good idea for the CoAP world. =20 7) A protocol like FIDO identifies a protocol element that is an = attention type the type of which is CWT with COSE_Sign1 - No tags are used [JLS] yes =20 8) A protocol like FIDO identifies a protocol element that is an = attention type the type of which is CWT; the COSE type is determined by = tag - No CWT tag - Has a COSE tag [JLS] yes =20 The one thing you can=E2=80=99t do is have a CWT tag without a COSE type = tag. 8392 section 6 forbids this. =20 [JLS] There however is a set of nested cases that you might need to look = at. That is 6.CWT ( COSE_Encrypt_Tagged ( COSE_Sign )) You would also = need to think about the requirements for nested COSE layers. =20 All but the most outer COSE type are always identified by a tag, per 7.1 = step 5 and 7.2 step 6, right? [JLS] Yes I guess that is true. I think my code is more generous that = this in terms of what is accepted. Jim =20 =20 LL =20 =20 Jim =20 =20 LL =20 =20 =20 =20 On Aug 11, 2020, at 12:20 PM, Laurence Lundblade > wrote: =20 =20 On Aug 10, 2020, at 5:49 PM, Jim Schaad > wrote: =20 This is all based on my understanding that the surrounding protocol for = must specify exactly when CBOR tags are to be used and when they are not = to be used and that the surrounding protocol must not leave it as an = optional implementation choice. In this case application/cwt is the = supporting protocol. =20 [JLS] What is the text that says that this is true. This would be a = surprising statement for me. =20 Here=E2=80=99s three things that lead me to this. =20 CBORbis The sentence of the first paragraph in 4.2.2 = = very clearly states this, though this is only for deterministic = encoding. =20 Typical CDDL Most CDDL that describes tagged data describes it only as tagged or = untagged, not as optionally tagged. COSE is one example of this.=20 =20 Email threads This thread = and this thread = . =20 I summarized this behavior in this email = = and no where in the rest of the thread was it indicated differently. =20 So, it is not a hard requirement because 4.2.2 is only for deterministic = encoding, but seems like a =E2=80=9Cshould" in spirit. It is the = preferred way to design a CBOR protocol. =20 However you slice it, I think it is up to the surrounding protocol to = say whether a tag is always required, never required or optionally = required. If the protocol doesn=E2=80=99t say, then it defaults to = optionally required. =20 Defaulting or explicitly allowing optional tagging means the receiver = has to allow for all the tagging scenarios and makes possible the error = case where the surrounding protocol says the data is of one type and the = tag conflicts with it. (e.g. an application/cwt that contains a tagged = CoSWID). =20 I don=E2=80=99t think optional tagging is of any advantage in a protocol = design. It doesn=E2=80=99t enable anything. =20 It has some disadvantage because it introduces error conditions and = potential confusion. =20 I think there are several scenarios with section 6 and application/cwt = that could be more clear. =20 Can you use tag 61 or not? I think the current answer is that in = application/cwt, tag 61 is optional. =20 How do you know what the COSE type is? It is somewhat obvious that COSE = tags will work, but there is no requirement to use them. A MIME = parameter or other is entirely allowed here. =20 Section 6 does say that determination that something is a CWT is = application dependent, but doesn=E2=80=99t say that the COSE type is = also application dependent. Section 7 does address this. =20 Said another way, my fully general CWT decoder that is called by some = application needs an input parameter to indicate the COSE type because = there is no requirement in 8392 that a CWT indicate which COSE type is = in use. Sometimes the caller will be able to provide the COSE type and = sometimes they won=E2=80=99t. Sometimes there will be an error of = conflicting COSE type and sometimes the error will be that the COSE type = can=E2=80=99t be determined. =20 I think it would have been cleanest if CWT always indicated the COSE = type be used and the tagging optionality didn=E2=80=99t span two = protocol layers, but that would be an incompatible change. Maybe a = recommendation that CWT=E2=80=99s SHOULD always indicate their COSE = type? =20 LL =20 _______________________________________________ Ace mailing list Ace@ietf.org = https://www.ietf.org/mailman/listinfo/ace =20 _______________________________________________ Ace mailing list Ace@ietf.org =20 https://www.ietf.org/mailman/listinfo/ace =20 ------=_NextPart_000_00C5_01D67C85.6555E170 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

 

 

From: Laurence Lundblade = <lgl@island-resort.com>
Sent: Thursday, August 27, 2020 = 1:06 PM
To: Jim Schaad = <ietf@augustcellars.com>
Cc: Ace Wg = <ace@ietf.org>; cose <cose@ietf.org>
Subject: Re: = [Ace] [COSE] Gap in registration of = application/cwt?

 

In a = CBOR thread it became clear (to me anyway) that in the context of CBOR a = =E2=80=9Ctag" is not a prefix, badge, identifier or such. It is the = combination of the identifier and the content. In the CBOR context when = you say =E2=80=9Ctag 1=E2=80=9D or =E2=80=9Cepoch-based date = tag=E2=80=9D you mean the major type 6 and the number content. =  The encoded CBOR for a tag 1 with value for Jan 1, 1970 would be = 0xc1 0x00.

 

RFC 8392 uses the terminology incorrectly in section 5. It = refers to the tag as a prefix. Maybe errata should be filed on = this?

 

[JLS] I would be fine with you filing an errata to = this effect.=C2=A0 It would get marked, probably, as editorial not = technical but that should be fine.

 

Jim

 

 

 

Going back to the identification of a CWT and/or COSE, = my understanding is that a =E2=80=9CCWT=E2=80=9D is a protocol message. = A =E2=80=9CCWT Tag=E2=80=9D is a type 6 item value 61 and the CWT = protocol message.  The definition of the CWT protocol message = stands apart from the definition of tag 61. (This is not true of a tag 1 = epoch date; the definition of the date is intwined with the definition = of tag 1).

 

I = believe the definition of the CWT protocol message allows the type of = COSE used to secure it to be identified in many ways. You can do it with = CBOR tags or you can do with externally such as my Application/CWT; = cose-type=3DCOSE_Sign1 content type example.

 

Further, I think nesting of COSE works as follows. It = doesn=E2=80=99t have to be identified with COSE tags. Several levels of = COSE can be required by some top level media type or even by some CBOR = tag that is not a COSE defined tag. For example, I could define = application/very-secure-string as follows.

  - Start with string of = bytes

  - Encrypt it = with COSE_Encrypt (the string of bytes is the payload) (note that this = is not COSE_Encrypt_Tagged)

  - Sign it COSE_Sign1 (the COSE_Encrypt is the = payload) (note that this is not COSE_Sign1_Tagged

<= div>

  - Mac = it with COSE_Mac0 (the COSE_Sign1 is the payload) (note = that this is not COSE_Mac0_Tagged)

 

I could make the payload at some level in this example = some newly defined tag that requires a COSE_Sign1 with EdDSA and = indicates something about its payload = format.

 

LL

 

 

 

 



On Aug 15, 2020, at 11:42 AM, Jim Schaad <ietf@augustcellars.com> = wrote:

 

 

 

From: Laurence Lundblade <lgl@island-resort.com> 
Sent: Saturday, August 15, 2020 = 10:58 AM
To: Jim Schaad <ietf@augustcellars.com>
= Cc: cose <cose@ietf.org>; Ace Wg <ace@ietf.org>
Subject: Re: [Ace] [COSE] Gap in = registration of application/cwt?

 

 




On Aug 14, 2020, at 3:35 PM, Jim Schaad <ietf@augustcellars.com> = wrote:

 

 

 

From: Laurence Lundblade <lgl@island-resort.com> 
Sent: Friday, August 14, 2020 1:59 = PM
To: Jim = Schaad <ietf@augustcellars.com>
= Cc: Ace Wg <ace@ietf.org>; cose <cose@ietf.org>
Subject: Re: [COSE] Gap in = registration of = application/cwt?

 

Here=E2=80=99s a series of scenarios that I think are = legal CWT. These are allowed by RFC 8392, = right?

 

<= p class=3DMsoNormal>1) Explicitly tagged, no external type info = needed

- Has CWT = tag

- Has COSE type = tag

[JLS] = Yes

 

<= p class=3DMsoNormal>2) CWT identification by label, COSE type = tagged

- The CWT is a CBOR data item with a label. The = definition of the label says the contents of the label are always = CWT

- No CWT tag necessary as it is implied by the = label

- Has a COSE type = tag

[JLS] Yes, = the label could be internal to the CBOR object or external such as an = media-type

<= p class=3DMsoNormal> 

I was being very specific with the term label, meaning = a label/key identifying an item in a CBOR = map.




 

<= p class=3DMsoNormal>3) CWT and COSE by = label

- The CWT is an item with a label. The definition of = the label says the contents of the label are always CWT and of a = specific COSE type

- No tags = necessary

[JLS] = Yes that would be fine

 

<= p class=3DMsoNormal>4) Application/CWT identifies content as CWT, = tagging for COSE type

- No CWT = tag

- Has a COSE = tag

[JLS] This = is the same as 2?  I don=E2=80=99t think that it would be = restricted to just that media = type.

 

You mean there could be other media types that also = identify the content as CWT?

[JLS] Yes this could be done in the future. =   One would normally expect this to be an application specific = profile, but funny things happen.

 

<= div>

5) Application/CWT identifies content as = CWT

- Has CWT tag even though it is = redundant 

- Has a COSE = tag

[JLS] = Yes

 

Additionally, one might interpret CBORbis 4.2.2 to say = the the CWT tag should not be present.

[JLS] For deterministic encoding, but not  for = general encoding.

 

<= p class=3DMsoNormal>6) Application/CWT; cose-type=3DCOSE_Sign1 (or Mac0 = or =E2=80=A6)

- No tags are = used

- Identification is completely by the MIME type = header

- (I understand that the cose-type MIME parameter is = not defined, but it could be. 8392 doesn=E2=80=99t forbid = it)

[JLS] Yes = you could do that, and as I stated in a previous mail this is not a good = idea for the CoAP = world.

 

<= p class=3DMsoNormal>7) A protocol like FIDO identifies a protocol = element that is an attention type the type of which is CWT with = COSE_Sign1

- No tags are = used

[JLS] = yes

 

<= div>

8) A protocol like FIDO identifies a protocol = element that is an attention type the type of which is CWT; the COSE = type is determined by = tag

- No CWT = tag

- Has a COSE = tag

[JLS] = yes

 

<= p class=3DMsoNormal>The one thing you can=E2=80=99t do is have a CWT tag = without a COSE type tag. 8392 section 6 forbids = this.

 

[JLS] There however is a set of nested cases that you = might need to look at.  That is 6.CWT ( COSE_Encrypt_Tagged ( = COSE_Sign ))  You would also need to think about the requirements = for nested COSE = layers.

 

All but the most outer COSE type are always identified = by a tag, per 7.1 step 5 and 7.2 step 6, = right?

[JLS] Yes I guess = that is true.  I think my code is more generous that this in terms = of what is accepted.

Jim

 

 

LL

 




 

Jim

 

<= p = class=3DMsoNormal> 

<= p class=3DMsoNormal>LL

 

<= p = class=3DMsoNormal> 

<= p class=3DMsoNormal> 

 





On Aug 11, 2020, at 12:20 PM, Laurence Lundblade = <lgl@island-resort.com> = wrote:

 

 





On Aug 10, 2020, at 5:49 PM, Jim Schaad <ietf@augustcellars.com> = wrote:

 

This is all based on my understanding that the = surrounding protocol for must specify exactly when CBOR tags are to be = used and when they are not to be used and that the surrounding protocol = must not leave it as an optional implementation choice. In this case = application/cwt is the supporting = protocol.

 

<= p class=3DMsoNormal>[JLS] What is the text that says that this is = true.  This would be a surprising statement for = me.

 

Here=E2=80=99s three things that lead me to = this.

 

CBORbis

The sentence of the first paragraph = in 4.2.2 very clearly states this, though this is only for = deterministic = encoding.

 

<= p class=3DMsoNormal>Typical = CDDL

Most CDDL that describes tagged data describes it only = as tagged or untagged, not as optionally tagged.  COSE is one = example of this. 

 

<= p class=3DMsoNormal>Email = threads

 

<= p class=3DMsoNormal>I summarized this behavior in this email and no where in the rest of the thread was it = indicated differently.

 

So, it is not a hard requirement because = 4.2.2 is only for deterministic encoding, but seems like a = =E2=80=9Cshould" in spirit. It is the preferred way to design a = CBOR protocol.

 

<= p class=3DMsoNormal>However you slice it, I think it is up to the = surrounding protocol to say whether a tag is always required, never = required or optionally required. If the protocol doesn=E2=80=99t say, = then it defaults to optionally = required.

 

<= p class=3DMsoNormal>Defaulting or explicitly allowing optional tagging = means the receiver has to allow for all the tagging scenarios and makes = possible the error case where the surrounding protocol says the data is = of one type and the tag conflicts with it. (e.g. an application/cwt that = contains a tagged = CoSWID).

 

<= p class=3DMsoNormal>I don=E2=80=99t think optional tagging is of any = advantage in a protocol design. It doesn=E2=80=99t enable = anything.

 

<= p class=3DMsoNormal>It has some disadvantage because it introduces error = conditions and potential = confusion.

 

<= p class=3DMsoNormal>I think there are several scenarios with section 6 = and application/cwt that could be more = clear.

 

Can you use tag 61 or not? = I think the current answer is that in application/cwt, tag 61 is = optional.

 

<= p class=3DMsoNormal>How do you know what the COSE type is? It is = somewhat obvious that COSE tags will work, but there is no requirement = to use them. A MIME parameter or other is entirely allowed = here.

 

<= p class=3DMsoNormal>Section 6 does say that determination that something = is a CWT is application dependent, but doesn=E2=80=99t say that the COSE = type is also application dependent. Section 7 does address = this.

 

<= p class=3DMsoNormal>Said another way, my fully general CWT decoder that = is called by some application needs an input parameter to indicate the = COSE type because there is no requirement in 8392 that a CWT indicate = which COSE type is in use. Sometimes the caller will be able to provide = the COSE type and sometimes they won=E2=80=99t. Sometimes there will be = an error of conflicting COSE type and sometimes the error will be that = the COSE type can=E2=80=99t be = determined.

 

<= p class=3DMsoNormal>I think it would have been cleanest if CWT always = indicated the COSE type be used and the tagging optionality = didn=E2=80=99t span two protocol layers, but that would be an = incompatible change.  Maybe a recommendation that CWT=E2=80=99s = SHOULD always indicate their COSE = type?

 

<= p = class=3DMsoNormal>LL

 

____________= ___________________________________
Ace mailing list
Ace@ietf.org=
<= a href=3D"https://www.ietf.org/mailman/listinfo/ace">https://www.= ietf.org/mailman/listinfo/ace

 

____________= ___________________________________
Ace mailing list
Ace@ietf.org
https://www.ietf.org/m= ailman/listinfo/ace

 

------=_NextPart_000_00C5_01D67C85.6555E170-- From nobody Mon Aug 31 05:53:26 2020 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B96F3A134A; Mon, 31 Aug 2020 05:53:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.102 X-Spam-Level: X-Spam-Status: No, score=-2.102 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.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 XaZ2mQBPNiUM; Mon, 31 Aug 2020 05:53:23 -0700 (PDT) Received: from EUR02-VE1-obe.outbound.protection.outlook.com (mail-eopbgr20068.outbound.protection.outlook.com [40.107.2.68]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A775A3A1349; Mon, 31 Aug 2020 05:53:22 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=cQLnwdfJQnIYSdj0f/Ymq52LFvDoIT+I/lr7r02PoULonxS042XT7BNyNW4jXLqOfoRukcG0ujPfYfPOrXFLhz+zCPQ4jxBNISCKbwE4/zwoZ8Q+8sH4a8GJ1VNhDkArV0OMCYEJM37SMURWl4XyYYxzE35bNJ7B36PWxEjuPfsdaaNUQjWaE9O8STkm/YhHlq6Dow9WlfVgEGHE9hUEcQoNlE8hMp7FGVR+ZYDmhwI6yDyGTwVawJRjXhmUzoAHV6GuwEueaTOLNUZOHsWnWPNHgwPUupHplJ/JHeQDiTR0G2fVk9qBukV2CdZTfm0rNlj+TYDFUb1LBOxPeJyEdg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=2hiKDnrmoHdCHna1OjhEYmR2X4OqBQfUeLHx5BURLXQ=; b=l33oUQJte5XS+LkW6w/LjX+pxO8BiMFlekibZpw06o+tFEk74GJwzBFed+mvvTPoiBKE1mmrYMhe5liG5q2OJHgqdhbnokU8s5WX2Bjfjn20FvtYfMEJp7CO7p3oBSA6GXkfjgmlMTI2RSgfkJjWn8/Jj6ijrrwEdKbTr7vFLu+blx1eKnz6bTIa6KgB4wSVa6Dz96/8G3uvlfmbeOX04/qbPa4N1CNHblAWIsOs3D1PTQ59WwifA/6G6bjFm99ECVU4Tu8cdbyN6DOoStskDxWBq5e2tq8rqrTLk1pEb4NRiRMKSRcVTdTND2xWk3+5WPxKwsDNgVXY2FRapyQe3g== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=2hiKDnrmoHdCHna1OjhEYmR2X4OqBQfUeLHx5BURLXQ=; b=NQ2aIL8/puAJkWlMfCSnzJoNYI45Hwvq13qDdahFNrtVIQ+lCw242Fa0UbwBftF+Ri476YrdfSfCPRVhuDYFsTk+ZGL1Sila2V+8p+WYZVYop8QqA8BR0/xW4wpJ4Xqis4yAfskCvpdF+n/fAtuQf1n54ZiItSuzIL9N3Xp5N0M= Received: from VI1PR07MB4477.eurprd07.prod.outlook.com (2603:10a6:803:74::33) by VI1PR0701MB6765.eurprd07.prod.outlook.com (2603:10a6:800:192::7) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3348.5; Mon, 31 Aug 2020 12:53:20 +0000 Received: from VI1PR07MB4477.eurprd07.prod.outlook.com ([fe80::cba:ac03:353c:2d1f]) by VI1PR07MB4477.eurprd07.prod.outlook.com ([fe80::cba:ac03:353c:2d1f%7]) with mapi id 15.20.3348.013; Mon, 31 Aug 2020 12:53:20 +0000 From: Francesca Palombini To: Ace Wg CC: "ace-chairs@ietf.org" Thread-Topic: OSCORE Profile IANA questions Thread-Index: AQHWf5W01luwmoZHhU++qk7AvzRo4Q== Date: Mon, 31 Aug 2020 12:53:20 +0000 Message-ID: <40F43BA8-1127-4066-8A5E-6929F962B052@ericsson.com> Accept-Language: en-GB, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.40.20081000 authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=ericsson.com; x-originating-ip: [158.174.219.143] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 2f93b18b-dd6f-42d7-224a-08d84dacd6b1 x-ms-traffictypediagnostic: VI1PR0701MB6765: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: IxHGUnK0E7fJGtj25z+Q6soIvsROFGBhkDmc2Dh102lDbtF036bQYIBk+IoDD2O2gqnfAxKXyoPw7kNJ0ti1yw/AYMuMkKZC8l4W45TDW5WyJBVz7bFt0rYWiLPLCmcEbWAeizXJFxW87dZdtYXf5lZfDehLCB7NpeFBfi1wHZsXSk1qCNGUWhdyb5pCqz508Qo+Fre+NUG+B/AwuCGaLX6L/o8G2azfPp2rGq+saruUnFTAqUBhESvab468X9ZnngGLHHKszqHu6zOor8y2VEhh+Yd20OodcPUYPZJr+ycLUrqHxrxAbQP/x8sUvHlYCWbmHC6logzkkuD49VnCPbGaDyoPahAZgt5/xf+LL58n61Q93MjXz8v1eLyckGKuOMoYWAYmZkzBrgzuO9OjyG+K59/JhKkdPC96a9FHpPRD+m9KMKyRjZb5YzXeOPClE7S3Gkp3tEkl7fhkJoK7Nq6gYgLcwDZHiDMXmLNcvcg= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:VI1PR07MB4477.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(39860400002)(396003)(366004)(376002)(346002)(136003)(66946007)(8676002)(66556008)(64756008)(66476007)(2906002)(36756003)(66446008)(2616005)(4326008)(26005)(71200400001)(478600001)(186003)(450100002)(966005)(316002)(76116006)(33656002)(83380400001)(6512007)(44832011)(91956017)(6506007)(86362001)(5660300002)(3480700007)(6486002)(8936002)(6916009); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: ow6asz1eQNHm7pcfb+o2q9UOhoMxGj93IBRMuHXMyvVMSOaMcRWmgrCzCukeTjNAZJ9seuiWagvp5T/ZF7MxEDe7OgC0CHWGJkliZnHwegzoNqFbq2E4eKZ1T2yKaqykTQoVImXkACtuOaFRdQzo0v1X/LTr6K3zKmEHTuAEmDUHBOQUPJ1x2vJ4wk5l18RrsE+Ln6io4M/boLPW0TuMOc/w9JNP+1Vvq0gxQXvfM/F6dhTfL6nchqiFynas4JyUlXAaS+TCZ3hgKqo6tc0oItwEW69PcS6ar1QGsyf5bdg6vW3cbFy3aUmcIkITBDqq6q0wWTPqsDYUyobQCN/qPKLK/Rtpq1sUggNkEcD/5DXgy9YYxDgSR6DO18P8Kko9qNfNqxcpbaj+NJsw9XO8dRyiyquXO3LSdQo59DnLDRIJzFX0kT5PS89r0XQx3NrxHAjYhEOBKdFm9SZkRgng9zmVqH1czrMje/7eX7sGb9rNaKVIQNyjEaaTQsbk/bTokmm0bWHqo3t6DGKep+uU1nFZ+h3HeynS+Zmu3KVx3QC5LbLot4QP8IEDnc2Vz8kBRnNTDP0RbPS3OQ8bR4HyPtkQBzS95QzbuVDyTTRmSAo7oawH670/vMQZT06gWNfgrawXuIAFsvxw2l0gLnKldA== x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-ID: <73045E1659E48E4883170D0CC6AC451B@eurprd07.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: VI1PR07MB4477.eurprd07.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 2f93b18b-dd6f-42d7-224a-08d84dacd6b1 X-MS-Exchange-CrossTenant-originalarrivaltime: 31 Aug 2020 12:53:20.3602 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: fXMwMCJzbdsEa8C1n3jlRpzAJE9+zc2tVBPTxbmDpzb+z0uEM84fBJQJUuEScrPpFd/bhDedaAbCKotqN4G2i1hH8gd3gKKd6yNG3u8jwdafkc8KscNO3Fi8EwFLJ/Ny X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR0701MB6765 Archived-At: Subject: [Ace] OSCORE Profile IANA questions X-BeenThere: ace@ietf.org 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, 31 Aug 2020 12:53:25 -0000 SGkgYWxsLA0KDQpJIGhhdmUgdHdvIHF1aWNrIHF1ZXN0aW9ucyBjb25jZXJuaW5nIElBTkEgYWN0 aW9ucyB0byBiZSBkb25lIGZvciB0aGUgT1NDT1JFIHByb2ZpbGU6DQoNCjEpIFRoZSBmcmFtZXdv cmsgKC1wYXJhbXMpIGFuZCB0aGUgcHJvZmlsZSBhcmUgY3VycmVudGx5IGNvbmZsaWN0aW5nIG9u IHRoZSByZWdpc3RyYXRpb24gb2YgcGFyYW1ldGVycywgYW5kIHdlIG5lZWQgdG8gZml4IHRoYXQu DQpJbiB0aGUgZnJhbWV3b3JrLCBwYXJhbWV0ZXJzIHRoYXQgYXJlIHNlbnQgZnJvbSBDbGllbnQg dG8gQVMgKHN1Y2ggYXMgcmVxX2NuZikgYXJlIHJlZ2lzdGVyZWQgaW4gdGhlIE9BdXRoIFBhcmFt ZXRlcnMgUmVnaXN0cnkgYXMgaGF2aW5nICJQYXJhbWV0ZXIgVXNhZ2UgTG9jYXRpb246IHRva2Vu IHJlcXVlc3QiLiBUaGUgT1NDT1JFIHByb2ZpbGUgcmVnaXN0ZXJzIHBhcmFtZXRlcnMgc2VudCBm cm9tIENsaWVudCB0byBSUyAoc3VjaCBhcyBub25jZTEpIHdpdGggIlBhcmFtZXRlciBVc2FnZSBM b2NhdGlvbjogdG9rZW4gcmVxdWVzdCIuIFRoZSBwb3NzaWJsZSAiUGFyYW1ldGVyIFVzYWdlIExv Y2F0aW9uIiBhcmUgInRva2VuIHJlcXVlc3QiICJ0b2tlbiByZXNwb25zZSIgImF1dGhvcml6YXRp b24gcmVxdWVzdCIgImF1dGhvcml6YXRpb24gcmVzcG9uc2UiIChzZWUgaHR0cHM6Ly90b29scy5p ZXRmLm9yZy9odG1sL3JmYzY3NDkjc2VjdGlvbi0xMS4yLjEgKS4gSXQgc2VlbXMgdGhhdCAiYXV0 aG9yaXphdGlvbiByZXF1ZXN0L3Jlc3BvbnNlIiBhcmUgdG8gdGhlIFJlc291cmNlIE93bmVyLCBh bmQgInRva2VuIHJlcXVlc3QvcmVzcG9uc2UiIGFyZSB0byB0aGUgQXV0aG9yaXphdGlvbiBTZXJ2 ZXIuIEkgdGhpbmsgdGhlIGZyYW1ld29yayBpcyB1c2luZyB0aGUgcmlnaHQgbmFtZXMsIGJ1dCBJ IGFtIG5vdCBzdXJlIHdoYXQgb3RoZXIgbG9jYXRpb24gdG8gcHV0IHRoZXJlLCBJIHRoaW5rIHRo ZXJlIGlzIG5vIG5hbWUgZm9yIENsaWVudC10by1SUyBhbmQgUlMtdG8tQ2xpZW50IGluIHRoZSBy ZWdpc3RyeSByaWdodCBub3cuDQoNCjIpIFRoZSBPU0NPUkUgcHJvZmlsZSBkZWZpbmVzIGEgbmV3 IHJlZ2lzdHJ5LCB0aGUgT1NDT1JFIFNlY3VyaXR5IENvbnRleHQgUGFyYW1ldGVycyByZWdpc3Ry eS4gVGhlIHF1ZXN0aW9uIGlzIHdoZXJlIHRvIHB1dCB0aGlzIHJlZ2lzdHJ5PyBNeSBwcm9wb3Nh bCBpcyB0byBwdXQgaXQgdW5kZXIgaHR0cHM6Ly93d3cuaWFuYS5vcmcvYXNzaWdubWVudHMvY29y ZS1wYXJhbWV0ZXJzL2NvcmUtcGFyYW1ldGVycy54aHRtbCAuIEFueSBvYmplY3Rpb25zPw0KDQpU aGFua3MsDQpGcmFuY2VzY2ENCg0K From nobody Mon Aug 31 06:42:49 2020 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B42723A13C0; Mon, 31 Aug 2020 06:42:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham 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 FD0uuHzbhfWi; Mon, 31 Aug 2020 06:42:46 -0700 (PDT) Received: from weald.air.saab.se (weald.air.saab.se [136.163.212.3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CD20E3A13B5; Mon, 31 Aug 2020 06:42:44 -0700 (PDT) Received: from mailhub2.air.saab.se ([136.163.213.5]) by weald.air.saab.se (8.14.4/8.14.4) with ESMTP id 07VDggwA015552 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 31 Aug 2020 15:42:42 +0200 DKIM-Filter: OpenDKIM Filter v2.11.0 weald.air.saab.se 07VDggwA015552 Received: from corpappl16594.corp.saab.se (corpappl16594.corp.saab.se [10.12.12.126]) by mailhub2.air.saab.se (8.13.8/8.13.8) with ESMTP id 07VDgS0T007375 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 31 Aug 2020 15:42:28 +0200 Received: from corpappl16595.corp.saab.se (10.12.12.127) by corpappl16594.corp.saab.se (10.12.12.126) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1979.3; Mon, 31 Aug 2020 15:42:28 +0200 Received: from corpappl16595.corp.saab.se ([fe80::3c3e:6470:4c56:a86f]) by corpappl16595.corp.saab.se ([fe80::3c3e:6470:4c56:a86f%4]) with mapi id 15.01.1979.003; Mon, 31 Aug 2020 15:42:28 +0200 From: Seitz Ludwig To: Francesca Palombini , Ace Wg CC: "ace-chairs@ietf.org" Thread-Topic: OSCORE Profile IANA questions Thread-Index: AQHWf5W01luwmoZHhU++qk7AvzRo4alSOI+g Date: Mon, 31 Aug 2020 13:42:27 +0000 Message-ID: <3547a70f710c48c1b84cd70b70e0e873@combitech.se> References: <40F43BA8-1127-4066-8A5E-6929F962B052@ericsson.com> In-Reply-To: <40F43BA8-1127-4066-8A5E-6929F962B052@ericsson.com> Accept-Language: en-SE, sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.12.13.198] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Saab-MailScanner-Information: Please contact the ISP for more information X-Saab-MailScanner-ID: 07VDgS0T007375 X-Saab-MailScanner: Found to be clean X-Saab-MailScanner-SpamCheck: not spam, SpamAssassin (not cached, score=-0.999, required 5, autolearn=not spam, ALL_TRUSTED -1.00, URIBL_BLOCKED 0.00) X-Saab-MailScanner-From: ludwig.seitz@combitech.se X-Saab-MailScanner-Watermark: 1599486148.87916@ycP8mkh7Cl55TlcBToHFuQ X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.6.2 (weald.air.saab.se [136.163.212.3]); Mon, 31 Aug 2020 15:42:42 +0200 (CEST) Archived-At: Subject: Re: [Ace] OSCORE Profile IANA questions X-BeenThere: ace@ietf.org 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, 31 Aug 2020 13:42:49 -0000 1.) I would not put these parameters in the "token request" category, they = belong into a new category. Whether they should be registered in the OAuth = parameters registry is doubtful to me, since I don't see them being used in= a non-ACE OAuth context. Somewhere in the ACE registries? 2.) I would propose to put it on ACE page to be created for the framework = by IANA. /Ludwig -----Original Message----- From: Ace On Behalf Of Francesca Palombini Sent: den 31 augusti 2020 14:53 To: Ace Wg Cc: ace-chairs@ietf.org Subject: [Ace] OSCORE Profile IANA questions Hi all, I have two quick questions concerning IANA actions to be done for the OSCOR= E profile: 1) The framework (-params) and the profile are currently conflicting on the= registration of parameters, and we need to fix that. In the framework, parameters that are sent from Client to AS (such as req_c= nf) are registered in the OAuth Parameters Registry as having "Parameter Us= age Location: token request". The OSCORE profile registers parameters sent = from Client to RS (such as nonce1) with "Parameter Usage Location: token re= quest". The possible "Parameter Usage Location" are "token request" "token = response" "authorization request" "authorization response" (see https://too= ls.ietf.org/html/rfc6749#section-11.2.1 ). It seems that "authorization req= uest/response" are to the Resource Owner, and "token request/response" are = to the Authorization Server. I think the framework is using the right names= , but I am not sure what other location to put there, I think there is no n= ame for Client-to-RS and RS-to-Client in the registry right now. 2) The OSCORE profile defines a new registry, the OSCORE Security Context P= arameters registry. The question is where to put this registry? My proposal= is to put it under https://www.iana.org/assignments/core-parameters/core-p= arameters.xhtml . Any objections? Thanks, Francesca _______________________________________________ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace From nobody Mon Aug 31 08:29:17 2020 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A88703A1599; Mon, 31 Aug 2020 08:29:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham 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 W-H3jnUR_pvd; Mon, 31 Aug 2020 08:29:13 -0700 (PDT) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 65DC33A1590; Mon, 31 Aug 2020 08:29:06 -0700 (PDT) Received: from Jude (73.180.8.170) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Mon, 31 Aug 2020 08:28:59 -0700 From: Jim Schaad To: 'Francesca Palombini' , 'Ace Wg' CC: References: <40F43BA8-1127-4066-8A5E-6929F962B052@ericsson.com> In-Reply-To: <40F43BA8-1127-4066-8A5E-6929F962B052@ericsson.com> Date: Mon, 31 Aug 2020 08:28:56 -0700 Message-ID: <000001d67fab$72c88f50$5859adf0$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQGecxfGuFJKithljWgfhxIquG2lLqnCcIfQ Content-Language: en-us X-Originating-IP: [73.180.8.170] Archived-At: Subject: Re: [Ace] OSCORE Profile IANA questions X-BeenThere: ace@ietf.org 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, 31 Aug 2020 15:29:16 -0000 -----Original Message----- From: Francesca Palombini =20 Sent: Monday, August 31, 2020 5:53 AM To: Ace Wg Cc: ace-chairs@ietf.org Subject: OSCORE Profile IANA questions Hi all, I have two quick questions concerning IANA actions to be done for the = OSCORE profile: 1) The framework (-params) and the profile are currently conflicting on = the registration of parameters, and we need to fix that. In the framework, parameters that are sent from Client to AS (such as = req_cnf) are registered in the OAuth Parameters Registry as having = "Parameter Usage Location: token request". The OSCORE profile registers = parameters sent from Client to RS (such as nonce1) with "Parameter Usage = Location: token request". The possible "Parameter Usage Location" are = "token request" "token response" "authorization request" "authorization = response" (see https://tools.ietf.org/html/rfc6749#section-11.2.1 ). It = seems that "authorization request/response" are to the Resource Owner, = and "token request/response" are to the Authorization Server. I think = the framework is using the right names, but I am not sure what other = location to put there, I think there is no name for Client-to-RS and = RS-to-Client in the registry right now. [JLS] Look at the OAuth registries - they have some "standardized" names = for these interactions as well as the RS-AS pair. Jim 2) The OSCORE profile defines a new registry, the OSCORE Security = Context Parameters registry. The question is where to put this registry? = My proposal is to put it under = https://www.iana.org/assignments/core-parameters/core-parameters.xhtml . = Any objections? Thanks, Francesca