OCSP Usage for Secure Telephone Identity Certificates
draft-ietf-stir-certificates-ocsp-12

IESG/Authors/WG Chairs:

IANA has completed its review of draft-ietf-stir-certificates-ocsp-11. If any part of this review is inaccurate, please let us know.

IANA understands that, upon approval of this document, there are three actions which we must complete.

First, in the SMI Security for PKIX Module Identifier registry in the Structure of Management Information (SMI) Numbers (MIB Module Registrations) registry group located at:

https://www.iana.org/assignments/smi-numbers/

a single registration will be made as follows:

Decimal: [ TBD-at-Registration ]
Description: id-mod-tn-ocsp-module-2023
Reference: [ RFC-to-be ]

As this document requests registrations in an Expert Review or Specification Required (see RFC 8126) registry, we have completed the required Expert Review via a separate request.

Second, in the SMI Security for PKIX Online Certificate Status Protocol (OCSP) registry also in the Structure of Management Information (SMI) Numbers (MIB Module Registrations) registry group located at:

https://www.iana.org/assignments/smi-numbers/

the existing registration for:

Decimal: 10
Description: id-pkix-ocsp-stir-tn

will have its reference changed to [ RFC-to-be ].

Third, in the JSON Web Token Claims registry in the JSON Web Token (JWT) registry group located at:

https://www.iana.org/assignments/jwt/

a single new registration will be made as follows:

Claim Name: stpl
Claim Description: OCSP Staple
Change Controller: IETF
Reference: [ RFC-to-be ]

As this also requests registrations in an Expert Review or Specification Required (see RFC 8126) registry, we have completed the required Expert Review via a separate request.

We understand that these are the only actions required to be completed upon approval of this document.

NOTE: The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed.

For definitions of IANA review states, please see:

https://datatracker.ietf.org/help/state/draft/iana-review

Thank you,

David Dong
IANA Services Sr. Specialist

The following Last Call announcement was sent out (ends 2025-07-28):

From: The IESG
To: IETF-Announce
CC: ben@nostrum.com, draft-ietf-stir-certificates-ocsp@ietf.org, orie@or13.io, stir-chairs@ietf.org, stir@ietf.org
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (OCSP Usage for Secure Telephone Identity Certificates) to Proposed Standard


The IESG has received a request from the Secure Telephone Identity Revisited
WG (stir) to consider the following document: - 'OCSP Usage for Secure
Telephone Identity Certificates'
  as Proposed Standard

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 2025-07-28. 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


  When certificates are used as credentials to attest the assignment or
  ownership of telephone numbers, some mechanism is required to convey
  certificate freshness to relying parties.  Certififcate Revocation
  Lists (CRLs) are commonly used for this purpose, but for certain
  classes of certificates, including delegate certificates conveying
  their scope of authority by-reference in Secure Telephone Identity
  Revisited (STIR) systems, they may not be aligned with the needs of
  relying parties.  This document specifies the use of the Online
  Certificate Status Protocol (OCSP) as a means of retrieving real-time
  status information about such certificates, defining new extensions
  to compensate for the dynamism of telephone number assignments.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-stir-certificates-ocsp/



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

# Document Shepherd Write-Up for Group Documents

## 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?

There was consensus among the core STIR participants, including several who are
experts in certificate management.

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

There were no major controversies, but the group did go back and forth about
whether to include stapling in this document or to leave it for future work. The
final consensus was to include stapling in this document.

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.)

There have been no expressions of discontent.

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 biggest consumer of STIR documents is US telephony carrier industry, as
represented the ATIS/SIP Forum joint IP-NNI task force. That task force creates
standards and architectures that incorporate STIR standards. At the time most of
this work was done, IP-NNI was expected to use OCSP in their certificate
delegation standard. Since then, IP-NNI has chosen not to use OCSP at this time,
and instead recommends short-lived certificates. In the shepherd's
opinion, it is possible (and maybe even likely) that they will incorporate OCSP
in the future. There is still STIR working group consensus to publish.

## 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.

The document would benefit from the usual directorate reviews, especially
secdir. Otherwise, there is sufficient expertise among the working group
participants.

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.

To the shepherd's knowledge, no formal expert review criteria apply. There are
two IANA registrations that will require expert review. (One of the experts is
an author and the other is a STIR working group chair.)

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]?

The document does not contain a YANG module.

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.

Russ Housley reviewed and compiled the ASN.1 module.

## 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 believes this draft is ready to hand off to the AD.

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?

The shepherd is not aware of such lists that would apply to this draft.

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 requested status is Proposed Standard. The content includes normative
requirements about the use of OSCP with existing STIR proposed standards

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.

There are no IPR disclosures. The authors are well aware of their IPR
obligations and confirmed that there are no disclosures that need to be filed.

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.

Both authors have confirmed that they wish to be listed as such.

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.)

The only material nit not mentioned elsewhere in this writeup is a reference
to an informational reference to the obsolete RFC 6961. This reference
is intentional and accompanied by a parallel informational reference to
draft-ietf-tls-rfc8446bis. 

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

In the shepherd's opinion, all references are correctly categorized.

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

All normative references are freely available.

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.

No. There is a normative downref to RFC 5912, which is listed on the downref
registry.

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?

No.

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.

This document will not change the status of existing RFCs

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 does not create new registries. It does make two assignments to
existing registries, which are appropriately documented.

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 does not create new registries.

[1]: https://www.ietf.org/about/groups/iesg/ [2]:
https://www.rfc-editor.org/rfc/rfc4858.html [3]:
https://www.rfc-editor.org/rfc/rfc7942.html [4]:
https://wiki.ietf.org/group/ops/yang-review-tools [5]:
https://www.rfc-editor.org/rfc/rfc8342.html [6]:
https://wiki.ietf.org/group/iesg/ExpertTopics [7]:
https://www.rfc-editor.org/info/bcp79 [8]: https://www.ietf.org/tools/idnits/
[9]: https://www.rfc-editor.org/rfc/rfc3967.html [10]:
https://www.rfc-editor.org/info/bcp97 [11]:
https://www.rfc-editor.org/rfc/rfc8126.html [12]:
https://www.rfc-editor.org/rfc/rfc2026.html#section-5 [13]:
https://www.rfc-editor.org/rfc/rfc2026.html#section-4.1 [14]:
https://www.rfc-editor.org/rfc/rfc2026.html#section-4.2 [15]:
https://authors.ietf.org/en/content-guidelines-overview [16]:
https://www.ietf.org/about/groups/iesg/statements/normative-informative-
references/ [17]: https://datatracker.ietf.org/doc/downref/

# Document Shepherd Write-Up for Group Documents

## 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?

There was consensus among the core STIR participants, including several who are
experts in certificate management.

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

There were no major controversies, but the group did go back and forth about
whether to include stapling in this document or to leave it for future work. The
final consensus was to include stapling in this document.

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.)

There have been no expressions of discontent.

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 biggest consumer of STIR documents is US telephony carrier industry, as
represented the ATIS/SIP Forum joint IP-NNI task force. That task force creates
standards and architectures that incorporate STIR standards. At the time most of
this work was done, IP-NNI was expected to use OCSP in their certificate
delegation standard. Since then, IP-NNI has chosen not to use OCSP at this time,
and instead recommends short-lived certificates. In the shepherd's
opinion, it is possible (and maybe even likely) that they will incorporate OCSP
in the future. There is still STIR working group consensus to publish.

## 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.

The document would benefit from the usual directorate reviews, especially
secdir. Otherwise, there is sufficient expertise among the working group
participants.

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.

To the shepherd's knowledge, no formal expert review criteria apply. There are
two IANA registrations that will require expert review. (One of the experts is
an author and the other is a STIR working group chair.)

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]?

The document does not contain a YANG module.

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.

Russ Housley reviewed and compiled the ASN.1 module.

## 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 believes this draft is ready to hand off to the AD.

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?

The shepherd is not aware of such lists that would apply to this draft.

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 requested status is Proposed Standard. The content includes normative
requirements about the use of OSCP with existing STIR proposed standards

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.

There are no IPR disclosures. The authors are well aware of their IPR
obligations and confirmed that there are no disclosures that need to be filed.

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.

Both authors have confirmed that they wish to be listed as such.

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.)

The only material nit not mentioned elsewhere in this writeup is a reference
to an informational reference to the obsolete RFC 6961. This reference
is intentional and accompanied by a parallel informational reference to
draft-ietf-tls-rfc8446bis. 

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

In the shepherd's opinion, all references are correctly categorized.

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

All normative references are freely available.

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.

No. There is a normative downref to RFC 5912, which is listed on the downref
registry.

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?

No.

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.

This document will not change the status of existing RFCs

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 does not create new registries. It does make two assignments to
existing registries, which are appropriately documented.

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 does not create new registries.

[1]: https://www.ietf.org/about/groups/iesg/ [2]:
https://www.rfc-editor.org/rfc/rfc4858.html [3]:
https://www.rfc-editor.org/rfc/rfc7942.html [4]:
https://wiki.ietf.org/group/ops/yang-review-tools [5]:
https://www.rfc-editor.org/rfc/rfc8342.html [6]:
https://wiki.ietf.org/group/iesg/ExpertTopics [7]:
https://www.rfc-editor.org/info/bcp79 [8]: https://www.ietf.org/tools/idnits/
[9]: https://www.rfc-editor.org/rfc/rfc3967.html [10]:
https://www.rfc-editor.org/info/bcp97 [11]:
https://www.rfc-editor.org/rfc/rfc8126.html [12]:
https://www.rfc-editor.org/rfc/rfc2026.html#section-5 [13]:
https://www.rfc-editor.org/rfc/rfc2026.html#section-4.1 [14]:
https://www.rfc-editor.org/rfc/rfc2026.html#section-4.2 [15]:
https://authors.ietf.org/en/content-guidelines-overview [16]:
https://www.ietf.org/about/groups/iesg/statements/normative-informative-
references/ [17]: https://datatracker.ietf.org/doc/downref/

# Document Shepherd Write-Up for Group Documents

## 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?

There was consensus among the core STIR participants, including several who are
experts in certificate management.

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

There were no major controversies, but the group did go back and forth about
whether to include stapling in this document or to leave it for future work. The
final consensus was to include stapling in this document.

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.)

There have been no expressions of discontent.

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 biggest consumer of STIR documents is US telephony carrier industry, as
represented the ATIS/SIP Forum joint IP-NNI task force. That task force creates
standards and architectures that incorporate STIR standards. At the time most of
this work was done, IP-NNI was expected to use OCSP in their certificate
delegation standard. Since then, IP-NNI has chosen not to use OCSP at this time,
and instead recommends short-lived certificates. In the shepherd's
opinion, it is possible (and maybe even likely) that they will incorporate OCSP
in the future. There is still STIR working group consensus to publish.

## 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.

The document would benefit from the usual directorate reviews, especially
secdir. Otherwise, there is sufficient expertise among the working group
participants.

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.

To the shepherd's knowledge, no formal expert review criteria apply. There are
two IANA registrations that will require expert review. (One of the experts is
an author and the other is a STIR working group chair.)

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]?

The document does not contain a YANG module.

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.

Russ Housley reviewed and compiled the ASN.1 module.

## 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 believes this draft is ready to hand off to the AD.

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?

The shepherd is not aware of such lists that would apply to this draft.

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 requested status is Proposed Standard. The content includes normative
requirements about the use of OSCP with existing STIR proposed standards

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.

There are no IPR disclosures. The authors are well aware of their IPR
obligations and confirmed that there are no disclosures that need to be filed.

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.

Both authors have confirmed that they wish to be listed as such.

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.)

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

In the shepherd's opinion, all references are correctly categorized.

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

All normative references are freely available.

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.

No. There is a normative downref to RFC 5912, which is listed on the downref
registry.

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.

This document will not change the status of existing RFCs

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 does not create new registries. It does make two assignments to
existing registries, which are appropriately documented.

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 does not create new registries.

[1]: https://www.ietf.org/about/groups/iesg/ [2]:
https://www.rfc-editor.org/rfc/rfc4858.html [3]:
https://www.rfc-editor.org/rfc/rfc7942.html [4]:
https://wiki.ietf.org/group/ops/yang-review-tools [5]:
https://www.rfc-editor.org/rfc/rfc8342.html [6]:
https://wiki.ietf.org/group/iesg/ExpertTopics [7]:
https://www.rfc-editor.org/info/bcp79 [8]: https://www.ietf.org/tools/idnits/
[9]: https://www.rfc-editor.org/rfc/rfc3967.html [10]:
https://www.rfc-editor.org/info/bcp97 [11]:
https://www.rfc-editor.org/rfc/rfc8126.html [12]:
https://www.rfc-editor.org/rfc/rfc2026.html#section-5 [13]:
https://www.rfc-editor.org/rfc/rfc2026.html#section-4.1 [14]:
https://www.rfc-editor.org/rfc/rfc2026.html#section-4.2 [15]:
https://authors.ietf.org/en/content-guidelines-overview [16]:
https://www.ietf.org/about/groups/iesg/statements/normative-informative-
references/ [17]: https://datatracker.ietf.org/doc/downref/

# Document Shepherd Write-Up for Group Documents

## 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?

There was consensus among the core STIR participants, including several who are
experts in certificate management.

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

There were no major controversies, but the group did go back and forth about
whether to include stapling in this document or to leave it for future work. The
final consensus was to include stapling in this document.

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.)

There have been no expressions of discontent.

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 biggest consumer of STIR documents is US telephony carrier industry, as
represented the ATIS/SIP Forum joint IP-NNI task force. That task force creates
standards and architectures that incorporate STIR standards. At the time most of
this work was done, IP-NNI was expected to use OCSP in their certificate
delegation standard. Since then, IP-NNI has chosen not to use OCSP at this time,
and instead recommends short-lived certificates. In the shepherd's
opinion, it is possible (and maybe even likely) that they will incorporate OCSP
in the future. There is still STIR working group consensus to publish.

## 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.

The document would benefit from the usual directorate reviews, especially
secdir. Otherwise, there is sufficient expertise among the working group
participants.

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.

To the shepherd's knowledge, no formal expert review criteria apply. There are
two IANA registrations that will require expert review. (One of the experts is
an author and the other is a STIR working group chair.)

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]?

The document does not contain a YANG module.

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.

Russ Housley reviewed and compiled the ASN.1 module.

## 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 believes this draft is ready to hand off to the AD.

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?

The shepherd is not aware of such lists that would apply to this draft.

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 requested status is Proposed Standard. The content includes normative
requirements about the use of OSCP with existing STIR proposed standards

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.

There are no IPR disclosures. The authors are well aware of their IPR
obligations and confirmed that there are no disclosures that need to be filed.

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.

Both authors have confirmed that they wish to be listed as such.

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.)

At the time of this writeup, there was an uncited informational reference to
RFC 6961, which has been obsoleted by RFC 8446. [To do: Ask authors to either
remove the reference or cite it.]

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

In the shepherd's opinion, all references are correctly categorized.

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

All normative references are freely available.

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.

No. There is a normative downref to RFC 5912, which is listed on the downref
registry.

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?

There is a normative reference to draft-peterson-stir-certificates-shortlived.
That should in fact refer to draft-ietf-stir-certificates-shortlived, which at
the time of this writeup was about to start WGLC. [To Do: Check with authors on
updating reference and whether it needs to be normative]

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.

This document will not change the status of existing RFCs

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 does not create new registries. It does make two assignments to
existing registries, which are appropriately documented.

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 does not create new registries.

[1]: https://www.ietf.org/about/groups/iesg/ [2]:
https://www.rfc-editor.org/rfc/rfc4858.html [3]:
https://www.rfc-editor.org/rfc/rfc7942.html [4]:
https://wiki.ietf.org/group/ops/yang-review-tools [5]:
https://www.rfc-editor.org/rfc/rfc8342.html [6]:
https://wiki.ietf.org/group/iesg/ExpertTopics [7]:
https://www.rfc-editor.org/info/bcp79 [8]: https://www.ietf.org/tools/idnits/
[9]: https://www.rfc-editor.org/rfc/rfc3967.html [10]:
https://www.rfc-editor.org/info/bcp97 [11]:
https://www.rfc-editor.org/rfc/rfc8126.html [12]:
https://www.rfc-editor.org/rfc/rfc2026.html#section-5 [13]:
https://www.rfc-editor.org/rfc/rfc2026.html#section-4.1 [14]:
https://www.rfc-editor.org/rfc/rfc2026.html#section-4.2 [15]:
https://authors.ietf.org/en/content-guidelines-overview [16]:
https://www.ietf.org/about/groups/iesg/statements/normative-informative-
references/ [17]: https://datatracker.ietf.org/doc/downref/

# Document Shepherd Write-Up for Group Documents

*This version is dated 4 July 2022.*

Thank you for your service as a document shepherd. Among the responsibilities is
answering the questions in this write-up to give helpful context to Last Call
and Internet Engineering Steering Group ([IESG][1]) reviewers, and your
diligence in completing it is appreciated. The full role of the shepherd is
further described in [RFC 4858][2]. You will need the cooperation of the authors
and editors to complete these checks.

Note that some numbered items contain multiple related questions; please be sure
to answer all of them.

## 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?

There was consensus among the core STIR participants, including several who are
expects in certificate management.

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

There were no major controversies, but the group did go back and forth about
whether to include stapling in this document or to leave it for future work. The
final consensus was to include stapling in this document.

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.)

There have been no expressions of discontent.

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 biggest consumer of STIR documents is US telephony carrier industry, as
represented the ATIS/SIP Forum joint IP-NNI task force. That task force creates
standards and architectures that incorporate STIR standards. At the time most of
this work was done, IP-NNI was expected to use OCSP in their certificate
delegation standard. Since then, IP-NNI has chosen not to use OCSP at this time,
and instead recommends the user of short-lived certificates. In the shepherd's
opinion, it is possible (and maybe even likely) that they will incorporate OCSP
in the future. There is still STIR working group consensus to publish.

## 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.

The document would benefit from the usual directorate reviews, especially
secdir. Otherwise, there is sufficient expertise among the working group
participants.

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.

To the shepherd's knowledge, no formal expert review criteria apply. There are
two IANA registrations that will require expert review. (One of the experts is
an author and the other is a STIR working group chair.)

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]?

The document does not contain a YANG module.

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.

Russ Housley reviewed and compiled the ASN.1 module. [To Do: Verify this!]

## 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 believes this draft is ready to hand off to the AD.

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?

The shepherd is not aware of such lists that would apply to this draft.

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 requested status is Proposed Standard. The content includes normative
requirements about the use of OSCP with existing STIR proposed standards

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.

There are no IPR disclosures. The authors are well aware of their IPR
obligations and confirmed that there are no disclosures that need to be filed.

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.

Both authors have confirmed that they wish to be listed as such.

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.)

At thie time of this writeup, there was an uncited informational reference to
RFC 6961, which has been obsoleted by RFC 8446. [To do: Revisit this before
pulling the trigger]

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

In the shepherd's opinion, all references are correctly categorized.

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

There are normative references to ITU-T recommendations for X.509, X.680, X.681,
X.682, and X.683 which might not be available  without payment. [To Do: Check
this with Russ.]

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.

No. There is a normative downref to RFC 5912, which is listed on the downref
registry.

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?

There is a normative reference to draft-peterson-stir-certificates-shortlived.
That should in fact refer to draft-ietf-stir-certificates-shortlived, which at
the time of this writeup was about to start WGLC. [To Do: Check with authors on
updating reference]

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.

This document will not change the status of existing RFCs

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 does not create new registries. It does make two assignments to
existing registries, which are appropriately documented.

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 does not create new registries.

[1]: https://www.ietf.org/about/groups/iesg/ [2]:
https://www.rfc-editor.org/rfc/rfc4858.html [3]:
https://www.rfc-editor.org/rfc/rfc7942.html [4]:
https://wiki.ietf.org/group/ops/yang-review-tools [5]:
https://www.rfc-editor.org/rfc/rfc8342.html [6]:
https://wiki.ietf.org/group/iesg/ExpertTopics [7]:
https://www.rfc-editor.org/info/bcp79 [8]: https://www.ietf.org/tools/idnits/
[9]: https://www.rfc-editor.org/rfc/rfc3967.html [10]:
https://www.rfc-editor.org/info/bcp97 [11]:
https://www.rfc-editor.org/rfc/rfc8126.html [12]:
https://www.rfc-editor.org/rfc/rfc2026.html#section-5 [13]:
https://www.rfc-editor.org/rfc/rfc2026.html#section-4.1 [14]:
https://www.rfc-editor.org/rfc/rfc2026.html#section-4.2 [15]:
https://authors.ietf.org/en/content-guidelines-overview [16]:
https://www.ietf.org/about/groups/iesg/statements/normative-informative-
references/ [17]: https://datatracker.ietf.org/doc/downref/