Re: [auth48] AUTH48: RFC-to-be 9334 <draft-ietf-rats-architecture-22> for your review

[Michael Richardson <[e-mail]>]

[e-mail] wrote:
    > 10) <!-- [rfced] Should the title of Figure 4 be updated to accurately
    > reflect the information provided in Section 3.3?

    > Original: Figure 4: Composite Device

    > Perhaps: Figure 4: Conceptual Data Flow for a Composite Device -->

Sounds good to us.

    > 11) <!--[rfced] We see the use of "Compare:" throughout the Terminology
    > section has special meaning.  As the text that follows isn't really a
    > sentence, and the slashes may be confusing/distracting, we will update
    > as follows for each of these similar instances unless we hear
    > objection.

    > Original: Compare: /relying party/ in [RFC4949].

    > Perhaps: Compare: relying party [RFC4949]
    -->

The trailing period is for consistency with RFC4949.
Removing the slashes is fine with us.

    > 12) <!--[rfced] "informs" seems like it should take an object.  Might a
    > rewording be acceptable here?

    > Original: Appraisal Policy for Evidence: A set of rules that informs
    > how a Verifier evaluates the validity of information about an Attester.
    > Compare: /security policy/ in [RFC4949].

    > Perhaps: Appraisal Policy for Evidence: A set of rules that provides
    > information about how a Verifier evaluates the validity of information
    > about an Attester.  Compare: /security policy/ in [RFC4949].
    -->

We prefer:

   Appraisal Policy for Evidence: A set of rules that
   a Verifier uses to evaluate the validity of information
   about an Attester.  Compare: security policy in [RFC4949].

    > 13) <!--[rfced] The use of "pass the policy" seems somewhat unusual.
    > Please let us know how we may rephrase.

    > Original: * The second way in which the process may fail is when the
    > Attestation Result is examined by the Relying Party, and based upon the
    > Appraisal Policy for Attestation Results, the result does not pass the
    > policy.

We suggest:

* The second way in which the process may fail is when the Attestation Result
is examined by the Relying Party, and based upon the Appraisal Policy for
Attestation Results, the result does not comply with the policy.


    > 14) <!-- [rfced] We had the following questions related to the use of
    > <tt> and <em> in the document.

    > a) Please confirm that <tt> and <em> provide output that is expected
    > after reading the points below.  Let us know if any changes are
    > necessary.

    > -In the html and pdf outputs, the text enclosed in <tt> is output in
    > fixed-width font. In the txt output, there are no changes to the font.

    > -In the html and pdf outputs, the text enclosed in <em> is output in
    > italics. In the txt output, the text enclosed in <em> appears with an
    > underscore before and after.

We understand and agree with this formatting, and aware of how it shows.

    > b) FYI: We removed 'in' from the emphasized string of text below to
    > provide more emphasis to the word "encapsulated". Please let us know
    > any objections.

    > Original XML: The only requirement is that the Evidence can be
    > <em>encapsulated in</em> the format required by the resource access
    > protocol between the Attester and Relying Party.

    > Current XML: The only requirement is that the Evidence can be
    > <em>encapsulated</em> in the format required by the resource access
    > protocol between the Attester and Relying Party.
    -->

No objection.

    > 15) <!-- [rfced] Will readers be able to easily identify the expansion
    > of GPIO?  We recommend expanding abbreviations on first use (see RFC
    > 7322).

    > Original: Alternative channels to convey conceptual messages include
    > function calls, sockets, GPIO interfaces, local busses, or hypervisor
    > calls. -->


Please go ahead and expand GPIO interfaces as "General-Purpose Input/Output
(GPIO) interfaces"

    > 16) <!--[rfced] In the following text, is it the other authorized
    > parties that address the handling of sensitive information?  Or should
    > it be "a governing policy that addresses" for subject/verb agreement?

    > Original: The Verifier might share this information with other
    > authorized parties, according to a governing policy that address the
    > handling of sensitive information (potentially included in Appraisal
    > Policies for Evidence).

    > Perhaps: The Verifier might share this information with other
    > authorized parties according to a governing policy that addresses the
    > handling of sensitive information (potentially included in Appraisal
    > Policies for Evidence).
    -->

We agree that the latter is better.


    > 17) <!-- [rfced] We suggest rewording this sentence to avoid repetition
    > of the phrases "in such a case/in which case". This change will make
    > the text more concise and easier to read. Does the following suggestion
    > change the original meaning of the text?

    > Original: In such a case, authentication or attestation in both
    > directions might be needed, in which case typically one side's Evidence
    > must be considered safe to share with an untrusted entity, in order to
    > bootstrap the sequence.

    > Perhaps: In such a case, authentication or attestation in both
    > directions might be needed. Typically, one side's Evidence must be
    > considered safe to share with an untrusted entity in order to bootstrap
    > the sequence.
    -->

We agree that the latter is better.


    > 18) <!--[rfced] Please review the use of COAP in the following text.
    > Should this be made "CoAP" (Constrained Application Protocol)?

    > Original: In this diagram, the protocol between Attester and a Relying
    > Party can be any new or existing protocol (e.g., HTTP(S), COAP(S),
    > ROLIE [RFC8322], 802.1x, OPC UA [OPCUA], etc.), depending on the use
    > case.
    -->


Yes, the "o" in CoAP should be lower case.


    > 19) <!--[rfced] Please review the use of "non-predictable" as opposed
    > to "unpredictable".

    > Original: In this approach, a non-predictable nonce is sent by the
    > appraising entity and the nonce is then signed and included along with
    > the Claims in the Evidence or Attestation Result.
    -->

Yes, change it to "unpredictable"


    > 20) <!-- [rfced] Please confirm our edits to this text have not altered
    > the intended meaning.

    > Original: For public-key cryptography, it is, by definition, not
    > necessary to maintain confidentiality of the public key: however
    > integrity of the chain of custody of the public key is necessary in
    > order to avoid attacks where an attacker is able to get a key they
    > control endorsed.

    > Current: By definition, it is not necessary to maintain confidentiality
    > of the public key for public-key cryptography; however, integrity of
    > the chain of custody of the public key is necessary in order to avoid
    > attacks where an attacker is able to get a key that the attacker
    > controls endorsed.
    -->

We agree that the edits do not change the intended meaning, but we prefer to
keep the start of the sentence, as it fits better with the previous sentence.

We prefer:

  For public-key cryptography, it is not necessary to maintain confidentiality
  of the public key. However, integrity of the chain of custody of the
  public key is necessary in order to avoid attacks where an attacker is able
  to get a key endorsed that the attacker controls.


    > 21) <!-- [rfced] The titles listed for the following reference entries
    > do not match the titles that appear at the links provided.  For each
    > reference below, we have updated to match the URL.  Please let us know
    > any objections.

    > Original (1): [WebAuthN] W3C, "Web Authentication: An API for accessing
    > Public Key Credentials", n.d., <https://www.w3.org/TR/webauthn-1/>.

    > Current (1): [WebAuthN] W3C, "Web Authentication: An API for accessing
    > Public Key Credentials Level 1", 4 March 2019,
    > <https://www.w3.org/TR/webauthn-1/>.

    > Original (2): [CTAP] FIDO Alliance, "Client to Authenticator Protocol",
    > n.d., <https://fidoalliance.org/specs/fido-v2.0-id-20180227/
    > fido-client-to-authenticator-protocol-v2.0-id-
    20180227.html> .

    > Current (2): [CTAP] FIDO Alliance, "Client to Authenticator Protocol
    > (CTAP)", 27 February 2018, <https://fidoalliance.org/specs/fido-
    > v2.0-id-20180227/fido-client-to-authenticator-protocol-
    v2.0-id-20180227.html> .

    > Original (3): [TCG-DICE-SIBDA] Trusted Computing Group, "Symmetric
    > Identity Based Device Attestation for DICE", 24 July 2019,
    > <https://trustedcomputinggroup.org/wp-content/uploads/
    TCG_DICE_SymIDAttest_v1_r0p94_pubrev.pdf> .

    > Current (3): [TCG-DICE-SIBDA] Trusted Computing Group, "Symmetric
    > Identity Based Device Attestation", 24 July 2019,
    > <https://trustedcomputinggroup.org/wp-content/uploads/
    TCG_DICE_SymIDAttest_v1_r0p94_pubrev.pdf> .
    -->

All seem okay to us.

    > 22) <!--[rfced] I-D.birkholz-rats-tuda has been replaced.  Please note
    > that we have updated this reference entry to instead point to
    > I-D.ietf-rats-uccs.  Please let us know any objections.-->

No.   The correct document is still: draft-birkholz-rats-tuda

    > 23) <!-- [rfced] The target URL for this reference leads to a PDF
    > titled "A Technical Analysis of Confidential Computing". We found a
    > different URL that leads to a PDF with the reference's original title
    > "Confidential Computing Deep Dive v1.0".  Please review which URL
    > should be used for this reference.

    > Original: [CCC-DeepDive] Confidential Computing Consortium,
    > "Confidential Computing Deep Dive", n.d.,
    > <https://confidentialcomputing.io/whitepaper-02-latest>.

    > Perhaps: [CCC-DeepDive] Confidential Computing Consortium,
    > "Confidential Computing Deep Dive", October 2020,
    > <https://confidentialcomputing.io/wp-content/uploads/sites/85/2020/10/Confidential-Computing-Deep-Dive-
    white-paper.pdf> .
    -->

Both are wrong.
The correct title is:
    A Technical Analysis of Confidential Computing
It is now version 1.2, and it is at:
    https://confidentialcomputing.io/whitepaper-02-latest

Note that the contents of the PDF have the wrong date, which will be fixed
imminently by the CCC.   It should be dated November 2022, version 1.3.

    > 24) <!-- [rfced] We note that "Example" was listed twice in the title
    > of each appendix. We have updated as follows to avoid redundancy.
    > Please let us know any objections.

    > Original: A.1. Example 1: Timestamp-Based Passport Model Example

    > Current: A.1. Example 1: Timestamp-Based Passport Model -->

no objection.


    > 25) <!-- [rfced] The table in Appendix A does not have a title.  Please
    > review and provide a title for the untitled table if desired.

    > Perhaps: Table 1: Events and Related IDs
    -->

We prefer the title:
   Table 1: Relevants events over time

    > 26) <!-- [rfced] We suggest rearranging parts of this sentence for an
    > improved flow of the text. Does the proposed text change the original
    > meaning of the sentence?

    > Original: Similarly if, based on an Attestation Result from a Verifier
    > it trusts, the Relying Party decides that the Attester can be trusted
    > to correctly provide time deltas, then it can determine whether the
    > Attestation Result is fresh by checking time(OP_r)-time(NS_r) +
    > time(RR_a)-time(EG_a) < Threshold.

    > Perhaps: Similarly, if the Relying Party decides that the Attester can
    > be trusted to correctly provide time deltas based on an Attestation
    > Result from a Verifier it trusts, then it can determine whether the
    > Attestation Result is fresh by checking time(OP_r)-time(NS_r) +
    > time(RR_a)-time(EG_a) < Threshold. -->

We find that it does change the meaning of the sentence, because "based" now
incorrectly applies to "time deltas" rather than "decides", and so we prefer
the original.

    > 27) <!--[rfced] Please review our update to this text to ensure we've
    > retained your intended meaning.


    > Original: The Verifier appraises that the received epoch ID I is
    > "fresh" according to the definition provided in Section 10.3 whereby
    > retries are required in the case of mismatching epoch IDs, and
    > generates an Attestation Result.

    > Current: The Verifier appraises that the received epoch ID I is "fresh"
    > according to the definition provided in Section 10.3 whereby retries
    > are required in the case of mismatching epoch IDs; then the Verifier
    > generates an Attestation Result.
    -->

We are fine with the new "current" text.

okay, more next week.


--
Michael Richardson <[e-mail]>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide