[SCITT] Re: [Last-Call] Re: [EXTERNAL] draft-ietf-scitt-receipts-ccf-profile-04 ietf last call Artart review

[Amaury Chamayou <[e-mail]>]

Hi Jijie,

I don't see Vernon's review on the datatracker, so I am not sure what you are referring to, this email is in response to IETF Last Call reviews.

  1.
Section 3.2, Figure 7: verify_inclusion_receipt() still takes the
receipt alone, and Section 2.2 still does not name the byte string
that data-hash covers.

Yes, that's what it verifies. Is the suggestion to change it to pass data-hash and add the assert inside the call? The last three sentences of Section 2.2 describe how data-hash is computed, I am not sure what you mean by not named.

  1.
Section 7 (Security Considerations): no statement that receipt
verification is independent of whether the anchored statement is
currently valid.

 That's covered by 9.2 in RFC9943, it's unrelated to VDS profile definition.

  1.
Figure 6: the path is still [+ ccf-proof-element], and single-
transaction ledgers are not stated as out of scope.

Happy to make that change, but the point of a single-entry ledger is questionable at best.

I don't mind doing a draft-06 to address 1 and 3, could you just clarify what you mean by naming? Is there something missing from the description?

Thank you,
Amaury

________________________________
From: Jijie Wei <[e-mail]>
Sent: Thursday, September 24, 2026 13:36
To: last-call <[e-mail]>
Cc: scitt <[e-mail]>; draft-ietf-scitt-receipts-ccf-profile.all <[e-mail]>; Amaury Chamayou <[e-mail]>
Subject: Re: [Last-Call] Re: [EXTERNAL] draft-ietf-scitt-receipts-ccf-profile-04 ietf last call Artart review

Some people who received this message don't often get email from [e-mail]. Learn why this is important<https://aka.ms/LearnAboutSenderIdentification>
Hi Amaury, authors,

Thanks for -05 and for the note. I understand your reply was to
Jasdip's ARTART review. For the record, I don't see the three items
Vernon listed on September 3 [1], and which I supported on September 4,
addressed in -05:

1. Section 3.2, Figure 7: verify_inclusion_receipt() still takes the
   receipt alone, and Section 2.2 still does not name the byte string
   that data-hash covers.

2. Section 7 (Security Considerations): no statement that receipt
   verification is independent of whether the anchored statement is
   currently valid.

3. Figure 6: the path is still [+ ccf-proof-element], and single-
   transaction ledgers are not stated as out of scope.

On the validity period point, your reply covers where a validity period
can be expressed. Item 2 asks whether receipt verification depends on
current validity -- a separate question.

Could you give a one-line disposition for each item and confirm whether a
-06 is planned? If any of them is meant to be handled elsewhere or
declined for this profile, saying so on the record is sufficient. I am
not asking to reopen the Last Call.

Best,
Jijie

[1] https://mailarchive.ietf.org/arch/msg/scitt/JFFYLHz293H6tS6vpxpPXNxqmZQ/