Re: [Cbor] draft-ietf-cbor-tags-oid-00.txt

worley@ariadne.com Mon, 03 August 2020 03:23 UTC

Return-Path: <worley@alum.mit.edu>
X-Original-To: cbor@ietfa.amsl.com
Delivered-To: cbor@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C6CB3A044A for <cbor@ietfa.amsl.com>; Sun, 2 Aug 2020 20:23:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.975
X-Spam-Level:
X-Spam-Status: No, score=0.975 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, SPF_HELO_NONE=0.001, SPF_SOFTFAIL=0.972, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=comcastmailservice.net
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 LmseEUE9QUEr for <cbor@ietfa.amsl.com>; Sun, 2 Aug 2020 20:23:31 -0700 (PDT)
Received: from resqmta-ch2-11v.sys.comcast.net (resqmta-ch2-11v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:43]) (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 81A933A043A for <cbor@ietf.org>; Sun, 2 Aug 2020 20:23:31 -0700 (PDT)
Received: from resomta-ch2-17v.sys.comcast.net ([69.252.207.113]) by resqmta-ch2-11v.sys.comcast.net with ESMTP id 2QyBkQQvTPdj92R4Ukr4mh; Mon, 03 Aug 2020 03:23:30 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcastmailservice.net; s=20180828_2048; t=1596425010; bh=xYuy2azE8PbT3i8aWqEzGBD6cH9yPvsUQEhqIVKuzvg=; h=Received:Received:Received:Received:From:To:Subject:Date: Message-ID; b=qrC6b1nwZDx1r+oyFD8JQjNC+2jDU89G3Rkaryj3NWSglVoT1t98yiqkFBvXY3Ftb d3zfdkmSoLqVXY+TKokJ3f1Qn2KQaE2trroz5gcvK+gM4auW4R417m5hXe7KNQtFie QQqtRmZ2tFwFNgwJnhmIPPfcDCqvT5PmJGpMpSRpVvSZRg9XBFXclHisrD/UtMhkeq EkVL6jczpr9UxF2aeUDFRamqXDym05FjvoIIn+/QnbAg/VLehkR/S8T3wRZI20fLrU EOwDaVGfLHltJkaoEa49aCpiaB5Dh66wSP5Kq0/2awp8NmUOO4v9XhF5PgMdyv4Juq rrnjLHQLn3Kvw==
Received: from hobgoblin.ariadne.com ([IPv6:2601:192:4a00:430:222:fbff:fe91:d396]) by resomta-ch2-17v.sys.comcast.net with ESMTPA id 2R4Skjtz1gljM2R4TkHkww; Mon, 03 Aug 2020 03:23:30 +0000
X-Xfinity-VMeta: sc=0.00;st=legit
Received: from hobgoblin.ariadne.com (hobgoblin.ariadne.com [127.0.0.1]) by hobgoblin.ariadne.com (8.14.7/8.14.7) with ESMTP id 0737NDA5025861 for <cbor@ietf.org>; Mon, 3 Aug 2020 03:23:13 -0400
Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id 0737NCfK025858; Mon, 3 Aug 2020 03:23:12 -0400
X-Authentication-Warning: hobgoblin.ariadne.com: worley set sender to worley@alum.mit.edu using -f
From: worley@ariadne.com
To: cbor@ietf.org
In-Reply-To: <18B0842C-B5B6-4F6D-B2F3-180A26B8F002@tzi.org> (cabo@tzi.org)
Sender: worley@ariadne.com
Date: Mon, 03 Aug 2020 03:23:12 -0400
Message-ID: <87v9i0w5un.fsf@hobgoblin.ariadne.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/cbor/5dYKkD2adz5Vhb2-SFxMOk0YKXc>
Subject: Re: [Cbor] draft-ietf-cbor-tags-oid-00.txt
X-BeenThere: cbor@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Concise Binary Object Representation \(CBOR\)" <cbor.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/cbor>, <mailto:cbor-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/cbor/>
List-Post: <mailto:cbor@ietf.org>
List-Help: <mailto:cbor-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/cbor>, <mailto:cbor-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 03 Aug 2020 03:23:35 -0000

Carsten Bormann <cabo@tzi.org> writes:
> (Crypto) keys don't have to be much longer, see
> https://tools.ietf.org/html/draft-mattsson-cose-cbor-cert-compress-01#appendix-A
> for a worked example.

I don't know elliptic-curve crypto well enough to follow that, but it
seems to me that you're going to have a hard time putting a 2048 bit key
in less than about 256 octets, and the signature will need a similar
number of octets.  So all overheads should be counted against a minimum
of 512 octets of essentially binary data.

From: Sean Leonard <dev+ietf@seantek.com> writes:
> The most authoritative dotted-decimal OID style definition that I could 
> find is in the LDAP specs, namely <numericoid> in RFC 4512.

There is an OID namespace for URNs which uses dotted-decimal syntax; the
first version is RFC 3001 (Apr 2000), which refers to RFC 1778 section
2.15 (Mar 1995).

Dale