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

Laurence Lundblade <lgl@island-resort.com> Thu, 29 October 2020 21:02 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 072313A0A6C for <rats@ietfa.amsl.com>; Thu, 29 Oct 2020 14:02:56 -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 rquDu-nf6jj5 for <rats@ietfa.amsl.com>; Thu, 29 Oct 2020 14:02:53 -0700 (PDT)
Received: from p3plsmtpa07-02.prod.phx3.secureserver.net (p3plsmtpa07-02.prod.phx3.secureserver.net [173.201.192.231]) (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 582BD3A0062 for <rats@ietf.org>; Thu, 29 Oct 2020 14:02:53 -0700 (PDT)
Received: from [192.168.1.81] ([76.167.193.86]) by :SMTPAUTH: with ESMTPA id YF4OkcqrkpwZiYF4OkUuri; Thu, 29 Oct 2020 14:02:52 -0700
X-CMAE-Analysis: v=2.4 cv=aop3tQVV c=1 sm=1 tr=0 ts=5f9b2dfc a=t2DvPg6iSvRzsOFYbaV4uQ==:117 a=t2DvPg6iSvRzsOFYbaV4uQ==:17 a=5KLPUuaC_9wA:10 a=gKmFwSsBAAAA:8 a=K6EGIJCdAAAA:8 a=48vgC7mUAAAA:8 a=BqEg4_3jAAAA:8 a=oGbIuagOAAAA:20 a=_sZlvxqxrPdw6Mc8mOQA:9 a=QEXdDO2ut3YA:10 a=WiFMg2hEW7gA:10 a=vBlvbjMb_ccA:10 a=JRYF3h_zhQEA:10 a=KFiGMKbQCqYA:10 a=ZrmZBiZdXJyb1JsyJGgA:9 a=w13D9S53jcP-wUdM:21 a=_W_S_7VecoQA:10 a=nnPW6aIcBuj1ljLj_o6Q:22 a=L6pVIi0Kn1GYQfi8-iRI:22 a=w1C3t2QeGrPiZgrLijVG:22 a=0mFWnFbQd5xWBqmg7tTt:22
X-SECURESERVER-ACCT: lgl@island-resort.com
From: Laurence Lundblade <lgl@island-resort.com>
Message-Id: <008CBA60-62C3-4B06-BC48-8BC159CD7A5D@island-resort.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_B87D7106-8CE7-4880-8FAE-F3AA4F8DC56F"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.17\))
Date: Thu, 29 Oct 2020 14:02:51 -0700
In-Reply-To: <3BBDCDD5-BEAC-4826-8D84-13814CF210C8@tzi.org>
Cc: "rats@ietf.org" <rats@ietf.org>, "draft-ietf-cbor-tags-oid@ietf.org" <draft-ietf-cbor-tags-oid@ietf.org>, "sacm@ietf.org" <sacm@ietf.org>, Francesca Palombini <francesca.palombini=40ericsson.com@dmarc.ietf.org>
To: Carsten Bormann <cabo@tzi.org>
References: <12027D40-562D-4859-8A3B-25551C5CBAC8@ericsson.com> <F835894B-8149-4884-AEFB-76EBD07DFB61@island-resort.com> <3BBDCDD5-BEAC-4826-8D84-13814CF210C8@tzi.org>
X-Mailer: Apple Mail (2.3445.104.17)
X-CMAE-Envelope: MS4xfH4abk+Lkigiu7Rm1BfmfgQolbkhYq0JUjpmt2EzrmijVyAK4dYFJAjrmHlMQ1gQwjmkDSi9WPWnDSbGqxMLjSAticsG08elYtYJQyXaMWx4k/HsNEyD mtxzm30R9jkgkPV6QRAT7PDm51AobH3YvZoll5DhXF7wZDWSrDAs/1C0JTvl2HQyhXFa6OpQWOkaao6eMV3TQy0dKrZQ5Y9BiCwcWdUB10Cj4GxoIvjBtqDk AOdjbWzQL5ZxOWSh/fDu9J1+ef8WPu4D8hv4VPvqWtYP1ZjaIklk9w0xTu7sfPMAYWZ+Uuz5y3nGwJJtLRr3+NZUxGeecuySdMqNB0hCVd8CVZviOIZ8yLOM iQiMVlC0
Archived-At: <https://mailarchive.ietf.org/arch/msg/rats/W0kv6POHOWe03SGUzvDqg6LPtSo>
Subject: Re: [Rats] [Cbor] 🔔 WGLC on draft-ietf-cbor-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: Thu, 29 Oct 2020 21:03:00 -0000

I see.

So if you are doing DN’s in CBOR this way, it’s kind “in for a penny, in for a pound” and you want to handle the mentioned example using what is described in section 5.

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.

Thanks

LL


> On Oct 29, 2020, at 1:25 PM, Carsten Bormann <cabo@tzi.org> wrote:
> 
> Hi Laurence,
> 
> On 2020-10-29, at 20:44, Laurence Lundblade <lgl@island-resort.com> wrote:
>> 
>> The question I have is whether there is any intent for these OIDs to be keys or labels in CBOR maps.
> 
> The way tag factoring (Section 5 [1]) works for maps was specifically meant to support this.
> 
>> In X.509/PKIX extensions are labeled by OIDs. Would there be similar use in CBOR?
> 
> Please see the example on page 8 [2] for such usage.
> 
>> Typically, CBOR map labels are integers and sometimes text strings. Having to pay attention to tags in map keys might be very inconvenient for some CBOR decoders, though that could be avoided in a given protocol by saying the map keys are byte strings that borrow tag 111 content eliminating the need for the tag.
> 
> That is of course also possible.
> 
> Which reminds me that we specify CDDL control operators, but not prelude-like conventional names for the types created by these tags (e.g., cf. [3]).  Now Issue 6 [4].
> 
> Grüße, Carsten
> 
> [1]: https://www.ietf.org/archive/id/draft-ietf-cbor-tags-oid-02.html#name-tag-factoring-with-oid-arra
> [2]: https://tools.ietf.org/html/draft-ietf-cbor-tags-oid-02#page-8
> [Yessss… :-)]
> [3]: https://www.rfc-editor.org/rfc/rfc8746.html#section-5
> [4]: https://github.com/cbor-wg/cbor-oid/issues/6
> _______________________________________________
> RATS mailing list
> RATS@ietf.org
> https://www.ietf.org/mailman/listinfo/rats