[COSE] Re: [EXT] Re: Requirement for protected header to actually be protected

Carsten Bormann <cabo@tzi.org> Fri, 04 July 2025 16:51 UTC

Return-Path: <cabo@tzi.org>
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 9AFAE3E66E13 for <cose@mail2.ietf.org>; Fri, 4 Jul 2025 09:51:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at ietf.org
X-Spam-Flag: NO
X-Spam-Score: -2.789
X-Spam-Level:
X-Spam-Status: No, score=-2.789 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no
Authentication-Results: mail2.ietf.org (amavisd-new); dkim=pass (2048-bit key) header.d=tzi.org
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 TskQ5yoH9EM6 for <cose@mail2.ietf.org>; Fri, 4 Jul 2025 09:51:15 -0700 (PDT)
Received: from smtp.zfn.uni-bremen.de (smtp.zfn.uni-bremen.de [IPv6:2001:638:708:32::21]) (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 849D33E66D5A for <cose@ietf.org>; Fri, 4 Jul 2025 09:51:11 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=tzi.org; s=2019; t=1751647869; bh=wpAoSNCU+q4GwjeLqMkqa1SBWtRy2jXvg+JfICn014k=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=JmqTx69i4xkpmWObx8F1c4uIxpEGd7E944nUQ+MwIcV23WERRFpelg2TYyud6sjnW gd4uZ4ciOn0jC1flq+pP+6xRBime5XUKC7lyu5IKfU1AKef4oA7zq9N222hia0SCQ7 q84KM6+De0S/adV1qjn31o6aS0nZjGdg4jDLcqjixv6CHszDXdcpf/N1dMn+fN6nSx wCfsG5NmEJIeQ/Vi5/9M+Nmk60Fg0owaUFqT4JwXpv7HiwoUxxcUPt2g4gM2ijhyDB 6wCC3/h6OrOdZNdxTT/ZacM0CUawUjCkarVGeZvEqxtiQuohcda/rshuNBpg1ZF0oh pURBp00b9mt3w==
Received: from [192.168.217.116] (p5dc5df6f.dip0.t-ipconnect.de [93.197.223.111]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.zfn.uni-bremen.de (Postfix) with ESMTPSA id 4bYflx3dRxzDCdy; Fri, 4 Jul 2025 18:51:09 +0200 (CEST)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.7\))
From: Carsten Bormann <cabo@tzi.org>
In-Reply-To: <f4f7995974e94c99bd09853b4ac8b043@jhuapl.edu>
Date: Fri, 04 Jul 2025 18:51:08 +0200
X-Mao-Original-Outgoing-Id: 773340668.721012-0f927d5a01451eff9df1a2fb33c7e500
Content-Transfer-Encoding: quoted-printable
Message-Id: <78EC60C4-EAC8-4ABE-B967-22DB14F90D5E@tzi.org>
References: <27687d9fe7f144948e3f801fc6b38a60@jhuapl.edu> <aGbXLV26swvuLL1l@LK-Perkele-VII2.locald> <f4f7995974e94c99bd09853b4ac8b043@jhuapl.edu>
To: "Sipos, Brian J." <Brian.Sipos@jhuapl.edu>
X-Mailer: Apple Mail (2.3608.120.23.2.7)
Message-ID-Hash: SWY43IOMNXEBN7EBB574SZON3N7XFL22
X-Message-ID-Hash: SWY43IOMNXEBN7EBB574SZON3N7XFL22
X-MailFrom: cabo@tzi.org
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: "ilariliusvaara@welho.com" <ilariliusvaara@welho.com>, "cose@ietf.org" <cose@ietf.org>
X-Mailman-Version: 3.3.9rc6
Precedence: list
Subject: [COSE] Re: [EXT] Re: Requirement for protected header to actually be protected
List-Id: CBOR Object Signing and Encryption <cose.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/cose/Bf1Fn-vGgRST9wvKBKJsRBgYSVI>
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 2025-07-03, at 21:35, Sipos, Brian J. <Brian.Sipos@jhuapl.edu> wrote:
> 
> But the direct (-6) algorithm makes no such statement

RFC 9053:
6.1.1.  Direct Key
[…]
   When this algorithm is used, the "protected" field MUST be zero
   length.  The key type MUST be "Symmetric".

I’m certainly unhappy about the way the various mandates are spread over different documents, but this one appears to be there.

Grüße, Carsten