IETF Logo Mail Archive

[COSE] Re: Tweaks to draft-ietf-cose-c509-test-vectors?

Laurence Lundblade <lgl@island-resort.com> Thu, 23 July 2026 01:59 UTC

Return-Path: <lgl@island-resort.com>
X-Original-To: cose@mail2.ietf.org
Delivered-To: cose@mail2.ietf.org
Received: from localhost (localhost [127.0.0.1]) by mail2.ietf.org (Postfix) with ESMTP id BF92011CDFEF3 for <cose@mail2.ietf.org>; Wed, 22 Jul 2026 18:59:55 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1784771995; bh=7t15D18KvE9Zx4kcAyYm1jYWpEpN8tWsUXATi+XHxO4=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=OWqoQn+6EX5pnXXhVsoTdDX2+/6JSgDB1issBRkGy9O14T/plPwBcxHW+1QRadsiP HX4jWCRPpwonrsqHcEVnBlNovPc/eTws0hXKQz4VARuz1kxVJwub+ssOVJ2M/DnmDp RUaEXvLb6WNWsHGeotuFqP/DTgjaj5YGAnA4RiLY=
X-Virus-Scanned: amavisd-new at ietf.org
X-Spam-Flag: NO
X-Spam-Score: -1.696
X-Spam-Level:
X-Spam-Status: No, score=-1.696 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, RCVD_IN_VALIDITY_CERTIFIED_BLOCKED=0.001, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Authentication-Results: mail2.ietf.org (amavisd-new); dkim=neutral reason="invalid (public key: not available)" header.d=island-resort.com
Received: from mail2.ietf.org ([166.84.6.31]) by localhost (mail2.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WZCoh3J-ivaS for <cose@mail2.ietf.org>; Wed, 22 Jul 2026 18:59:55 -0700 (PDT)
Received: from sender4-op-o12.zoho.com (sender4-op-o12.zoho.com [136.143.188.12]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by mail2.ietf.org (Postfix) with ESMTPS id 4C45211CDFEF0 for <cose@ietf.org>; Wed, 22 Jul 2026 18:59:55 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; t=1784771987; cv=none; d=zohomail.com; s=zohoarc; b=Pgn42Tiay0g6AwXJDUkX6jbkwDF+XZA4rNz82xjusDrtX6kRknzLzrX0X1FkYYMeTRLI+R3wm3GZml3GWzHwowvBAzUW8DiBKyDEDPeI9lRDwr0zgbLyNfLflo+24priJoRCHJxBpEPbzbxarKQhxfWphHq7NUhH405m4lItIHA=
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1784771987; h=Content-Type:Content-Transfer-Encoding:Cc:Cc:Date:Date:From:From:In-Reply-To:MIME-Version:Message-ID:Subject:Subject:To:To:Message-Id:Reply-To; bh=gjxckztZ/o3x0U+WcNdDmLFH8ynd89R2XxL2JoO1VT0=; b=gqW1MMWEYGVpRwUs6kInu3/gmkZz5F8BlK+MJdjVXSGLcXtpNoO5A90sGhsy2S5F6m6grbZ44QKVN7xWXPbXdNYx2GIQjM2DuALaO2UYmNmxfyE3Drz9Qmfa6TEGoHPdvX/F11bKdahIYBb+gw1qznb/KpkuodffYU+X1jaF0cA=
ARC-Authentication-Results: i=1; mx.zohomail.com; dkim=pass header.i=island-resort.com; spf=pass smtp.mailfrom=lgl@island-resort.com; dmarc=pass header.from=<lgl@island-resort.com>
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; t=1784771987; s=island; d=island-resort.com; i=lgl@island-resort.com; h=Content-Type:Mime-Version:Subject:Subject:From:From:In-Reply-To:Date:Date:Cc:Cc:Content-Transfer-Encoding:Message-Id:Message-Id:To:To:Reply-To; bh=gjxckztZ/o3x0U+WcNdDmLFH8ynd89R2XxL2JoO1VT0=; b=RpsGqDgUKKzGI9E1/oFRn1Avw874BqdroqHdm8H8gUq/Y+oVLaz86ktNeGsnUh8O 6AG73c7s/Bi64PqdOkMcrgBTsW9GpBdyhGsi1ujdBH2Fm4mwlTH7hdBCAvNcYqf62fn hCOV9xBR9wmKGakIks1rVIewXO3UZVF83OK6PbNc=
Received: by mx.zohomail.com with SMTPS id 1784771983976430.93281312944646; Wed, 22 Jul 2026 18:59:43 -0700 (PDT)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3826.500.181.1.5\))
From: Laurence Lundblade <lgl@island-resort.com>
In-Reply-To: <AS1PR07MB847728A83813375098C1954FF4C12@AS1PR07MB8477.eurprd07.prod.outlook.com>
Date: Wed, 22 Jul 2026 18:59:32 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <A58E3616-FCBF-4321-A2E3-AAA7D693C03F@island-resort.com>
References: <2EA736E2-70EA-48BC-A8AD-6183EB08A91B@island-resort.com> <DB5P192MB22303470F16984AEA30E8F1CEBC22@DB5P192MB2230.EURP192.PROD.OUTLOOK.COM> <F41B7FA7-4758-479D-B427-F3D5511478E3@island-resort.com> <56422BBD-B09E-4563-8A45-C1F34B4E38AE@tzi.org> <20CF34FC-AD20-4275-9172-9EEA0D814685@island-resort.com> <AS1PR07MB847728A83813375098C1954FF4C12@AS1PR07MB8477.eurprd07.prod.outlook.com>
To: Göran Selander <goran.selander=40ericsson.com@dmarc.ietf.org>
X-Mailer: Apple Mail (2.3826.500.181.1.5)
X-ZohoMailClient: External
Message-ID-Hash: 7BCVVNLLMH2NYUK3N3PI5UYXN4P7BIUX
X-Message-ID-Hash: 7BCVVNLLMH2NYUK3N3PI5UYXN4P7BIUX
X-MailFrom: lgl@island-resort.com
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-cose.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
CC: Carsten Bormann <cabo@tzi.org>, cose <cose@ietf.org>, Lijun Liao <lijun.liao=40nio.io@dmarc.ietf.org>
X-Mailman-Version: 3.3.9rc6
Precedence: list
Subject: [COSE] Re: Tweaks to draft-ietf-cose-c509-test-vectors?
List-Id: CBOR Object Signing and Encryption <cose.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/cose/_VN9JSs26Q3zPNx3OGVdutdYvLE>
List-Archive: <https://mailarchive.ietf.org/arch/browse/cose>
List-Help: <mailto:cose-request@ietf.org?subject=help>
List-Owner: <mailto:cose-owner@ietf.org>
List-Post: <mailto:cose@ietf.org>
List-Subscribe: <mailto:cose-join@ietf.org>
List-Unsubscribe: <mailto:cose-leave@ietf.org>

> On Jul 22, 2026, at 12:31 PM, Göran Selander <goran.selander=40ericsson.com@dmarc.ietf.org> wrote:
> 
>     • Laurence: I didn’t understand what is unclear with: "Hash of a C509Certificate”. C509Certificate is a CBOR array with 11 elements, i.e., starting with 0x8B. How does “CBOR-encoded C509Certificate” make that more clear?

These parameters are very independent, right? If you are sending/receiving c5t, you are not sending/receiving c5b or c5c. 

The point is to remove mention of C509CertData from the paragraph discussing c5t because it has nothing to do with c5t. A c5t is a COSE_CertHash, an array of 2 with a hash algorithm ID and a bstr containing the hash. If you are sending or receiving a c5t, you are not using C509CertData at all.

The mention of C509CertData makes one think that maybe you should bstr wrap the C509Certificate before hashing. It leaves one trying to figure out why it is mentioned. (I suppose I may be missing something, but I couldn’t come up with any reason that it would be mentioned).

If you are sending or receiving c5b or c5c, that is different, then you are using C509CertData because it is part of a COSE_C509.

LL

v2.46.0 | Report a Bug | By Email | System Status