Re: [Rats] [Cbor] 🔔 WGLC on draft-ietf-cbor-tags-oid-02

Laurence Lundblade <lgl@island-resort.com> Mon, 02 November 2020 19:03 UTC

Return-Path: <lgl@island-resort.com>
X-Original-To: rats@ietfa.amsl.com
Delivered-To: rats@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 095C83A0AC1 for <rats@ietfa.amsl.com>; Mon, 2 Nov 2020 11:03:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.895
X-Spam-Level:
X-Spam-Status: No, score=-1.895 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 A0wY3lmGaEQp for <rats@ietfa.amsl.com>; Mon, 2 Nov 2020 11:03:34 -0800 (PST)
Received: from p3plsmtpa09-05.prod.phx3.secureserver.net (p3plsmtpa09-05.prod.phx3.secureserver.net [173.201.193.234]) (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 3904D3A0AAF for <rats@ietf.org>; Mon, 2 Nov 2020 11:03:34 -0800 (PST)
Received: from [192.168.1.81] ([76.167.193.86]) by :SMTPAUTH: with ESMTPA id Zf4wkeMJEdbL2Zf4wk0Pbd; Mon, 02 Nov 2020 12:01:19 -0700
X-CMAE-Analysis: v=2.4 cv=IJPHtijG c=1 sm=1 tr=0 ts=5fa0577f a=t2DvPg6iSvRzsOFYbaV4uQ==:117 a=t2DvPg6iSvRzsOFYbaV4uQ==:17 a=IkcTkHD0fZMA:10 a=5KLPUuaC_9wA:10 a=gKmFwSsBAAAA:8 a=rswtVFESZHRFf59x9wwA:9 a=RKswsgigV1WoH85D:21 a=K3r_0QX-1iJZ8ISP:21 a=QEXdDO2ut3YA:10 a=nnPW6aIcBuj1ljLj_o6Q:22
X-SECURESERVER-ACCT: lgl@island-resort.com
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.17\))
From: Laurence Lundblade <lgl@island-resort.com>
In-Reply-To: <12FDAD94-4378-42C4-8054-B5A135043636@tzi.org>
Date: Mon, 2 Nov 2020 11:01:18 -0800
Cc: "rats@ietf.org" <rats@ietf.org>, Francesca Palombini <francesca.palombini=40ericsson.com@dmarc.ietf.org>, "sacm@ietf.org" <sacm@ietf.org>, "draft-ietf-cbor-tags-oid@ietf.org" <draft-ietf-cbor-tags-oid@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <5B4766CE-E79C-4035-BF93-9C38336AA143@island-resort.com>
References: <12027D40-562D-4859-8A3B-25551C5CBAC8@ericsson.com> <F835894B-8149-4884-AEFB-76EBD07DFB61@island-resort.com> <3BBDCDD5-BEAC-4826-8D84-13814CF210C8@tzi.org> <008CBA60-62C3-4B06-BC48-8BC159CD7A5D@island-resort.com> <12FDAD94-4378-42C4-8054-B5A135043636@tzi.org>
To: Carsten Bormann <cabo@tzi.org>
X-Mailer: Apple Mail (2.3445.104.17)
X-CMAE-Envelope: MS4xfHNPfFRi3MnRYND1QgfsH1Ftrl21eX1sIg+1vjFFE2mRaU2Zdo5fjiDOzoj1MjbMEP82CMcAfNNx1qE1WpysGdej3wmHqYKyF/xfYTROz073TQEkOhaP qemLQ6jOUkddxCfT/SrPw7Dl9Ya7O7urWOKm2imLvjNjj7qXhSqAwiz4E5RKhb7MVafNuy/4M8kuFvA12FwQPm+pdyHSODEgle1+YTtDvUVJ7xTa1yKpsjlG 9IqVE/CfLN6iGsvis2mlFdARBktlHYZLyQSM+FfsgZiuhy8aPLbl9CfXTHx4Wbd+3sxF/XGYAomwKFNCCAD294QJ9bJKjdLT7G6gbZE9q2CY23cYIY+Tp47H 5QRnBhav
Archived-At: <https://mailarchive.ietf.org/arch/msg/rats/_2UgFKW3lpwoGOFXI0nXiC2ju78>
Subject: Re: [Rats] =?utf-8?q?=5BCbor=5D_=F0=9F=94=94_WGLC_on_draft-ietf-cbor?= =?utf-8?q?-tags-oid-02?=
X-BeenThere: rats@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Remote ATtestation procedureS <rats.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rats>, <mailto:rats-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rats/>
List-Post: <mailto:rats@ietf.org>
List-Help: <mailto:rats-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rats>, <mailto:rats-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 02 Nov 2020 19:03:35 -0000

> On Oct 31, 2020, at 1:36 PM, Carsten Bormann <cabo@tzi.org> wrote:
> 
>> 
>> CWT seems a little ambiguous as to whether thusly encoded OIDs are allowed as a label/key. Section 3 says:
>> 
>>   To keep CWTs as small as possible, the Claim Keys are represented
>>   using integers or text strings.
>> 
>> 
>> This seems more of a statement of design intent rather than a prohibition against other types of Claim Keys, but one could interpret it as a prohibition.
> 
> It is neither: It is a statement of fact.
> The dual of this statement is:
> If the label (map key) is not an integer or a text string, this label is not a Claim Key.
> (And, since Claims use Claim Keys, the key/value pair is not a Claim, and ... the whole thing is not a CWT.)

This the interpretation I was thinking of when I used the word prohibition. I am glad for this as it keeps the implementation I’m working on  lot simpler.

The upshot is two things:

   1) No one can define, register, or standardize a Claim Key that is not an integer or text string

   2) CWT decoder/verifiers should error out if they encounter a Claim Key that is not an integer or text string

LL