Re: [COSE] Structure of CBOR certificates

Russ Housley <housley@vigilsec.com> Mon, 27 July 2020 17:04 UTC

Return-Path: <housley@vigilsec.com>
X-Original-To: cose@ietfa.amsl.com
Delivered-To: cose@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 736D53A1A24 for <cose@ietfa.amsl.com>; Mon, 27 Jul 2020 10:04:21 -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, SPF_HELO_NONE=0.001, SPF_NONE=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 icEjWBYhpjfJ for <cose@ietfa.amsl.com>; Mon, 27 Jul 2020 10:04:19 -0700 (PDT)
Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 291143A0FA3 for <cose@ietf.org>; Mon, 27 Jul 2020 10:04:19 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 807C6300B81 for <cose@ietf.org>; Mon, 27 Jul 2020 13:04:16 -0400 (EDT)
X-Virus-Scanned: amavisd-new at mail.smeinc.net
Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id f3j1RUgr93iD for <cose@ietf.org>; Mon, 27 Jul 2020 13:04:14 -0400 (EDT)
Received: from a860b60074bd.fios-router.home (pool-72-66-113-56.washdc.fios.verizon.net [72.66.113.56]) by mail.smeinc.net (Postfix) with ESMTPSA id 6F098300B5A; Mon, 27 Jul 2020 13:04:14 -0400 (EDT)
From: Russ Housley <housley@vigilsec.com>
Message-Id: <398A4546-4305-4935-BA00-0C9420774359@vigilsec.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_3BAD8B9D-8101-469A-AD2F-8436C6C94547"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.15\))
Date: Mon, 27 Jul 2020 13:04:15 -0400
In-Reply-To: <CAHszGEJnyWpx0joVSM5x5-6WrS3cG6X1ni_2tdHs-kg2ThBv4A@mail.gmail.com>
Cc: Ilari Liusvaara <ilariliusvaara@welho.com>, cose@ietf.org
To: Joel Höglund <joel.hoglund@gmail.com>
References: <4fbee615-6d6f-700f-2439-237add7fbcf2@sit.fraunhofer.de> <CAHszGE+A=e9tdBZpa51wMasxm1AhA_xRbAUCmR55xXSJgtF7Lg@mail.gmail.com> <20200710125843.GA224527@LK-Perkele-VII> <CAHszGELkqDzL8n1FWOmLiTQh1jxS7EZKNZCqX89PEFoisHXPmg@mail.gmail.com> <20200721115009.GB464556@LK-Perkele-VII> <C58E33A1-6D18-4D9F-9B96-7249C23E4379@vigilsec.com> <CAHszGEJnyWpx0joVSM5x5-6WrS3cG6X1ni_2tdHs-kg2ThBv4A@mail.gmail.com>
X-Mailer: Apple Mail (2.3445.104.15)
Archived-At: <https://mailarchive.ietf.org/arch/msg/cose/UwLstOyPmioNNZAnxvXoU1g8PS8>
Subject: Re: [COSE] Structure of CBOR certificates
X-BeenThere: cose@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: CBOR Object Signing and Encryption <cose.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/cose>, <mailto:cose-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/cose/>
List-Post: <mailto:cose@ietf.org>
List-Help: <mailto:cose-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/cose>, <mailto:cose-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 27 Jul 2020 17:04:22 -0000


> On Jul 27, 2020, at 12:09 PM, Joel Höglund <joel.hoglund@gmail.com> wrote:
> 
> A follow-up question below:
> 
> >   4 bits is not sufficient to represent non-empty ordered subsets
> >   of 4 elements. One needs at least 6 bits for that.
> > 
> >   However, one could fit the thing in 4 bits by noting that combining
> >   id-kp-OCSPSigning with anything else is Bad Idea. And non-empty
> >   ordered subset of mutually exclusive sets of 3+1 elements does
> >   fit in 4 bits (A, B, C, AB, AC, BA, BC, CA, CB, ABC, ACB, BAC, BCA,
> >   CAB, CBA, Z).
> 
> Yes, a SET OF would have defined an order, but it does not help the relying party, who only cares about whether a particular OID is in the SEQUENCE or not.
> 
> Putting them in the same order as SET OF would work for new certificates, but it will not help with existing ones.
> 
> 
> We read Ilari's proposal as a way to uniquely order the relevant EKU combinations, in which case the encoding would work with both existing and new certificates. Can you please clarify which situation you are referring to?

The ASN.1 DER encoding of SET OF specifies the order.  The encoding of SEQUENCE OF allows the sender to pick the order.  I suggest we not pick another ordering.

Russ