[Last-Call] Re: Artart last call review of draft-ietf-cose-tsa-tst-header-parameter-03

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Shuping,

Thanks very much for the review.

On Sat, 28 Dec 2024 at 10:03, Shuping Peng via Datatracker
<noreply@xxxxxxxx> wrote:
>
> Reviewer: Shuping Peng
> Review result: Ready with Issues
>
> I am the assigned ART-ART reviewer for this draft.
>
> Summary:
>
> I have some minor concerns about this document that I think should be resolved
> before publication.
>
> Comments:
>
> The 03 version has resolved the comments posted in the mailing list so far. The
> IANA description is much more clear, two use cases are added, and the Security
> considerations is significantly extended.
>
> Major Issues:
>
>  "No major issues found."
>
> Minor Issues:
>
> 1. A COSE header parameter with two modes or two COSE header parameters for two
> modes?
>
> In the Abstract, it says "This document defines a CBOR Signing And Encrypted
> (COSE) header parameter for ...". In Section 1, it says "This document defines
> two new CBOR Object Signing and Encryption (COSE) [STD96] header parameters
> that ..." In Section 3, it says "The two modes described in ... To clearly
> separate their semantics two different COSE header parameters are defined as
> described in the following subsections."
>
> So is it about two COSE header parameters for two modes? Maybe simply changing
> the wording in the Abstract?
>
> 2. Section 2.1
> To compare through 2.1, 2.2, 3.1, and 3.2, would it be more clear to move this
> following sentence to Section 3.1? "The message imprint sent to the TSA
> (Section 2.4 of [RFC3161]) MUST be the hash of the payload field of the COSE
> signed object."
>
> 3. Section 2.1, 3.2
> To compare against RFC 3161 and the Figures, should "message imprint" be
> "messageImprint"? s/message imprint/messageImprint
>
> 4. Section 3.1
> This following sentence could be moved to the end of this sub-section, to
> better align with the similar information in Section 3.2. "The 3161-ttc
> protected header parameter contains a DER-encoded RFC3161 TimeStampToken
> wrapped in a CBOR byte string (Major type 2)."
>
> Nits:
> 6. IANA Considerations
> In Table 1.
> s/"3161-tcc"/"3161-ttc"

We have filed issues for your suggestions [1] and will work on them in
the next few days.

cheers!

[1] https://github.com/ietf-scitt/draft-birkholz-cose-tsa-tst-header-parameter/issues?q=is%3Aissue+is%3Aopen+label%3Aartart

-- 
last-call mailing list -- last-call@xxxxxxxx
To unsubscribe send an email to last-call-leave@xxxxxxxx




[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Mhonarc]     [Fedora Users]

  Powered by Linux