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

[Michael Jones <[e-mail]>]

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 <[e-mail]>
Sent: Sunday, March 3, 2024 4:53 PM
To: Michael Jones <[e-mail]>; [e-mail]; [e-mail]; [e-mail]
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 <[e-mail]>
> Sent: Saturday, March 2, 2024 2:11 PM
> To: [e-mail]; [e-mail];
> [e-mail]
> 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