[Ace] draft-raza-ace-cbor-certificates-04.txt

Laurence Lundblade <lgl@island-resort.com> Wed, 22 April 2020 15:23 UTC

Return-Path: <lgl@island-resort.com>
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 078A83A0E82 for <ace@ietfa.amsl.com>; Wed, 22 Apr 2020 08:23:15 -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, 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 feTcMsfnHRk4 for <ace@ietfa.amsl.com>; Wed, 22 Apr 2020 08:23:13 -0700 (PDT)
Received: from p3plsmtpa12-04.prod.phx3.secureserver.net (p3plsmtpa12-04.prod.phx3.secureserver.net [68.178.252.233]) (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 9DDDE3A0E7F for <ace@ietf.org>; Wed, 22 Apr 2020 08:23:13 -0700 (PDT)
Received: from [192.168.1.78] ([76.167.193.86]) by :SMTPAUTH: with ESMTPA id RHDUjCnJxaTvaRHDVjsdok; Wed, 22 Apr 2020 08:23:13 -0700
X-CMAE-Analysis: v=2.3 cv=YYnDGDZf c=1 sm=1 tr=0 a=t2DvPg6iSvRzsOFYbaV4uQ==:117 a=t2DvPg6iSvRzsOFYbaV4uQ==:17 a=ZbKh0HJnzUMA:10 a=IkcTkHD0fZMA:10 a=H_2F2HXJbL2iPrxgAqoA:9 a=QEXdDO2ut3YA:10 a=Z5ABNNGmrOfJ6cZ5bIyy:22 a=jd6J4Gguk5HxikPWLKER:22
X-SECURESERVER-ACCT: lgl@island-resort.com
From: Laurence Lundblade <lgl@island-resort.com>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
Message-Id: <44737D23-ADDF-4F43-8C68-B898C06DBD69@island-resort.com>
Date: Wed, 22 Apr 2020 08:23:12 -0700
To: Ace Wg <ace@ietf.org>
X-Mailer: Apple Mail (2.3445.104.11)
X-CMAE-Envelope: MS4wfFHgWumhipfJNzOWZSYDVpWenmslk52np0b6UKeql4oeJoryazGV1b2ZpCsqzpS5Wzq4YXZMC57ck5wAUY8O9A1T+VXj+UJkkMdCTQIWjzoFPewFBuUM OJPXffF9fmuuNrWcvu2OxLXW1ChcvvPXrczD5dgq3L3qoIP3ODzavOGC
Archived-At: <https://mailarchive.ietf.org/arch/msg/ace/OqpzBchUxTTE_WOutKLtIh2c82c>
Subject: [Ace] draft-raza-ace-cbor-certificates-04.txt
X-BeenThere: ace@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" <ace.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ace>, <mailto:ace-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ace/>
List-Post: <mailto:ace@ietf.org>
List-Help: <mailto:ace-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ace>, <mailto:ace-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 22 Apr 2020 15:23:15 -0000

I have a few comments / questions about draft-raza-ace-cbor-certificates-04.txt section 6 on native CBOR certs

When you sign CBOR, usually it is wrapped in a bstr. This is important to be able to use typical CBOR encoders/decoders. This doesn’t seem to be the case here, at least I don’t see it in the text near the end of section 3.

Was any consideration given to using the COSE algorithm registry rather than defining a new one?

But of most interest to me is whether the COSE was considered as the signing format for native CBOR certs. If COSE is used, then this looks almost identical to CWT and may be a native CBOR cert is a variant of a CWT? One advantage of this would be reuse of some of the CWT (and EAT) code. Some of the fields in the CBOR cert might overlap with CWT claims. That might be a good thing.

LL