Delegated Credentials for TLS and DTLS
draft-ietf-tls-subcerts-15

[Ballot comment]
** Section 4
    Endpoints will reject delegated
      credentials that expire more than 7 days from the current time (as
      described in Section 4.1) based on the default (see Section 3.

For clarity, consider:

NEW
By default, unless set to an alternative value by an application profile (see Section 3), endpoints will reject delegated credentials that expire more than 7 days from the current time (as described in Section 4.1.3).

** Section 7.1
  However, they cannot create new delegated credentials.  Thus,
  delegated credentials should not be used to send a delegation to an
  untrusted party, ...

The second sentence doesn’t seem to follow from the first.

** Appendix B
  The following certificate has the Delegated Credentials OID.

For clarity, consider:

NEW
The following is an example of a delegation certificate which satisfies the requirements described in Section 4.2 (i.e., uses the DelegationUsage extension and has the digitalSignature KeyUsage).

** Appendix B.  I will leave to the RFC Editor to decide if using the Watson Ladd’s personal home page (kc2kdm.com) in the certificate SAN is an acceptable example domain name.

Editorial Nits

** Abstract.  Typo. s/to to/to/

** Section 4.2. Typo. s/documnt/document/

** Section 7.6.  In the spirit of inclusive language, consider if there is an alternative term to “man-in-the-middle certificate”

[Ballot comment]
Thank you for the work on this document.

Many thanks to Christian Amsüss for his ART ART review: https://mailarchive.ietf.org/arch/msg/art/7lzdOaiccRnXFtSuX3aUyh9ffV8/. Authors, please take a look at Christian's comments (also reported below), especially the one about the "delegated_credential" usage in the Certificate message.

Francesca

--

Reviewer: Christian Amsüss
Review result: Ready with Nits

Thanks for this well-written document

ART topics:

The document does not touch on any of the typical ART review issues; times are
relative in well understood units, and versioning, formal language (ASN.1,
which is outside of my experience to check) and encoding infrastructure
(struct) follows TLS practices.

General comments:

* The introduction of this mechanism gives the impression of a band-aid applied
to a PKI ecosystem that has accumulated many limitations as outlined in section
3.1. The present solution appears good, but if there is ongoing work on the
underlying issues (even experimentally), I'd appreciate a careful reference to
it.

* Section 7.6 hints at the front end querying the back-end for creation of new
DCs -- other than that, DC distribution (neither push- nor pull-based) is
discussed. If there are any mechanisms brewing, I'd appreciate a reference as
well.

Please check:

* The IANA considerations list "delegated_credential" for CH, CR and CT
messages. I did not find a reference in the text for Ct, only for CH and CR.

Editorial comments:

* (p5) "result for the peer.." -- extraneous period.
* (p9, p15, p16) The "7 days" are introduced as the default for a profilable
prarameter, but later used without further comment.

[Ballot comment]
# GEN AD review of draft-ietf-tls-subcerts-14

CC @larseggert

Thanks to Elwyn Davies for the General Area Review Team (Gen-ART) review
(https://mailarchive.ietf.org/arch/msg/gen-art/QDnSqLec7uKP9GcyuL-8p8nS-2s).

## Comments

### Section 6, paragraph 2
```
    This document also defines an ASN.1 module for the DelegationUsage
    certificate extension in Appendix A.  IANA has registered value 95
    for "id-mod-delegated-credential-extn" in the "SMI Security for PKIX
    Module Identifier" (1.3.5.1.5.5.7.0) registry.  An OID for the
    DelegationUsage certificate extension is not needed as it is already
    assigned to the extension from Cloudflare's IANA Private Enterprise
    Number (PEN) arc.
```
See Martin Duke's comment on using the Cloudflare space; I have the same
question.

### Inclusive language

Found terminology that should be reviewed for inclusivity; see
https://www.rfc-editor.org/part2/#inclusive_language for background and more
guidance:

* Term `man`; alternatives might be `individual`, `people`, `person`
* Term `invalid`; alternatives might be `not valid`, `unenforceable`, `not
  binding`, `inoperative`, `illegitimate`, `incorrect`, `improper`,
  `unacceptable`, `inapplicable`, `revoked`, `rescinded`

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

#### Section 4.2, paragraph 1
```
-    This documnt defines a new X.509 extension, DelegationUsage, to be
+    This document defines a new X.509 extension, DelegationUsage, to be
+              +
```

### Outdated references

Reference `[RFC5246]` to `RFC5246`, which was obsoleted by `RFC8446` (this may
be on purpose).

### Grammar/style

#### Paragraph 2
```
his document describes a mechanism to to overcome some of these limitations
                                  ^^^^^
```
Possible typo: you repeated a word.

#### Section 5.1, paragraph 1
```
tial's private key is thus important and access control mechanisms SHOULD be
                                    ^^^^
```
Use a comma before "and" if it connects two independent clauses (unless they
are closely connected and short).

#### Section 6, paragraph 1
```
f early revocation. Since it is short lived, the expiry of the delegated cre
                                ^^^^^^^^^^^
```
This word is normally spelled with a hyphen.

#### Section 7, paragraph 1
```
ime could be unique and thus privacy sensitive clients, such as browsers in i
                            ^^^^^^^^^^^^^^^^^
```
This word is normally spelled with a hyphen.

## 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]
# Éric Vyncke, INT AD, review of # Éric Vyncke, INT AD, review of draft-ietf-tls-subcerts-14

Thank you for the work put into this document. It solves a common and important issue while keeping backward compatibility.

Please find below some non-blocking COMMENT points (but replies would be appreciated even if only for my own education).

Special thanks to Joe Salowey for the shepherd's write-up including the WG consensus and the intended status.

I hope that this helps to improve the document,

Regards,

-éric

## COMMENTS

### Section 1

```
  Furthermore, this mechanism allows the server to use modern signature
  algorithms such as Ed25519 [RFC8032] even if their CA does not
  support them.
```
Does it also mean that the signature algorithm could be weaker ?

I found the use of `(D)TLS termination services`, `(D)TLS server`, `(D)TLS peer` a little confusing on whether they represent the same entity.

### Section 3.2

The small graphic in the text is really useful but:

* should include a figure legend
* the bottom part would be welcome in the introduction

## Section 4.2

Thanks to Sean Turner for providing the explanation about the use of Cloudflare OID into an IETF standard.

## Section 5.1

Unsure whether having such a short subsection is useful (albeit being harmless) especially when there is only one subsection.

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

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

[Ballot comment]
Hi,

Thanks for this document.

I found section 5.1 on Clock Skew interesting and good to raise, but it was slightly unclear to me on several regards:

1) This text only writes about client clock skew. Isn't it also possible that a poorly maintained server might also suffer clock skew and a client using a delegated-certificate could be similarly affected?

2) It was a bit unclear to me what "The lifetime of the delegated credential should be set taking clock skew into account." was intending.  Initially I had read this wondering if the peer should try and calculate the clock skew of the peer and allocate a certificate accordingly. But I presume that the actual intent is that when certificates are generated, the start time should probably be a few minutes in the past, and the certificate expiry should not be set to be exactly 7 days into the future, but perhaps a few minutes less to account for potential skew between clocks?

I will leave it to the authors discretion to decide if they want to tighten or clarify this text at all.

Regards,
Rob

[Ballot comment]
# GEN AD review of draft-ietf-tls-subcerts-14

CC @larseggert

Thanks to Elwyn Davies for the General Area Review Team (Gen-ART) review
(https://mailarchive.ietf.org/arch/msg/gen-art/QDnSqLec7uKP9GcyuL-8p8nS-2s).

## Comments

### Section 6, paragraph 2
```
    This document also defines an ASN.1 module for the DelegationUsage
    certificate extension in Appendix A.  IANA has registered value 95
    for "id-mod-delegated-credential-extn" in the "SMI Security for PKIX
    Module Identifier" (1.3.5.1.5.5.7.0) registry.  An OID for the
    DelegationUsage certificate extension is not needed as it is already
    assigned to the extension from Cloudflare's IANA Private Enterprise
    Number (PEN) arc.
```
See Martin Duke's comment on using the Cloudflare space; I have the same
question.

### Inclusive language

Found terminology that should be reviewed for inclusivity; see
https://www.rfc-editor.org/part2/#inclusive_language for background and more
guidance:

* Term `man`; alternatives might be `individual`, `people`, `person`
* Term `invalid`; alternatives might be `not valid`, `unenforceable`, `not
  binding`, `inoperative`, `illegitimate`, `incorrect`, `improper`,
  `unacceptable`, `inapplicable`, `revoked`, `rescinded`

### IP addresses

Found IP blocks or addresses not inside RFC5737/RFC3849 example ranges:
`1.3.5.1` and `5.5.7.0`.

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

#### Section 4.2, paragraph 1
```
-    This documnt defines a new X.509 extension, DelegationUsage, to be
+    This document defines a new X.509 extension, DelegationUsage, to be
+              +
```

### Outdated references

Reference `[RFC5246]` to `RFC5246`, which was obsoleted by `RFC8446` (this may
be on purpose).

### Grammar/style

#### Paragraph 2
```
his document describes a mechanism to to overcome some of these limitations
                                  ^^^^^
```
Possible typo: you repeated a word.

#### Section 5.1, paragraph 1
```
tial's private key is thus important and access control mechanisms SHOULD be
                                    ^^^^
```
Use a comma before "and" if it connects two independent clauses (unless they
are closely connected and short).

#### Section 6, paragraph 1
```
f early revocation. Since it is short lived, the expiry of the delegated cre
                                ^^^^^^^^^^^
```
This word is normally spelled with a hyphen.

#### Section 7, paragraph 1
```
ime could be unique and thus privacy sensitive clients, such as browsers in i
                            ^^^^^^^^^^^^^^^^^
```
This word is normally spelled with a hyphen.

## 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]
A question to remedy by ignorance of ASN.1:

How customary is it for the final standard to use an ASN.1 codepoint from Cloudflare's private namespace? In other contexts I would expect change control to lie with a more public institution.

Put another way, what would happen if Cloudflare were purchased by EvilCorp one day?

Ben's AD report issues have been addressed in -12 and the genart issues have been resolved in -13. I've send my own AD review to the TLS list, but as the document has been waiting for a whole, and I found no major issues, let's move the doc forward.

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has completed its review of draft-ietf-tls-subcerts-12. If any part of this review is inaccurate, please let us know.

The IANA Functions Operator understands that, upon approval of this document, there are two actions which we must complete.

First, in the TLS ExtensionType Values registry on the Transport Layer Security (TLS) Extensions registry page located at:

https://www.iana.org/assignments/tls-extensiontype-values/

the existing registration for:

Value: 34
Extension Name: delegated_credentials

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

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

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

the existing registration for:

Decimal: 95
Description: id-mod-delegated-credential-extn

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

The IANA Functions Operator understands 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.

Thank you,

Sabrina Tanamal
Lead IANA Services Specialist

The following Last Call announcement was sent out (ends 2022-04-08):

From: The IESG
To: IETF-Announce
CC: Joseph Salowey , draft-ietf-tls-subcerts@ietf.org, joe@salowey.net, kaduk@mit.edu, tls-chairs@ietf.org, tls@ietf.org
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (Delegated Credentials for (D)TLS) to Proposed Standard


The IESG has received a request from the Transport Layer Security WG (tls) to
consider the following document: - 'Delegated Credentials for (D)TLS'
  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 2022-04-08. 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


  The organizational separation between the operator of a (D)TLS
  endpoint and the certification authority can create limitations.  For
  example, the lifetime of certificates, how they may be used, and the
  algorithms they support are ultimately determined by the
  certification authority.  This document describes a mechanism to to
  overcome some of these limitations by enabling operators to delegate
  their own credentials for use in (D)TLS without breaking
  compatibility with peers that do not support this specification.




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



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

As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up. Changes are expected over time.

This version is dated 1 November 2019.

(1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header?

This document requests proposed standard status since it is proposing an extension to the TLS protocol that is generally useful. 

(2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections:

Technical Summary:

The organizational separation between the operator of a TLS endpoint and the certification authority can create limitations. For example, the lifetime of certificates, how they may be used, and the algorithms they support are ultimately determined by the certification authority. This document describes a mechanism by which operators may delegate their own credentials for use in TLS, without breaking compatibility with peers that do not support this specification.

Working Group Summary:

There is good consensus for this document with the working group. There was some delay in getting issues addressed from the previous WGLC and a delay in publishing a revised draft with the required changes.  There is interest in the working group to see this document move forward. 

Document Quality:

Several vendors have indicated they will support the draft and more than one implementation exists.  There are test vectors available for the draft, but the authors and chairs decided to wait until they are verified before including them in the draft. 

Personnel:

Joe Salowey is the document Shepherd.

(3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG.

The document shepherd has reviewed the document and believes it is ready for IESG review.  This document will need an edit in the IANA section to mark the extension as DTLS OK, but that can be handled with the resolution to any AD and directorate comments.

(4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?

The draft has gone through and extensive review process by experts in the TLS working group.  There has also be formal analysis of the protocol

(5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place.

Jonathan Hoyland performed a formal security analysis of the protocol using Tamarin (https://mailarchive.ietf.org/arch/msg/tls/vSweLT6yZX42i0VGKbN5eZzLi8s/) showing it secure under the stronger model of a Dolev-Yao attacker with the ability to reveal long term keys (for certificates). No paper has been published yet.

(6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here.

None.

(7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why?

yes

(8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures.

No IPR disclosure has been filed for this draft

(9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it?

There is solid consensus for this document within the working group. 

(10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise 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.)

No appeals known

(11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough.

No ID nits found

(12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

NA

(13) Have all references within this document been identified as either normative or informative?

Yes

(14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion?

No

(15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure.

No Downrefs

(16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary.

No

(17) 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 protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 8126).

I reviewed that the IANA actions are correctly identified and the correct registry is updated.  The extension should be marked as DTLS OK. 

(18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries.

No new registries

(19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, YANG modules, etc.

NA

(20) If the document contains a YANG module, has the module been checked with any of the recommended validation tools (https://trac.ietf.org/trac/ops/wiki/yang-review-tools) 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 RFC8342?

NA

As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up. Changes are expected over time.

This version is dated 1 November 2019.

(1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header?

This document requests proposed standard status since it is proposing an extension to the TLS protocol that is generally useful. 

(2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections:

Technical Summary:

The organizational separation between the operator of a TLS endpoint and the certification authority can create limitations. For example, the lifetime of certificates, how they may be used, and the algorithms they support are ultimately determined by the certification authority. This document describes a mechanism by which operators may delegate their own credentials for use in TLS, without breaking compatibility with peers that do not support this specification.

Working Group Summary:

There is good consensus for this document with the working group. There was some delay in getting issues addressed from the previous WGLC and a delay in publishing a revised draft with the required changes.  There is interest in the working group to see this document move forward. 

Document Quality:

Several vendors have indicated they will support the draft and more than one implementation exists.  There are test vectors available for the draft, but the authors and chairs decided to wait until they are verified before including them in the draft. 

Personnel:

Joe Salowey is the document Shepherd.

(3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG.

The document shepherd has reviewed the document and believes it is ready for IESG review.  This document will need an edit in the IANA section to mark the extension as DTLS OK, but that can be handled with the resolution to any AD and directorate comments.

(4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?

The draft has gone through and extensive review process by experts in the TLS working group.  There has also be formal analysis of the protocol

(5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place.

Jonathan Hoyland performed a formal security analysis of the protocol using Tamarin (https://mailarchive.ietf.org/arch/msg/tls/vSweLT6yZX42i0VGKbN5eZzLi8s/) showing it secure under the stronger model of a Dolev-Yao attacker with the ability to reveal long term keys (for certificates). No paper has been published yet.

(6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here.

None.

(7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why?

yes

(8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures.

No IPR disclosure has been filed for this draft

(9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it?

There is solid consensus for this document within the working group. 

(10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise 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.)

No appeals known

(11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough.

No ID nits found

(12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

NA

(13) Have all references within this document been identified as either normative or informative?

Yes

(14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion?

No

(15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure.

No Downrefs

(16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary.

No

(17) 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 protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 8126).

I reviewed that the IANA actions are correctly identified and the correct registry is updated.  The extension should be marked as DTLS OK. 

(18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries.

No new registries

(19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, YANG modules, etc.

NA

(20) If the document contains a YANG module, has the module been checked with any of the recommended validation tools (https://trac.ietf.org/trac/ops/wiki/yang-review-tools) 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 RFC8342?

NA

As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up. Changes are expected over time.

This version is dated 1 November 2019.

(1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header?

This document requests proposed standard status since it is proposing an extension to the TLS protocol that is generally useful. 

(2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections:

Technical Summary:

The organizational separation between the operator of a TLS endpoint and the certification authority can create limitations. For example, the lifetime of certificates, how they may be used, and the algorithms they support are ultimately determined by the certification authority. This document describes a mechanism by which operators may delegate their own credentials for use in TLS, without breaking compatibility with peers that do not support this specification.

Working Group Summary:

There is good consensus for this document with the working group. There was some delay in getting issues addressed from the previous WGLC and a delay in publishing a revised draft with the required changes.  There is interest in the working group to see this document move forward. 

Document Quality:

Several vendors have indicated they will support the draft and more than one implementation exists.  There are test vectors available for the draft, but the authors and chairs decided to wait until they are verified before including them in the draft. 

Personnel:

Joe Salowey is the document Shepherd.

(3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG.

The document shepherd has reviewed the document and believes it is ready for IESG review.  This document will need an edit in the IANA section to mark the extension as DTLS OK, but that can be handled with the resolution to any AD and directorate comments.

(4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?

The draft has gone through and extensive review process by experts in the TLS working group.  There has also be formal analysis of the protocol

(5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place.

Jonathan Hoyland performed a formal security analysis of the protocol using Tamarin (https://mailarchive.ietf.org/arch/msg/tls/vSweLT6yZX42i0VGKbN5eZzLi8s/) showing it secure under the stronger model of a Dolev-Yao attacker with the ability to reveal long term keys (for certificates). No paper has been published yet.

(6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here.

None.

(7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why?

yes

(8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures.

No IPR disclosure has been filed for this draft

(9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it?

There is solid consensus for this document within the working group. 

(10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise 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.)

No appeals known

(11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough.

No ID nits found

(12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

NA

(13) Have all references within this document been identified as either normative or informative?

Yes

(14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion?

No

(15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure.

No Downrefs

(16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary.

No

(17) 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 protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 8126).

I reviewed that the IANA actions are correctly identified and the correct registry is updated. 

(18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries.

No new registries

(19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, YANG modules, etc.

NA

(20) If the document contains a YANG module, has the module been checked with any of the recommended validation tools (https://trac.ietf.org/trac/ops/wiki/yang-review-tools) 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 RFC8342?

NA

As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up. Changes are expected over time.

This version is dated 1 November 2019.

(1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header?

This document requests proposed standard status since it is proposing an extension to the TLS protocol that is generally useful. 

(2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections:

Technical Summary:

The organizational separation between the operator of a TLS endpoint and the certification authority can create limitations. For example, the lifetime of certificates, how they may be used, and the algorithms they support are ultimately determined by the certification authority. This document describes a mechanism by which operators may delegate their own credentials for use in TLS, without breaking compatibility with peers that do not support this specification.

Working Group Summary:

There is good consensus for this document with the working group. There was some delay in getting issues addressed from the previous WGLC and a delay in publishing a revised draft with the required changes.  There is interest in the working group to see this document move forward. 

Document Quality:

Several vendors have indicated they will support the draft and more than one implementation exists.  There are test vectors available for the draft, but the authors and chairs decided to wait until they are verified before including them in the draft. 

Personnel:

Joe Salowey is the document Shepherd.

(3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG.

The document shepherd has reviewed the document and believes it is ready for IESG review. 

(4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?

The draft has gone through and extensive review process by experts in the TLS working group.  There has also be formal analysis of the protocol

(5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place.

Jonathan Hoyland performed a formal security analysis of the protocol using Tamarin (https://mailarchive.ietf.org/arch/msg/tls/vSweLT6yZX42i0VGKbN5eZzLi8s/) showing it secure under the stronger model of a Dolev-Yao attacker with the ability to reveal long term keys (for certificates). No paper has been published yet.

(6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here.

None.

(7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why?

yes

(8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures.

No IPR disclosure has been filed for this draft

(9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it?

There is solid consensus for this document within the working group. 

(10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise 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.)

No appeals known

(11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough.

No ID nits found

(12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

NA

(13) Have all references within this document been identified as either normative or informative?

Yes

(14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion?

No

(15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure.

No Downrefs

(16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary.

No

(17) 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 protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 8126).

I reviewed that the IANA actions are correctly identified and the correct registry is updated. 

(18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries.

No new registries

(19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, YANG modules, etc.

NA

(20) If the document contains a YANG module, has the module been checked with any of the recommended validation tools (https://trac.ietf.org/trac/ops/wiki/yang-review-tools) 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 RFC8342?

NA