Hi Authors, *Hannes,

Authors - Thank you for your reply! We have updated the document accordingly. 
Please see below for followup comments/questions.

*Hannes - We have updated your affiliation as requested. 

>> 5) <!-- [rfced] May we rephrase the following sentence for clarity?
>> Original:
>>   It MUST be represented as a string made of nineteen numeric
>>   characters: a thirteen-digit [EAN-13], followed by a dash "-",
>>   followed by the five-digit versioning information described in
>>   [PSA-Cert-Guide].
>> Perhaps:
>>   It MUST be represented as a string made of nineteen numeric
>>   characters: a thirteen-digit [EAN-13], followed by a dash "-",
>>   followed by the five-digit versioning information described in
>>   [PSA-Cert-Guide].
>> -->
> 
> "Original" and "Perhaps" look exactly the same :-)

1) Apologies for the confusion! Here is the corrected question:

<!-- [rfced] May we rephrase the following sentence for clarity?

Original:
  It MUST be represented as a string made of nineteen numeric
  characters: a thirteen-digit [EAN-13], followed by a dash "-",
  followed by the five-digit versioning information described in
  [PSA-Cert-Guide].

Perhaps:
 The Certification Reference claim MUST be represented as a string              
                           
 made of nineteen numeric characters: a thirteen-digit EAN-13 [EAN-13] followed 
                            
 by a dash "-" and the five-digit versioning information described in 
[PSA-Cert-Guide].                                                               
                          
-->

>> 11) <!-- [rfced] Reference-related questions: 
>> d) It appears as though the goal is to refer to the most recent I-D
>> prior to deprecation of the "private use range" values.  As such, we
>> have updated the reference to refer to version -08.  Please review and
>> let us know if any updates are needed. Original:
>>   [PSA-OLD]  Tschofenig, H., Frost, S., Brossard, M., Shaw, A. L.,
>>   and T. Fossati, "Arm's Platform Security Architecture (PSA)
>>   Attestation Token", Work in Progress, Internet-Draft,
>>   draft-tschofenig-rats-psa-token-07, 1 February 2021,
>>   <https://datatracker.ietf.org/doc/html/draft-tschofenig-
>>   rats-psa-token-07>.
>> -->
> 
> No, here we want to reference the last version of the document which
> defined PSA_IO_PROFILE_1, that is -07.
> 
> (Aside: the "Work in Progress" sounds a bit misleading because in this
> case we are referring to a very specific version which is frozen in
> time.)

2) Thank you for letting us know! We have reverted this change. Also, please 
note that all I-D references include "Work in Progress", so we are unable to 
make any changes regarding this wording.

>> 14) <!-- [rfced] Terminology 
>> b) Please let us know how we should update the following terms for 
>> consistency throughout the document.
>> EAT nonce claim vs. nonce claim vs. Nonce claim
> 
> "EAT nonce claim" as in RFC9711

3) After reviewing the terminology for "nonce" in <tt> tags, we came across the 
following sentences in Section 4.1.1 that may need review. To follow your 
preference for claim names appearing in quotes, should quotes be applied here 
since the EAT "nonce" claim is referring to a claim name? Additionally, should 
the first sentence of the second paragraph be deleted since it seems 
repetitive? 

Current:
The Nonce claim is used to carry the challenge provided by the caller
to demonstrate freshness of the generated token.

The EAT [EAT] nonce (claim key 10) is used. Since the EAT nonce
claim offers flexiblity for different attestation technologies, this
specification applies the following constraints to the nonce-type:

Perhaps:
The EAT [EAT] "nonce" (claim key 10) is used to carry the challenge 
provided by the caller to demonstrate freshness of the generated token.

Since the EAT nonce claim offers flexiblity for different attestation 
technologies, this specification applies the following constraints to the 
nonce-type:


4) Please note that we also await your preference regarding the following terms:
* Arm's Platform Security Architecture vs. The Arm Platform Security 
Architecture
* PSA-token claims-set vs. PSA claims-set (Appendix A)


Updated files have been posted here (please refresh):
   https://www.rfc-editor.org/authors/rfc9783.txt
   https://www.rfc-editor.org/authors/rfc9783.pdf
   https://www.rfc-editor.org/authors/rfc9783.html
   https://www.rfc-editor.org/authors/rfc9783.xml

Updated diffs are here: 
   https://www.rfc-editor.org/authors/rfc9783-diff.html
   https://www.rfc-editor.org/authors/rfc9783-rfcdiff.html (side by side)
   https://www.rfc-editor.org/authors/rfc9783-auth48diff.html
   https://www.rfc-editor.org/authors/rfc9783-auth48rfcdiff.html (side by side)

For the AUTH48 status page, please see: 
https://www.rfc-editor.org/auth48/rfc9783.

Thank you!
RFC Editor/mc
-- 
auth48archive mailing list -- auth48archive@rfc-editor.org
To unsubscribe send an email to auth48archive-le...@rfc-editor.org
  • [auth48] Re:... RFC Editor via auth48archive
    • [auth48... Independent Submissions Editor (Eliot Lear) via auth48archive
      • [au... Thomas Fossati via auth48archive
    • [auth48... Thomas Fossati via auth48archive
      • [au... Hannes Tschofenig via auth48archive
      • [au... Madison Church via auth48archive
        • ... Hannes Tschofenig via auth48archive
          • ... Thomas Fossati via auth48archive
        • ... Thomas Fossati via auth48archive
          • ... Independent Submissions Editor (Eliot Lear) via auth48archive
            • ... Madison Church via auth48archive
              • ... Madison Church via auth48archive
                • ... Mathias Brossard via auth48archive
                • ... Madison Church via auth48archive
                • ... Hannes Tschofenig via auth48archive
                • ... Madison Church via auth48archive

Reply via email to