IETF Logo Mail Archive

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

"Sipos, Brian J." <Brian.Sipos@jhuapl.edu> Thu, 03 July 2025 19:35 UTC

Return-Path: <Brian.Sipos@jhuapl.edu>
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 A54123DB8413 for <cose@mail2.ietf.org>; Thu, 3 Jul 2025 12:35:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at ietf.org
X-Spam-Flag: NO
X-Spam-Score: -1.868
X-Spam-Level:
X-Spam-Status: No, score=-1.868 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_VALIDITY_CERTIFIED_BLOCKED=0.232, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: mail2.ietf.org (amavisd-new); dkim=pass (2048-bit key) header.d=jhuapl.edu
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 a-ED4zET8tm2 for <cose@mail2.ietf.org>; Thu, 3 Jul 2025 12:35:05 -0700 (PDT)
Received: from aplegw03.jhuapl.edu (aplegw03.jhuapl.edu [128.244.208.131]) by mail2.ietf.org (Postfix) with ESMTP id 6FC9F3DB83E1 for <cose@ietf.org>; Thu, 3 Jul 2025 12:35:01 -0700 (PDT)
Received: from pps.filterd (aplegw03.jhuapl.edu [127.0.0.1]) by aplegw03.jhuapl.edu (8.18.1.2/8.18.1.2) with ESMTP id 563JUguZ137262; Thu, 3 Jul 2025 15:35:01 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jhuapl.edu; h=content-type : date : from : in-reply-to : message-id : mime-version : references : subject : to; s=JHUAPL2024; bh=K6+Ih/UKsVzDUH3Xz+ebVrXENWBBLfOxt6/NuN+9yyw=; b=ocQNueownFlEfA9AKebsHrKoEN4GFpkjrNETvIPnqiFgWoiJm4VeI3dEuKN1g0SZCG0j HWXMEM6X29O81AxytwhgcZf3HarY/71gpWmdhERwNf3TJZWFiGqjExkxx7vE9JBeU9vk YaZegh9UxE8bS4+K8nHMmwrQJmAyp592eTqhpp4MDs/pY/VfdogElH4pycC1LSI2qEuS MttMD8lU/GWLhYhPLY+5MIVOAmO2ghMrNLO5ZjxMVYucjrfzYuFz3IwipAboKXvBOpoC mfUfpDejjHIoBCV3t17C952sbwC6pWVbDwnxvV0XsDz3XcwPlW38L4mj+ymGO7tuBNal 7g==
Received: from aplex27.dom1.jhuapl.edu (aplex27.dom1.jhuapl.edu [10.114.162.12]) by aplegw03.jhuapl.edu (PPS) with ESMTPS id 47jxjbdj79-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 03 Jul 2025 15:35:01 -0400
Received: from APLEX21.dom1.jhuapl.edu (10.114.162.6) by APLEX27.dom1.jhuapl.edu (10.114.162.12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1748.10; Thu, 3 Jul 2025 15:35:00 -0400
Received: from APLEX21.dom1.jhuapl.edu ([fe80::20d7:9545:f01e:9b2]) by APLEX21.dom1.jhuapl.edu ([fe80::20d7:9545:f01e:9b2%5]) with mapi id 15.02.1748.010; Thu, 3 Jul 2025 15:35:00 -0400
From: "Sipos, Brian J." <Brian.Sipos@jhuapl.edu>
To: "ilariliusvaara@welho.com" <ilariliusvaara@welho.com>, "cose@ietf.org" <cose@ietf.org>
Thread-Topic: [EXT] [COSE] Re: Requirement for protected header to actually be protected
Thread-Index: AdvsQqJAGvBB6OIFTFu3A2hLoSgVSQALfJKAAAfwbAA=
Date: Thu, 03 Jul 2025 19:35:00 +0000
Message-ID: <f4f7995974e94c99bd09853b4ac8b043@jhuapl.edu>
References: <27687d9fe7f144948e3f801fc6b38a60@jhuapl.edu> <aGbXLV26swvuLL1l@LK-Perkele-VII2.locald>
In-Reply-To: <aGbXLV26swvuLL1l@LK-Perkele-VII2.locald>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
x-originating-ip: [10.114.162.19]
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg="SHA1"; boundary="----=_NextPart_000_01CB_01DBEC30.08D42DB0"
MIME-Version: 1.0
X-CrossPremisesHeadersFilteredBySendConnector: APLEX27.dom1.jhuapl.edu
X-OrganizationHeadersPreserved: APLEX27.dom1.jhuapl.edu
X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.293,Aquarius:18.0.1099,Hydra:6.1.7,FMLib:17.12.80.40 definitions=2025-07-03_04,2025-07-02_04,2025-03-28_01
Message-ID-Hash: 7YPVFZIGSCPSOI6BMEGIXKZSEVMLOKU7
X-Message-ID-Hash: 7YPVFZIGSCPSOI6BMEGIXKZSEVMLOKU7
X-MailFrom: Brian.Sipos@jhuapl.edu
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
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/V7_nDN_dFNXofJjJbFKCBG4MqsI>
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>

Ilari,
Thanks for confirming this. It does appear that the section on AES-KW in RFC 9053 [2] includes the statement "The protected header bucket MUST be empty." and two families defined in RFC 9459 [3] have similar statements. But the direct (-6) algorithm makes no such statement nor does the RSAES-OAEP family [4]. So it seems desirable but inconsistent.

Does this rise to the level of an errata for the general discussion of protected header in RFC 9052? I think having specific guidance there would help understanding for those who don't have a huge background in this ecosystem.

Brian S.

[2] https://www.rfc-editor.org/rfc/rfc9053.html#section-6.2.1
[3] https://www.rfc-editor.org/rfc/rfc9459.html
[4] https://www.rfc-editor.org/rfc/rfc8230.html#section-3

> -----Original Message-----
> From: ilariliusvaara@welho.com <ilariliusvaara@welho.com>
> Sent: Thursday, July 3, 2025 3:17 PM
> To: cose@ietf.org
> Subject: [EXT] [COSE] Re: Requirement for protected header to actually be
> protected
> 
> APL external email warning: Verify sender forwardingalgorithm@ietf.org before
> clicking links or attachments
> 
> On Thu, Jul 03, 2025 at 05:48:21PM +0000, Sipos, Brian J. wrote:
> > WG,
> >
> > I was looking for, and have failed to find, any requirement in the
> > base COSE specification [1] that if the protected header map is
> > non-empty the associated algorithm must support additional
> > authenticated data (AAD). The non-normative text and examples seem to
> > support this but I don't see anything normative around this. Am I just
> > missing something? Or does this seem like something that deserves a
> constraint?
> >
> 
> I guess this was what was intended — like intending to only have authenticated
> symmetric encryption so to not need algorithm binding — but it wasn't explicitly
> written anywhere. The section on AE certainly forbids protected headers.
> 
> 
> 
> 
> -Ilari
> 
> _______________________________________________
> COSE mailing list -- cose@ietf.org
> To unsubscribe send an email to cose-leave@ietf.org

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