Remote Attestation Procedures (RATS) Endorsements
draft-ietf-rats-endorsements-13

[Ballot comment]
Thanks to Vincent Roca for their secdir review.

Abstract, second para, second sentence:  Consider changing 'extends' to 'updates near the beginning of the sentence.  Also consider removing the phrase, 'as these topics were outside the scope of the rats charter when RFC 9334 was developed'.

Introduction, second para:  Again, I'm not sure whether the information about the charter update is useful, I would consider removing it here too.

Introduction:  What would be useful is a list of changes/additions that this specification provides as an update to RFC 9334.

Introduction, or Sec 2:  Consider adding the definition of 'conceptual messages', since RFC 9334 does not actually define them.  Or reference RFC 9999 (Section 1) where they are defined.

[Ballot comment]
# IESG review of draft-ietf-rats-endorsements-11

CC @MikeBishop

## Comments

### Section 5, paragraph 4

In addition to the Verifier needing to consider conflicting
Endorsements, isn't there a risk that someone selectively presents only the
older Endorsement?

### Inclusive language

#### Section 8, paragraph 3
```
    terminating within the appraisal session context, to avoid man-in-
    the-middle attacks.  Minimizing the use of intermediaries is also
```
RFC Editor style prefers "on-path attacker"; see
https://www.rfc-editor.org/part2/#inclusive_language for background and more
guidance.

## Nits

All comments below are about very minor potential issues that you may choose to
address in some way - or ignore - as you see fit. Some were flagged by
automated tools (via https://github.com/larseggert/ietf-reviewtool), so there
will likely be some false positives. There is no need to let me know what you
did with these suggestions.

### Typos

#### "Abstract", paragraph 2
```
-    Endorsements and Reference Values.  Instead, it extends RFC9334 to
+    Endorsements and Reference Values.  Instead, it extends RFC 9334 to
+                                                              +
```

#### "Abstract", paragraph 2
```
-    these topics were outside the scope of the RATS charter when RFC9334
+    these topics were outside the scope of the RATS charter when RFC 9334
+                                                                    +
```

### Section 2, paragraph 1
```
    state of an Attester includes its "shape", i.e., the structural
```
This is the only use of "shape" in this document; maybe just "includes the structural..."?

### Section 8, paragraph 1
```
    The binding from an Endorsement to a given Target Environment is done
    as discussed in Section 4 of this document.
```
This seems more like Section 6. Is this correct?

### Grammar/style

#### Section 2, paragraph 1
```
deployed software, firmware, and micro-code), static and dynamic configurati
                                ^^^^^^^^^^
```
This word is normally spelled as one.

#### Section 5, paragraph 5
```
aims about that Target Environment. Thus each Target Environment (application
                                    ^^^^
```
A comma may be missing after the conjunctive/linking adverb "Thus".

## Notes

This review is in the ["IETF Comments" Markdown format][ICMF]. You can use the
[`ietf-comments` tool][ICT] to automatically convert this review into
individual GitHub issues. Review generated by the [`ietf-reviewtool`][IRT].

[ICMF]: https://github.com/mnot/ietf-comments/blob/main/format.md
[ICT]: https://github.com/mnot/ietf-comments
[IRT]: https://github.com/larseggert/ietf-reviewtool

[Ballot comment]
Hi Dave, Henk, and Thomas,

Thank you for the effort put into this document.

Thanks also to Jen for the OPSDIR review.

Please find below some few comments:

# Suggest to delete process/charter details from the document

# Make it clear the update does not change any part of the arch document; it is more a zoom on some aspects.

# For authors convenience, I sent a PR with few suggestions: https://github.com/ietf-rats-wg/rats-endorsements/pull/94. Feel free to grab whatever useful.

Cheers,
Med

[Ballot comment]
** Ketan raises a good point about the use of the updates tag, and subsequent use of "extends".

** Section 6
  When Target Environments from different vendors each have their own
  Endorser, a Verifier must be able to distinguish which Endorser is
  allowed to provide an Endorsement about which Target Environment.
  … 
  The
  binding between Target Environment and Endorser might be part of the
  Appraisal Policy for Evidence, or might be specified as part of the
  Evidence itself (e.g., claims from a Target Environment might include
  an identifier of what Endorser can provide additional claims about
  it), or some combination of the two.

Considering this caution that Verifiers need to be able to distinguish which Endorser is applicable for a given Target Environment, how can the Evidence carry the binding between the Target Environment/Endorser?  This would imply that the Verifier would already have to trust the Endorser.  It seems like this binding could only come from the Appraisal Policy which is independent of the Endorser/TE/Evidence.

[Ballot comment]
I have no objection to this document being published as an RFC.
Many thanks to Jim Fenton for the ARTART review, and thanks to the authors for engaging with him to address his concerns.

[Ballot comment]
Thanks to the authors and the WG for their work on this document.

Please find below a couple of comments/suggestions inline in the idnits output of
v11 of this document. The end of the review is marked by the tag

24   This document does not aim to define a conceptual message format for
25   Endorsements and Reference Values.  Instead, it extends RFC9334 to
26   provide further details on Reference Values and Endorsements, as
27   these topics were outside the scope of the RATS charter when RFC9334
28   was developed.

Suggest dropping the charter history from the Abstract; it dates
quickly there, and the Introduction already carries it.

24   This document does not aim to define a conceptual message format for
25   Endorsements and Reference Values.  Instead, it extends RFC9334 to
26   provide further details on Reference Values and Endorsements, as
27   these topics were outside the scope of the RATS charter when RFC9334
28   was developed.

The document carries "Updates: 9334", but neither the Abstract nor the
Introduction says what in RFC 9334 is changed; both describe it as extending
RFC 9334 with further detail. If the relationship is intended, suggest saying
in each what a reader of RFC 9334 now reads alongside it; if the document only
adds detail that Section 8 of RFC 9334 leaves to other specifications, perhaps
the header is not needed. Please correct me if I am reading this wrong.

The following Last Call announcement was sent out (ends 2026-09-07):

From: The IESG
To: IETF-Announce
CC: draft-ietf-rats-endorsements@ietf.org, ned.smith.ietf@outlook.com, rats-chairs@ietf.org, rats@ietf.org, stndrds-inacio@andrew.cmu.edu, yogesh.deshpande@arm.com
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (RATS Endorsements) to Informational RFC


The IESG has received a request from the Remote ATtestation ProcedureS WG
(rats) to consider the following document: - 'RATS Endorsements'
  as Informational RFC

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-call@ietf.org mailing lists by 2026-09-07. Exceptionally, comments may
be sent to iesg@ietf.org instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

Abstract


  In the IETF Remote Attestation Procedures (RATS) architecture, a
  Verifier accepts Evidence and uses Appraisal Policy for Evidence,
  typically with additional input from Endorsements and Reference
  Values, to generate Attestation Results in formats that are useful
  for Relying Parties.  This document illustrates the purpose and role
  of Endorsements and discusses some considerations in the choice of
  message format for Endorsements in the scope of the RATS
  architecture.

  This document does not aim to define a conceptual message format for
  Endorsements and Reference Values.  Instead, it extends RFC9334 to
  provide further details on Reference Values and Endorsements, as
  these topics were outside the scope of the RATS charter when RFC9334
  was developed.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-rats-endorsements/



No IPR declarations have been submitted directly on this I-D.

# Document Shepherd Write-Up for Group Documents

*This version is dated 4 July 2022.*

## Document History

1. Does the working group (WG) consensus represent the strong concurrence of a
  few individuals, with others being silent, or did it reach broad agreement?
The WG reached a broad agreement, as the subject is valuable to the RATS WG now that RATS Reference Values and Endorsements are within the charter.

2. Was there controversy about particular points, or were there decisions where
  the consensus was particularly rough?

There was a total concensus on the technical aspects present in the document.
Though there was a rough concensus on where the material presented in the document should reside.
Few experts suggested it to be part of RFC9334-bis but this idea was turned down eventually.
 

3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If
  so, please summarize the areas of conflict in separate email messages to the
  responsible Area Director. (It should be in a separate email because this
  questionnaire is publicly available)

None to the knowledge of the Shepherd.

4. For protocol documents, are there existing implementations of the contents of
  the document? Have a significant number of potential implementers indicated
  plans to implement? Are any existing implementations reported somewhere,
  either in the document itself (as [RFC 7942][3] recommends) or elsewhere
  (where)?
The Rats Endorsement document is an Informational RFC, so there is not a direct implementation applicable to this standard.
However matching of Evidence to Reference Values can be seen in open source project Veraison - https://github.com:veraison


## Additional Reviews

5. Do the contents of this document closely interact with technologies in other
  IETF working groups or external organizations, and would it therefore benefit
  from their review? Have those reviews occurred? If yes, describe which
  reviews took place.
ONLY Shepherd Review has been undertaken so far.

The document is applicable to Security Feature Remote Attestation.

Security Considerations: It is important that the Security Considerations section adequately reflects any security impacts associated with endorsement formats and interpretation, especially how endorsement claim semantics impact verifier trust decisions. This review area has been conducted by WG reviews.

Protocol Interaction: While the draft is informational and does not specify protocols directly, it interacts with other RATS documents (e.g., evidence formats, appraisal policies). The Shepherd has reviewed for high-level consistency.

The Shepherd is not aware of any required formal outside expert reviews (e.g., AAA, DNS) necessary for this informational document.


6. Describe how the document meets any required formal expert review criteria,
  such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.
Not Applicable

7. If the document contains a YANG module, has the final version of the module
  been checked with any of the [recommended validation tools][4] for syntax and
  formatting validation? If there are any resulting errors or warnings, what is
  the justification for not fixing them at this time? Does the YANG module
  comply with the Network Management Datastore Architecture (NMDA) as specified
  in [RFC 8342][5]?
This aspect is not applicable

8. Describe reviews and automated checks performed to validate sections of the
  final version of the document written in a formal language, such as XML code,
  BNF rules, MIB definitions, CBOR's CDDL, etc.

The Datatracker page links an ID Nits check;
ID-Nits tool was run post publication of the 09 revision.
It shows no major error or flaws in the document.



## Document Shepherd Checks

9. Based on the shepherd's review of the document, is it their opinion that this
  document is needed, clearly written, complete, correctly designed, and ready
  to be handed off to the responsible Area Director?

The shepherd had a detailed review of the version 08 document on 06th February 2026.
The details of the Review were tracked via issue: https://github.com/ietf-rats-wg/rats-endorsements/issues/67 and comments emailed to RATS  mailing list.

Major comments on Document Clarity and Security and Privacy Considerations were raised by the Shepherd review. The Authors worked upon the Review Comments and a new Draft Version 09 with all comments incorporated have now been published.
As a document Shepherd, I have personally verified that the comments during the review have been addressed.

The document is clearly needed, it is clearly written, complete and ready to handed off to next stage of reviews.
Given the security relevant nature of RATS Reference Values and Endorsements, a , secdir review is recommended; iotdir and opsdir may also be useful for deployment aspects.
 

10. Several IETF Areas have assembled [lists of common issues that their
    reviewers encounter][6]. For which areas have such issues been identified
    and addressed? For which does this still need to happen in subsequent
    reviews?

11. What type of RFC publication is being requested on the IETF stream ([Best
    Current Practice][12], [Proposed Standard, Internet Standard][13],
    [Informational, Experimental or Historic][14])? Why is this the proper type
    of RFC? Do all Datatracker state attributes correctly reflect this intent?

The document is an Extension of RFC 9334, and hence on an Informational Track

12. Have reasonable efforts been made to remind all authors of the intellectual
    property rights (IPR) disclosure obligations described in [BCP 79][7]? To
    the best of your knowledge, have all required disclosures been filed? If
    not, explain why. If yes, summarize any relevant discussion, including links
    to publicly-available messages when applicable.

The draft includes the standard BCP 78/79 notices. The Shepherd has obtained via email to Authors Mailing list explicit IPR confirmation from all authors.
Each author has confirmed NO Knowledge of any IPR for this document. T
he Datatracker page for this draft does not list an AD or IESG state yet; the page includes the IPR link (no disclosures are visible there at the time of this write up).


13. Has each author, editor, and contributor shown their willingness to be
    listed as such? If the total number of authors and editors on the front page
    is greater than five, please provide a justification.
Yes, individual explicit email approval of been listed as authors been sought with individual authors.

14. Document any remaining I-D nits in this document. Simply running the [idnits
    tool][8] is not enough; please review the ["Content Guidelines" on
    authors.ietf.org][15]. (Also note that the current idnits tool generates
    some incorrect warnings; a rewrite is underway.)
This will be completed during the subsequent review phase

15. Should any informative references be normative or vice-versa? See the [IESG
    Statement on Normative and Informative References][16].

16. List any normative references that are not freely available to anyone. Did
    the community have sufficient access to review any such normative
    references?
None exist at the moment.

17. Are there any normative downward references (see [RFC 3967][9] and [BCP
    97][10]) that are not already listed in the [DOWNREF registry][17]? If so,
    list them.
The RATS endorsements draft is informational and the referenced documents are also informational, and are referenced as information, so there is no downref (e.g. an informative document referenced as normative). 

18. Are there normative references to documents that are not ready to be
    submitted to the IESG for publication or are otherwise in an unclear state?
    If so, what is the plan for their completion?

19. Will publication of this document change the status of any existing RFCs? If
    so, does the Datatracker metadata correctly reflect this and are those RFCs
    listed on the title page, in the abstract, and discussed in the
    introduction? If not, explain why and point to the part of the document
    where the relationship of this document to these other RFCs is discussed.

20. Describe the document shepherd's review of the IANA considerations section,
    especially with regard to its consistency with the body of the document.
    Confirm that all aspects of the document requiring IANA assignments are
    associated with the appropriate reservations in IANA registries. Confirm
    that any referenced IANA registries have been clearly identified. Confirm
    that each newly created IANA registry specifies its initial contents,
    allocations procedures, and a reasonable name (see [RFC 8126][11]).

The document has no IANA request to be made

21. List any new IANA registries that require Designated Expert Review for
    future allocations. Are the instructions to the Designated Expert clear?
    Please include suggestions of designated experts, if appropriate.

The document has no IANA request to be made

# Document Shepherd Write-Up for Group Documents

*This version is dated 4 July 2022.*

## Document History

1. Does the working group (WG) consensus represent the strong concurrence of a
  few individuals, with others being silent, or did it reach broad agreement?
The WG reached a broad agreement, as the subject is valuable to the RATS WG now that RATS Reference Values and Endorsements are within the charter.

2. Was there controversy about particular points, or were there decisions where
  the consensus was particularly rough?

There was a total concensus on the technical aspects present in the document.
Though there was a rough concensus on where the material presented in the document should reside.
Few experts suggested it to be part of RFC9334-bis but this idea was turned down eventually.
 

3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If
  so, please summarize the areas of conflict in separate email messages to the
  responsible Area Director. (It should be in a separate email because this
  questionnaire is publicly available)

None to the knowledge of the Shepherd.

4. For protocol documents, are there existing implementations of the contents of
  the document? Have a significant number of potential implementers indicated
  plans to implement? Are any existing implementations reported somewhere,
  either in the document itself (as [RFC 7942][3] recommends) or elsewhere
  (where)?
The Rats Endorsement document is an Informational RFC, so there is not a direct implementation applicable to this standard.
However matching of Evidence to Reference Values can be seen in open source project Veraison - https://github.com:veraison


## Additional Reviews

5. Do the contents of this document closely interact with technologies in other
  IETF working groups or external organizations, and would it therefore benefit
  from their review? Have those reviews occurred? If yes, describe which
  reviews took place.
ONLY Shepherd Review has been undertaken so far.

The document is applicable to Security Feature Remote Attestation.

Security Considerations: It is important that the Security Considerations section adequately reflects any security impacts associated with endorsement formats and interpretation, especially how endorsement claim semantics impact verifier trust decisions. This review area has been conducted by WG reviews.

Protocol Interaction: While the draft is informational and does not specify protocols directly, it interacts with other RATS documents (e.g., evidence formats, appraisal policies). The Shepherd has reviewed for high-level consistency.

The Shepherd is not aware of any required formal outside expert reviews (e.g., AAA, DNS) necessary for this informational document.


6. Describe how the document meets any required formal expert review criteria,
  such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.
Not Applicable

7. If the document contains a YANG module, has the final version of the module
  been checked with any of the [recommended validation tools][4] for syntax and
  formatting validation? If there are any resulting errors or warnings, what is
  the justification for not fixing them at this time? Does the YANG module
  comply with the Network Management Datastore Architecture (NMDA) as specified
  in [RFC 8342][5]?
This aspect is not applicable

8. Describe reviews and automated checks performed to validate sections of the
  final version of the document written in a formal language, such as XML code,
  BNF rules, MIB definitions, CBOR's CDDL, etc.

The Datatracker page links an ID Nits check;
ID-Nits tool was run post publication of the 09 revision.
It shows no major error or flaws in the document.



## Document Shepherd Checks

9. Based on the shepherd's review of the document, is it their opinion that this
  document is needed, clearly written, complete, correctly designed, and ready
  to be handed off to the responsible Area Director?

The shepherd had a detailed review of the version 08 document on 06th February 2026.
The details of the Review were tracked via issue: https://github.com/ietf-rats-wg/rats-endorsements/issues/67 and comments emailed to RATS  mailing list.

Major comments on Document Clarity and Security and Privacy Considerations were raised by the Shepherd review. The Authors worked upon the Review Comments and a new Draft Version 09 with all comments incorporated have now been published.
As a document Shepherd, I have personally verified that the comments during the review have been addressed.

The document is clearly needed, it is clearly written, complete and ready to handed off to next stage of reviews.
Given the security relevant nature of RATS Reference Values and Endorsements, a , secdir review is recommended; iotdir and opsdir may also be useful for deployment aspects.
 

10. Several IETF Areas have assembled [lists of common issues that their
    reviewers encounter][6]. For which areas have such issues been identified
    and addressed? For which does this still need to happen in subsequent
    reviews?

11. What type of RFC publication is being requested on the IETF stream ([Best
    Current Practice][12], [Proposed Standard, Internet Standard][13],
    [Informational, Experimental or Historic][14])? Why is this the proper type
    of RFC? Do all Datatracker state attributes correctly reflect this intent?

The document is an Extension of RFC 9334, and hence on an Informational Track

12. Have reasonable efforts been made to remind all authors of the intellectual
    property rights (IPR) disclosure obligations described in [BCP 79][7]? To
    the best of your knowledge, have all required disclosures been filed? If
    not, explain why. If yes, summarize any relevant discussion, including links
    to publicly-available messages when applicable.

The draft includes the standard BCP 78/79 notices. The Shepherd has obtained via email to Authors Mailing list explicit IPR confirmation from all authors.
Each author has confirmed NO Knowledge of any IPR for this document. T
he Datatracker page for this draft does not list an AD or IESG state yet; the page includes the IPR link (no disclosures are visible there at the time of this write up).


13. Has each author, editor, and contributor shown their willingness to be
    listed as such? If the total number of authors and editors on the front page
    is greater than five, please provide a justification.
Yes, individual explicit email approval of been listed as authors been sought with individual authors.

14. Document any remaining I-D nits in this document. Simply running the [idnits
    tool][8] is not enough; please review the ["Content Guidelines" on
    authors.ietf.org][15]. (Also note that the current idnits tool generates
    some incorrect warnings; a rewrite is underway.)
This will be completed during the subsequent review phase

15. Should any informative references be normative or vice-versa? See the [IESG
    Statement on Normative and Informative References][16].

16. List any normative references that are not freely available to anyone. Did
    the community have sufficient access to review any such normative
    references?
None exist at the moment.

17. Are there any normative downward references (see [RFC 3967][9] and [BCP
    97][10]) that are not already listed in the [DOWNREF registry][17]? If so,
    list them.
The RATS endorsements draft is informational and the referenced documents are also informational, and are referenced as information, so there is no downref (e.g. an informative document referenced as normative). 

18. Are there normative references to documents that are not ready to be
    submitted to the IESG for publication or are otherwise in an unclear state?
    If so, what is the plan for their completion?

19. Will publication of this document change the status of any existing RFCs? If
    so, does the Datatracker metadata correctly reflect this and are those RFCs
    listed on the title page, in the abstract, and discussed in the
    introduction? If not, explain why and point to the part of the document
    where the relationship of this document to these other RFCs is discussed.

20. Describe the document shepherd's review of the IANA considerations section,
    especially with regard to its consistency with the body of the document.
    Confirm that all aspects of the document requiring IANA assignments are
    associated with the appropriate reservations in IANA registries. Confirm
    that any referenced IANA registries have been clearly identified. Confirm
    that each newly created IANA registry specifies its initial contents,
    allocations procedures, and a reasonable name (see [RFC 8126][11]).

The document has no IANA request to be made

21. List any new IANA registries that require Designated Expert Review for
    future allocations. Are the instructions to the Designated Expert clear?
    Please include suggestions of designated experts, if appropriate.

The document has no IANA request to be made

# Document Shepherd Write-Up for Group Documents

*This version is dated 4 July 2022.*

## Document History

1. Does the working group (WG) consensus represent the strong concurrence of a
  few individuals, with others being silent, or did it reach broad agreement?
The WG reached a broad agreement, as the subject is valuable to the RATS WG now that RATS Reference Values and Endorsements are within the charter.

2. Was there controversy about particular points, or were there decisions where
  the consensus was particularly rough?

There was a total concensus on the technical aspects present in the document.
Though there was a rough concensus on where the material presented in the document should reside.
Few experts suggested it to be part of RFC9334-bis but this idea was turned down eventually.
 

3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If
  so, please summarize the areas of conflict in separate email messages to the
  responsible Area Director. (It should be in a separate email because this
  questionnaire is publicly available)

None to the knowledge of the Shepherd.

4. For protocol documents, are there existing implementations of the contents of
  the document? Have a significant number of potential implementers indicated
  plans to implement? Are any existing implementations reported somewhere,
  either in the document itself (as [RFC 7942][3] recommends) or elsewhere
  (where)?
The Rats Endorsement document is an Informational RFC, so there is not a direct implementation applicable to this standard.
However matching of Evidence to Reference Values can be seen in open source project Veraison - https://github.com:veraison


## Additional Reviews

5. Do the contents of this document closely interact with technologies in other
  IETF working groups or external organizations, and would it therefore benefit
  from their review? Have those reviews occurred? If yes, describe which
  reviews took place.
ONLY Shepherd Review has been undertaken so far.

The document is applicable to Security Feature Remote Attestation.

Security Considerations: It is important that the Security Considerations section adequately reflects any security impacts associated with endorsement formats and interpretation, especially how endorsement claim semantics impact verifier trust decisions. This review area has been conducted by WG reviews.

Protocol Interaction: While the draft is informational and does not specify protocols directly, it interacts with other RATS documents (e.g., evidence formats, appraisal policies). The Shepherd has reviewed for high-level consistency.

The Shepherd is not aware of any required formal outside expert reviews (e.g., AAA, DNS) necessary for this informational document.


6. Describe how the document meets any required formal expert review criteria,
  such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.
Not Applicable

7. If the document contains a YANG module, has the final version of the module
  been checked with any of the [recommended validation tools][4] for syntax and
  formatting validation? If there are any resulting errors or warnings, what is
  the justification for not fixing them at this time? Does the YANG module
  comply with the Network Management Datastore Architecture (NMDA) as specified
  in [RFC 8342][5]?
This aspect is not applicable

8. Describe reviews and automated checks performed to validate sections of the
  final version of the document written in a formal language, such as XML code,
  BNF rules, MIB definitions, CBOR's CDDL, etc.

The Datatracker page links an ID Nits check;
ID-Nits tool was run post publication of the 09 revision.
It shows no major error or flaws in the document.



## Document Shepherd Checks

9. Based on the shepherd's review of the document, is it their opinion that this
  document is needed, clearly written, complete, correctly designed, and ready
  to be handed off to the responsible Area Director?

The shepherd had a detailed review of the version 08 document on 06th February 2026.
The details of the Review were tracked via issue: https://github.com/ietf-rats-wg/rats-endorsements/issues/67 and comments emailed to RATS  mailing list.

Major comments on Document Clarity and Security and Privacy Considerations were raised by the Shepherd review. The Authors worked upon the Review Comments and a new Draft Version 09 with all comments incorporated have now been published.
As a document Shepherd, I have personally verified that the comments during the review have been addressed.

The document is clearly needed, it is clearly written, complete and ready to handed off to next stage of reviews.
Given the security relevant nature of RATS Reference Values and Endorsements, a , secdir review is recommended; iotdir and opsdir may also be useful for deployment aspects.
 

10. Several IETF Areas have assembled [lists of common issues that their
    reviewers encounter][6]. For which areas have such issues been identified
    and addressed? For which does this still need to happen in subsequent
    reviews?

11. What type of RFC publication is being requested on the IETF stream ([Best
    Current Practice][12], [Proposed Standard, Internet Standard][13],
    [Informational, Experimental or Historic][14])? Why is this the proper type
    of RFC? Do all Datatracker state attributes correctly reflect this intent?

The document is an Extension of RFC 9334, and hence on an Informational Track

12. Have reasonable efforts been made to remind all authors of the intellectual
    property rights (IPR) disclosure obligations described in [BCP 79][7]? To
    the best of your knowledge, have all required disclosures been filed? If
    not, explain why. If yes, summarize any relevant discussion, including links
    to publicly-available messages when applicable.

The draft includes the standard BCP 78/79 notices. The Shepherd has obtained via email to Authors Mailing list explicit IPR confirmation from all authors.
Each author has confirmed NO Knowledge of any IPR for this document. T
he Datatracker page for this draft does not list an AD or IESG state yet; the page includes the IPR link (no disclosures are visible there at the time of this write up).


13. Has each author, editor, and contributor shown their willingness to be
    listed as such? If the total number of authors and editors on the front page
    is greater than five, please provide a justification.
Yes, individual explicit email approval of been listed as authors been sought with individual authors.

14. Document any remaining I-D nits in this document. Simply running the [idnits
    tool][8] is not enough; please review the ["Content Guidelines" on
    authors.ietf.org][15]. (Also note that the current idnits tool generates
    some incorrect warnings; a rewrite is underway.)
This will be completed during the subsequent review phase

15. Should any informative references be normative or vice-versa? See the [IESG
    Statement on Normative and Informative References][16].

16. List any normative references that are not freely available to anyone. Did
    the community have sufficient access to review any such normative
    references?
None exist at the moment.

17. Are there any normative downward references (see [RFC 3967][9] and [BCP
    97][10]) that are not already listed in the [DOWNREF registry][17]? If so,
    list them.
The RATS endorsements draft is informational and the referenced documents are also informational, and are referenced as information, so there is no downref (e.g. an informative document referenced as normative). 

18. Are there normative references to documents that are not ready to be
    submitted to the IESG for publication or are otherwise in an unclear state?
    If so, what is the plan for their completion?

19. Will publication of this document change the status of any existing RFCs? If
    so, does the Datatracker metadata correctly reflect this and are those RFCs
    listed on the title page, in the abstract, and discussed in the
    introduction? If not, explain why and point to the part of the document
    where the relationship of this document to these other RFCs is discussed.

20. Describe the document shepherd's review of the IANA considerations section,
    especially with regard to its consistency with the body of the document.
    Confirm that all aspects of the document requiring IANA assignments are
    associated with the appropriate reservations in IANA registries. Confirm
    that any referenced IANA registries have been clearly identified. Confirm
    that each newly created IANA registry specifies its initial contents,
    allocations procedures, and a reasonable name (see [RFC 8126][11]).

The document has no IANA request to be made

21. List any new IANA registries that require Designated Expert Review for
    future allocations. Are the instructions to the Designated Expert clear?
    Please include suggestions of designated experts, if appropriate.

The document has no IANA request to be made

Shepherd’s Concerns (if any)

Note there is ONE Concern that needs to be resolved before this document becoming an RFC.

RFC 9334 is added to the downref list, which implies that it can be referenced Normatively.

RATS Endorsement Document is an extension of RFC 9334 and this document refers to RFC9334.
Hence RATS Endorsement Document MUST be added to Downref List.
Or otherwise, it cannot be refereced Normatively (as it is an extension of RFC9334).

The draft is ready to progress and just needs the shepherd report to be updated to reflect that there are no downrefs to avoid any confusion.

# Document Shepherd Write-Up for Group Documents

*This version is dated 4 July 2022.*

## Document History

1. Does the working group (WG) consensus represent the strong concurrence of a
  few individuals, with others being silent, or did it reach broad agreement?
The WG reached a broad agreement, as the subject is valuable to the RATS WG now that RATS Reference Values and Endorsements are within the charter.

2. Was there controversy about particular points, or were there decisions where
  the consensus was particularly rough?

There was a total concensus on the technical aspects present in the document.
Though there was a rough concensus on where the material presented in the document should reside.
Few experts suggested it to be part of RFC9334-bis but this idea was turned down eventually.
 

3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If
  so, please summarize the areas of conflict in separate email messages to the
  responsible Area Director. (It should be in a separate email because this
  questionnaire is publicly available)

None to the knowledge of the Shepherd.

4. For protocol documents, are there existing implementations of the contents of
  the document? Have a significant number of potential implementers indicated
  plans to implement? Are any existing implementations reported somewhere,
  either in the document itself (as [RFC 7942][3] recommends) or elsewhere
  (where)?
The Rats Endorsement document is an Informational RFC, so there is not a direct implementation applicable to this standard.
However matching of Evidence to Reference Values can be seen in open source project Veraison - https://github.com:veraison


## Additional Reviews

5. Do the contents of this document closely interact with technologies in other
  IETF working groups or external organizations, and would it therefore benefit
  from their review? Have those reviews occurred? If yes, describe which
  reviews took place.
ONLY Shepherd Review has been undertaken so far.

The document is applicable to Security Feature Remote Attestation.

Security Considerations: It is important that the Security Considerations section adequately reflects any security impacts associated with endorsement formats and interpretation, especially how endorsement claim semantics impact verifier trust decisions. This review area has been conducted by WG reviews.

Protocol Interaction: While the draft is informational and does not specify protocols directly, it interacts with other RATS documents (e.g., evidence formats, appraisal policies). The Shepherd has reviewed for high-level consistency.

The Shepherd is not aware of any required formal outside expert reviews (e.g., AAA, DNS) necessary for this informational document.


6. Describe how the document meets any required formal expert review criteria,
  such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.
Not Applicable

7. If the document contains a YANG module, has the final version of the module
  been checked with any of the [recommended validation tools][4] for syntax and
  formatting validation? If there are any resulting errors or warnings, what is
  the justification for not fixing them at this time? Does the YANG module
  comply with the Network Management Datastore Architecture (NMDA) as specified
  in [RFC 8342][5]?
This aspect is not applicable

8. Describe reviews and automated checks performed to validate sections of the
  final version of the document written in a formal language, such as XML code,
  BNF rules, MIB definitions, CBOR's CDDL, etc.

The Datatracker page links an ID Nits check;
ID-Nits tool was run post publication of the 09 revision.
It shows no major error or flaws in the document.



## Document Shepherd Checks

9. Based on the shepherd's review of the document, is it their opinion that this
  document is needed, clearly written, complete, correctly designed, and ready
  to be handed off to the responsible Area Director?

The shepherd had a detailed review of the version 08 document on 06th February 2026.
The details of the Review were tracked via issue: https://github.com/ietf-rats-wg/rats-endorsements/issues/67 and comments emailed to RATS  mailing list.

Major comments on Document Clarity and Security and Privacy Considerations were raised by the Shepherd review. The Authors worked upon the Review Comments and a new Draft Version 09 with all comments incorporated have now been published.
As a document Shepherd, I have personally verified that the comments during the review have been addressed.

The document is clearly needed, it is clearly written, complete and ready to handed off to next stage of reviews.
Given the security relevant nature of RATS Reference Values and Endorsements, a , secdir review is recommended; iotdir and opsdir may also be useful for deployment aspects.
 

10. Several IETF Areas have assembled [lists of common issues that their
    reviewers encounter][6]. For which areas have such issues been identified
    and addressed? For which does this still need to happen in subsequent
    reviews?

11. What type of RFC publication is being requested on the IETF stream ([Best
    Current Practice][12], [Proposed Standard, Internet Standard][13],
    [Informational, Experimental or Historic][14])? Why is this the proper type
    of RFC? Do all Datatracker state attributes correctly reflect this intent?

The document is an Extension of RFC 9334, and hence on an Informational Track

12. Have reasonable efforts been made to remind all authors of the intellectual
    property rights (IPR) disclosure obligations described in [BCP 79][7]? To
    the best of your knowledge, have all required disclosures been filed? If
    not, explain why. If yes, summarize any relevant discussion, including links
    to publicly-available messages when applicable.

The draft includes the standard BCP 78/79 notices. The Shepherd has obtained via email to Authors Mailing list explicit IPR confirmation from all authors.
Each author has confirmed NO Knowledge of any IPR for this document. T
he Datatracker page for this draft does not list an AD or IESG state yet; the page includes the IPR link (no disclosures are visible there at the time of this write up).


13. Has each author, editor, and contributor shown their willingness to be
    listed as such? If the total number of authors and editors on the front page
    is greater than five, please provide a justification.
Yes, individual explicit email approval of been listed as authors been sought with individual authors.

14. Document any remaining I-D nits in this document. Simply running the [idnits
    tool][8] is not enough; please review the ["Content Guidelines" on
    authors.ietf.org][15]. (Also note that the current idnits tool generates
    some incorrect warnings; a rewrite is underway.)
This will be completed during the subsequent review phase

15. Should any informative references be normative or vice-versa? See the [IESG
    Statement on Normative and Informative References][16].

16. List any normative references that are not freely available to anyone. Did
    the community have sufficient access to review any such normative
    references?
None exist at the moment.

17. Are there any normative downward references (see [RFC 3967][9] and [BCP
    97][10]) that are not already listed in the [DOWNREF registry][17]? If so,
    list them.
A final downref check will be performed when references are finalized; no specific downrefs have been flagged in WG discussion to date. 

18. Are there normative references to documents that are not ready to be
    submitted to the IESG for publication or are otherwise in an unclear state?
    If so, what is the plan for their completion?

19. Will publication of this document change the status of any existing RFCs? If
    so, does the Datatracker metadata correctly reflect this and are those RFCs
    listed on the title page, in the abstract, and discussed in the
    introduction? If not, explain why and point to the part of the document
    where the relationship of this document to these other RFCs is discussed.

20. Describe the document shepherd's review of the IANA considerations section,
    especially with regard to its consistency with the body of the document.
    Confirm that all aspects of the document requiring IANA assignments are
    associated with the appropriate reservations in IANA registries. Confirm
    that any referenced IANA registries have been clearly identified. Confirm
    that each newly created IANA registry specifies its initial contents,
    allocations procedures, and a reasonable name (see [RFC 8126][11]).

The document has no IANA request to be made

21. List any new IANA registries that require Designated Expert Review for
    future allocations. Are the instructions to the Designated Expert clear?
    Please include suggestions of designated experts, if appropriate.

The document has no IANA request to be made

Shepherd’s Concerns (if any)

Note there is ONE Concern that needs to be resolved before this document becoming an RFC.

RFC 9334 is added to the downref list, which implies that it can be referenced Normatively.

RATS Endorsement Document is an extension of RFC 9334 and this document refers to RFC9334.
Hence RATS Endorsement Document MUST be added to Downref List.
Or otherwise, it cannot be refereced Normatively (as it is an extension of RFC9334).

# Document Shepherd Write-Up for Group Documents

*This version is dated 4 July 2022.*

## Document History

1. Does the working group (WG) consensus represent the strong concurrence of a
  few individuals, with others being silent, or did it reach broad agreement?
The WG reached a broad agreement, as the subject is valuable to the RATS WG now that RATS Reference Values and Endorsements are within the charter.

2. Was there controversy about particular points, or were there decisions where
  the consensus was particularly rough?
  There was a total concensus on the technical aspects present in the document.
  Though there was a rough concensus on where the material presented in the document should reside.
  Few experts suggested it to be part of RFC9334-bis but this idea was turned down eventually.
 

3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If
  so, please summarize the areas of conflict in separate email messages to the
  responsible Area Director. (It should be in a separate email because this
  questionnaire is publicly available.)
None to the knowledge of the Shepherd.

4. For protocol documents, are there existing implementations of the contents of
  the document? Have a significant number of potential implementers indicated
  plans to implement? Are any existing implementations reported somewhere,
  either in the document itself (as [RFC 7942][3] recommends) or elsewhere
  (where)?
The Rats Endorsement document is an Informational RFC, so there is not a direct implementation applicable to this standard.
However matching of Evidence to Reference Values can be seen in open source project Veraison - https://github.com:veraison


## Additional Reviews

5. Do the contents of this document closely interact with technologies in other
  IETF working groups or external organizations, and would it therefore benefit
  from their review? Have those reviews occurred? If yes, describe which
  reviews took place.
ONLY Shepherd Review has been undertaken so far.

The document is applicable to Security Feature Remote Attestation.

Security Considerations: It is important that the Security Considerations section adequately reflects any security impacts associated with endorsement formats and interpretation, especially how endorsement claim semantics impact verifier trust decisions. This review area has been conducted by WG reviews.

Protocol Interaction: While the draft is informational and does not specify protocols directly, it interacts with other RATS documents (e.g., evidence formats, appraisal policies). The Shepherd has reviewed for high-level consistency.

The Shepherd is not aware of any required formal outside expert reviews (e.g., AAA, DNS) necessary for this informational document.


6. Describe how the document meets any required formal expert review criteria,
  such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.
Not Applicable

7. If the document contains a YANG module, has the final version of the module
  been checked with any of the [recommended validation tools][4] for syntax and
  formatting validation? If there are any resulting errors or warnings, what is
  the justification for not fixing them at this time? Does the YANG module
  comply with the Network Management Datastore Architecture (NMDA) as specified
  in [RFC 8342][5]?
This aspect is not applicable

8. Describe reviews and automated checks performed to validate sections of the
  final version of the document written in a formal language, such as XML code,
  BNF rules, MIB definitions, CBOR's CDDL, etc.

The Datatracker page links an ID Nits check;
ID-Nits tool was run post publication of the 09 revision.
It shows no major error or flaws in the document.



## Document Shepherd Checks

9. Based on the shepherd's review of the document, is it their opinion that this
  document is needed, clearly written, complete, correctly designed, and ready
  to be handed off to the responsible Area Director?

The shepherd had a detailed review of the version 08 document on 06th February 2026.
The details of the Review were tracked via issue: https://github.com/ietf-rats-wg/rats-endorsements/issues/67 and comments emailed to RATS  mailing list.

Major comments on Document Clarity and Security and Privacy Considerations were raised by the Shepherd review. The Authors worked upon the Review Comments and a new Draft Version 09 with all comments incorporated have now been published.
As a document Shepherd, I have personally verified that the comments during the review have been addressed.

The document is clearly needed, it is clearly written, complete and ready to handed off to next stage of reviews.
Given the security relevant nature of RATS Reference Values and Endorsements, a , secdir review is recommended; iotdir and opsdir may also be useful for deployment aspects.
 

10. Several IETF Areas have assembled [lists of common issues that their
    reviewers encounter][6]. For which areas have such issues been identified
    and addressed? For which does this still need to happen in subsequent
    reviews?

11. What type of RFC publication is being requested on the IETF stream ([Best
    Current Practice][12], [Proposed Standard, Internet Standard][13],
    [Informational, Experimental or Historic][14])? Why is this the proper type
    of RFC? Do all Datatracker state attributes correctly reflect this intent?

The document is an Extension of RFC 9334, and hence on an Informational Track

12. Have reasonable efforts been made to remind all authors of the intellectual
    property rights (IPR) disclosure obligations described in [BCP 79][7]? To
    the best of your knowledge, have all required disclosures been filed? If
    not, explain why. If yes, summarize any relevant discussion, including links
    to publicly-available messages when applicable.

The draft includes the standard BCP 78/79 notices. The Shepherd has obtained via email to Authors Mailing list explicit IPR confirmation from all authors.
Each author has confirmed NO Knowledge of any IPR for this document. T
he Datatracker page for this draft does not list an AD or IESG state yet; the page includes the IPR link (no disclosures are visible there at the time of this write up).


13. Has each author, editor, and contributor shown their willingness to be
    listed as such? If the total number of authors and editors on the front page
    is greater than five, please provide a justification.
Yes, individual explicit email approval of been listed as authors been sought with individual authors.

14. Document any remaining I-D nits in this document. Simply running the [idnits
    tool][8] is not enough; please review the ["Content Guidelines" on
    authors.ietf.org][15]. (Also note that the current idnits tool generates
    some incorrect warnings; a rewrite is underway.)
This will be completed during the subsequent review phase

15. Should any informative references be normative or vice-versa? See the [IESG
    Statement on Normative and Informative References][16].

16. List any normative references that are not freely available to anyone. Did
    the community have sufficient access to review any such normative
    references?
None exist at the moment.

17. Are there any normative downward references (see [RFC 3967][9] and [BCP
    97][10]) that are not already listed in the [DOWNREF registry][17]? If so,
    list them.
A final downref check will be performed when references are finalized; no specific downrefs have been flagged in WG discussion to date. 

18. Are there normative references to documents that are not ready to be
    submitted to the IESG for publication or are otherwise in an unclear state?
    If so, what is the plan for their completion?

19. Will publication of this document change the status of any existing RFCs? If
    so, does the Datatracker metadata correctly reflect this and are those RFCs
    listed on the title page, in the abstract, and discussed in the
    introduction? If not, explain why and point to the part of the document
    where the relationship of this document to these other RFCs is discussed.

20. Describe the document shepherd's review of the IANA considerations section,
    especially with regard to its consistency with the body of the document.
    Confirm that all aspects of the document requiring IANA assignments are
    associated with the appropriate reservations in IANA registries. Confirm
    that any referenced IANA registries have been clearly identified. Confirm
    that each newly created IANA registry specifies its initial contents,
    allocations procedures, and a reasonable name (see [RFC 8126][11]).

The document has no IANA request to be made

21. List any new IANA registries that require Designated Expert Review for
    future allocations. Are the instructions to the Designated Expert clear?
    Please include suggestions of designated experts, if appropriate.

The document has no IANA request to be made

Shepherd’s Concerns (if any)

Note there is ONE Concern that needs to be resolved before this document becoming an RFC.

RFC 9334 is added to the downref list, which implies that it can be referenced Normatively.

RATS Endorsement Document is an extension of RFC 9334 and this document refers to RFC9334.
Hence RATS Endorsement Document MUST be added to Downref List.
Or otherwise, it cannot be refereced Normatively (as it is an extension of RFC9334).

Document: draft-ietf-rats-endorsements
Intended Status:  Informational
Working Group: RATS (Remote ATtestation ProcedureS)
Current Version at time of write‑up: -09 (published 2026‑03‑02)


(A) Document Announcement Write‑Up

Technical Summary:
The purpose of this document is to extend RFC9334 to provide further details on Reference Values and Endorsements.

Working Group Summary:
The work originated in RATS as a concrete realization presentation and discussion starting at IETF 116 (March 2023) , with an email from RATS Chairs on Mon, 26 June 2023 18:21 UTC requesting call for adoption. Document was adopted in RATS WG on: 2023-12-01

Document Quality:
The specification has been discussed in multiple WG meetings and has an open GitHub repository referenced from the Datatracker page.

Personnel
Document Shepherd: Yogesh Deshpande
Responsible Area Director:  (TBD at time of write‑up; not yet assigned in Datatracker)

(B) Shepherd’s Detailed Write‑Up (RFC 4858)

1. Summary of the Document

See the Technical Summary above. The intended status is Informational 

2. Document History

Individual Versions exists since March 2023, while the WG adopted the work on 2023-12-01 and the first version draft-ietf-rats-endorsements-00
Was published around the same time frame. Subsequent Versions are
Published with Revision 01 – Dated 2024-06-12
To latest Revision 09 – Dated 2026-03-02

3. Working Group Summary (Degree of Consensus / Controversy)
The topic has received repeated presentations and discussion. The Datatracker entry links to a GitHub repo; The document gained relevance because of RATS Charter been modified to widen the scope to include Reference Values and Endorsements to be included in the charter. There were initial discussions about whether an RFC9334-bis would have been appropriate for this? Though the WG concluded the timeline for a RFC9334-bis was not appropriate as a result, this document, stayed as a separate Informational draft.

4. Document Quality (Reviews / Implementations)

Over the last two years since the document was originally adopted (revision 00) to revision 09, the document has made significant clarity, and 21 issues are resolved via 50 Pull Requests to the document. The Shepherd recommends secdir and iotdir reviews now that the Shepherd Review has been completed.

Shepherd’s Review of the Document:
The shepherd had a detailed review of the version 08 document on 06th February 2026.
The details of the Review were tracked via issue: https://github.com/ietf-rats-wg/rats-endorsements/issues/67 and comments emailed to RATS  mailing list.

Major comments on Document Clarity and Security and Privacy Considerations were raised by the Shepherd review. The Authors worked upon the Review Comments and a new Draft Version 09 with all comments incorporated have now been published.
As a document Shepherd, I have personally verified that the comments during the review have been addressed.

6. Shepherd’s Concerns (if any)
No concerns. Shepherd believes that the further reviews like SecDir and OPSDir or iotDir once complete, review comments MUST be addressed with one more revision cycle post focused reviews.

7. IPR Compliance

The draft includes the standard BCP 78/79 notices. The Shepherd has obtained via email to Authors Mailing list explicit IPR confirmation from all authors . Each author has confirmed NO Knowledge of any IPR for this document. The Datatracker page for this draft does not list an AD or IESG state yet; the page includes the IPR link (no disclosures are visible there at the time of this write‑up).

8. Has anyone threatened an appeal or otherwise indicated extreme discontent?
None to the knowledge of Shepherd

9. How solid is the WG consensus behind the document?
The details of the document are enhancement relevant to the concepts given in  RFC9334 and there were email discussions indicating rough consensus to advance the document further.
10. ID‑Nits
The Datatracker page links an ID‑Nits check;
ID-Nits tool was run post publication of the 09 revision.
It shows no major error or flaws in the document.

11. Formal/Directorate Review Needs
Given the security‑relevant nature of RATS Reference Values and Endorsements, a , secdir review is recommended; iotdir may also be useful for deployment aspects.

12. References (Normative/Informative)
The draft has no Normative References (as it’s an Informational RFC) and has a clear reference to Informative References
13. IANA Considerations
The document has no IANA request to be made
14. New Registries
The document does not create new registries

15. Impact on Existing Registries
Not Applicable
16. Intended Status Justification
The document extends the RFC9334 as an Informational RFC, which is justified

17. Downward References
A final downref check will be performed when references are finalized; no specific downrefs have been flagged in WG discussion to date.

18. Reviews & Shepherd’s Summary of Significant Issues
Significant Issues reported so far have been addressed in revision 09 of the draft.

19. Document Shepherd / Responsible AD
Shepherd: Yogesh Deshpande
Responsible AD: TBC.

20. Additional Notes for the IESG
        None at this point in time