Re: [COSE] Help with RFC8152 encryption example
Benjamin Kaduk <kaduk@mit.edu> Fri, 14 May 2021 04:00 UTC
Return-Path: <kaduk@mit.edu>
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 2EDFD3A20FB for <cose@ietfa.amsl.com>; Thu, 13 May 2021 21:00:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.499
X-Spam-Level:
X-Spam-Status: No, score=-1.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, KHOP_HELO_FCRDNS=0.398, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=no 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 M4pafzVOFtIE for <cose@ietfa.amsl.com>; Thu, 13 May 2021 21:00:25 -0700 (PDT)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (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 9911F3A20FE for <cose@ietf.org>; Thu, 13 May 2021 21:00:25 -0700 (PDT)
Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 14E40Hgv009217 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 14 May 2021 00:00:23 -0400
Date: Thu, 13 May 2021 21:00:17 -0700
From: Benjamin Kaduk <kaduk@mit.edu>
To: Carsten Bormann <cabo@tzi.org>
Cc: cose@ietf.org
Message-ID: <20210514040017.GL79563@kduck.mit.edu>
References: <b9138e0c-a63f-bb15-11f1-b7c4519ebf2e@gmail.com> <BEEEB4E5-5FAC-4EA6-88FD-23D7B031C7AB@tzi.org> <53320179-c867-d0c3-4b50-6eeb11ab5fd4@gmail.com> <25CC1B9F-FBE1-482D-BDE4-724A684F53D5@tzi.org> <7E82B2CB-54A3-440F-82C2-DB0BD26AB1BC@tzi.org>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <7E82B2CB-54A3-440F-82C2-DB0BD26AB1BC@tzi.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/cose/z0Dv3klC-kZwZjyDiKwrER_7Nzk>
Subject: Re: [COSE] Help with RFC8152 encryption example
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: Fri, 14 May 2021 04:00:37 -0000
On Mon, May 10, 2021 at 05:03:08PM +0200, Carsten Bormann wrote: > On 2021-05-10, at 16:36, Carsten Bormann <cabo@tzi.org> wrote: > > > > But 8152 predates that document, so it uses basic DN, which doesn’t have <</>> yet, which is part of the problem you had.) > > … and I should have added that this is fixed in draft-ietf-cose-rfc8152bis-struct-15, which is really what you should be using anyway. > > BTW, it’s in the RFC editor queue, but I don’t understand its status: > https://www.rfc-editor.org/cluster_info.php?cid=C416 Interestingly, a few hours after your note, all three transitioned from "REF*R" to "RFC-EDITOR*R", which is only slightly less confusing... (I would have assumed that their systems have loop detection if the REF state was just from mutual dependencies...) -Ben
- [COSE] Help with RFC8152 encryption example Anders Rundgren
- Re: [COSE] Help with RFC8152 encryption example Carsten Bormann
- Re: [COSE] Help with RFC8152 encryption example Anders Rundgren
- Re: [COSE] Help with RFC8152 encryption example Carsten Bormann
- Re: [COSE] Help with RFC8152 encryption example Carsten Bormann
- Re: [COSE] Help with RFC8152 encryption example Benjamin Kaduk