Re: [secdir] secdir review of draft-ietf-cose-typ-header-parameters

Dan Harkins <dharkins@lounge.org> Mon, 04 March 2024 07:42 UTC

Return-Path: <dharkins@lounge.org>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C7524C14F682; Sun, 3 Mar 2024 23:42:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.997
X-Spam-Level:
X-Spam-Status: No, score=-6.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.091, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lAhrC_zelfrj; Sun, 3 Mar 2024 23:42:12 -0800 (PST)
Received: from www.goatley.com (www.goatley.com [198.137.202.94]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 066B8C14F681; Sun, 3 Mar 2024 23:42:11 -0800 (PST)
Received: from kitty.bergandi.net (076-176-014-122.res.spectrum.com [76.176.14.122]) by wwwlocal.goatley.com (PMDF V6.8 #2433) with ESMTP id <0S9T1MH0PC2B9E@wwwlocal.goatley.com>; Mon, 04 Mar 2024 02:42:11 -0500 (EST)
Received: from [192.168.1.24] (customer.lsancax1.pop.starlinkisp.net [98.97.60.9]) by kitty.bergandi.net (PMDF V6.8 #2433) with ESMTPSA id <0S9T00740C29J6@kitty.bergandi.net>; Sun, 03 Mar 2024 23:42:11 -0800 (PST)
Received: from customer.lsancax1.pop.starlinkisp.net ([98.97.60.9] EXTERNAL) (EHLO [192.168.1.24]) with TLS/SSL by kitty.bergandi.net ([10.0.42.19]) (PreciseMail V3.3); Sun, 03 Mar 2024 23:42:11 -0800
Date: Sun, 03 Mar 2024 23:42:09 -0800
From: Dan Harkins <dharkins@lounge.org>
In-reply-to: <SJ0PR02MB7439F6090B095A63FA388A51B7232@SJ0PR02MB7439.namprd02.prod.outlook.com>
To: Michael Jones <michael_b_jones@hotmail.com>, "iesg@ietf.org" <iesg@ietf.org>, "secdir@ietf.org" <secdir@ietf.org>, "draft-ietf-cose-typ-header-parameter.all@ietf.org" <draft-ietf-cose-typ-header-parameter.all@ietf.org>
Message-id: <735a7670-7a04-3fd0-5a70-d1050854194e@lounge.org>
MIME-version: 1.0
Content-type: text/plain; charset="UTF-8"; format="flowed"
Content-language: en-US
Content-transfer-encoding: 8bit
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:102.0) Gecko/20100101 Thunderbird/102.15.1
X-PMAS-SPF: SPF check skipped for authenticated session (recv=kitty.bergandi.net, send-ip=98.97.60.9)
X-PMAS-External-Auth: customer.lsancax1.pop.starlinkisp.net [98.97.60.9] (EHLO [192.168.1.24])
References: <355edff2-75ed-c30e-858d-8bf7a027a164@lounge.org> <PH0PR02MB7430F66C51746AD01ADD9178B7232@PH0PR02MB7430.namprd02.prod.outlook.com> <fc28a997-c6f3-f3d3-ef77-f6c385d4efdd@lounge.org> <PH0PR02MB74306E59B052D57BF0FA24E7B7232@PH0PR02MB7430.namprd02.prod.outlook.com> <SJ0PR02MB7439F6090B095A63FA388A51B7232@SJ0PR02MB7439.namprd02.prod.outlook.com>
X-PMAS-Software: PreciseMail V3.3 [240301a] (kitty.bergandi.net)
X-PMAS-Allowed: system rule (rule allow header:X-PMAS-External noexists)
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/m0VtZfERj7v84dhgD_xsyE2dx1s>
Subject: Re: [secdir] secdir review of draft-ietf-cose-typ-header-parameters
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/secdir/>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 04 Mar 2024 07:42:15 -0000

   Hi Mike,

   The text that was added ("...other than being passed through
to applications.... Any processing of this parameter....") makes
the I-D clear now and it addresses my concern. Thank you very much!

   regards,

   Dan.

On 3/3/24 10:06 PM, Michael Jones wrote:
> Dan, please review https://github.com/selfissued/draft-ietf-cose-typ-header-parameter/pull/9, which is intended to address your comments.  I'll plan to publish -04 with this, possibly with revisions that you suggest, before the submission cut-off tomorrow.
>
>                                  Thanks again,
>                                  -- Mike
>
> -----Original Message-----
> From: Michael Jones <michael_b_jones@hotmail.com>
> Sent: Sunday, March 3, 2024 5:05 PM
> To: Dan Harkins <dharkins@lounge.org>; iesg@ietf.org; secdir@ietf.org; draft-ietf-cose-typ-header-parameter.all@ietf.org
> Subject: RE: secdir review of draft-ietf-cose-typ-header-parameters
>
> I understand that this could be clearer.  Let me think about how to make it so.  After all, I've got about 23 hours left until the submission deadline to ponder. ;-)
>
>                                  -- Mike
>
> -----Original Message-----
> From: Dan Harkins <dharkins@lounge.org>
> Sent: Sunday, March 3, 2024 4:53 PM
> To: Michael Jones <michael_b_jones@hotmail.com>; iesg@ietf.org; secdir@ietf.org; draft-ietf-cose-typ-header-parameter.all@ietf.org
> Subject: Re: secdir review of draft-ietf-cose-typ-header-parameters
>
>
>     Hi Mike,
>
>     So what you're saying is that the "implementation" is the entity that just parses the message and that the "application" is the entity that does something with parsed components of the messages, right? I guess I see what you're saying. I think the confusion was just in my differing definition of what it means for something to be an "implementation" versus an "application".
>
>     On the one had I want to just say, "forget about it, this is fine" but on the other hand, if I'm confused then there's a reasonable probability of other people being confused so you might want to make a new section
> 1.2 (suggest "Definitions") and explain the difference. Yes, I understand this is similar to the text in RFC 7515 but I wasn't assigned to review the draft that became RFC 7515 and just because it's there doesn't mean its clear. But I'll leave it up to you.
>
>     regards,
>
>     Dan.
>
> On 3/3/24 4:03 PM, Michael Jones wrote:
>> Thanks for reviewing, Dan.
>>
>> The language you cite is intentionally parallel to this language in the JWS spec at https://www.rfc-editor.org/rfc/rfc7515.html#section-4.1.9 : "This parameter is ignored by JWS implementations; any processing of this parameter is performed by the JWS application."
>>
>> The point in both cases is that the COSE (or JOSE) specification intentionally defines no processing rules for this field.  Therefore, COSE (or JOSE) libraries simply pass the field through to the application software calling it.  It's up to the application software to apply any processing rules that it defines, such as verifying that the "typ" value is a particular application-chosen media type and rejecting the data structure if it's not.
>>
>> Does that help?
>>
>>                                Thanks,
>>                                -- Mike
>>
>> -----Original Message-----
>> From: Dan Harkins <dharkins@lounge.org>
>> Sent: Saturday, March 2, 2024 2:11 PM
>> To: iesg@ietf.org; secdir@ietf.org;
>> draft-ietf-cose-typ-header-parameter.all@ietf.org
>> Subject: secdir review of draft-ietf-cose-typ-header-parameters
>>
>>
>>      Howdy,
>>
>> I have reviewed draft-ietf-cose-type-header-parameters as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments.
>>
>> The summary of the review is ready (but I do have a question).
>>
>> The draft defines the typ (type) header to COSE to parallel the header parameters defined by JOSE, this will permit "explicit typing" of JSON Web Tokens.
>>
>> The draft is very simple and straightforward and there aren't really any issues but I was unable to parse this sentence from section 2:
>>
>>        "This parameter is ignored by COSE implementations; any
>>        processing of this parameter is performed by the COSE
>>        application."
>>
>> I'm not sure what the authors are trying to say here. Applications of COSE represent an implementation of COSE, right? So it can't be both ignored and processed. Or can it? What am I missing?
>>
>>      regards,
>>
>>      Dan.
>>
>> --
>> "The object of life is not to be on the side of the majority, but to
>> escape finding oneself in the ranks of the insane." -- Marcus Aurelius
>>
> --
> "The object of life is not to be on the side of the majority, but to escape finding oneself in the ranks of the insane." -- Marcus Aurelius
>

-- 
"The object of life is not to be on the side of the majority, but to
escape finding oneself in the ranks of the insane." -- Marcus Aurelius