Skip to main content

Delegated Credentials for TLS and DTLS


Paul Wouters

No Objection

Andrew Alston
Erik Kline
Murray Kucherawy
Zaheduzzaman Sarker
(Alvaro Retana)

Note: This ballot was opened for revision 14 and is now closed.

Paul Wouters
Andrew Alston
No Objection
Erik Kline
No Objection
Francesca Palombini
No Objection
Comment (2022-05-31 for -14) Sent
Thank you for the work on this document.

Many thanks to Christian Amsüss for his ART ART review: Authors, please take a look at Christian's comments (also reported below), especially the one about the "delegated_credential" usage in the Certificate message.



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

* 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

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.
John Scudder
No Objection
Comment (2022-06-01 for -14) Sent
Nit, in the Abstract "This document describes a mechanism to to", s/to//.
Lars Eggert
No Objection
Comment (2022-05-31 for -14) Sent for earlier
# GEN AD review of draft-ietf-tls-subcerts-14

CC @larseggert

Thanks to Elwyn Davies for the General Area Review Team (Gen-ART) review

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

### Inclusive language

Found terminology that should be reviewed for inclusivity; see for background and more

 * 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, 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].

Martin Duke
No Objection
Comment (2022-05-23 for -14) Sent
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?
Murray Kucherawy
No Objection
Robert Wilton
No Objection
Comment (2022-05-27 for -14) Sent

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.

Roman Danyliw
No Objection
Comment (2022-05-31 for -14) Sent
** 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:

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:

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 ( 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”
Zaheduzzaman Sarker
No Objection
Éric Vyncke
No Objection
Comment (2022-05-31 for -14) Sent
# É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,




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

Alvaro Retana Former IESG member
No Objection
No Objection (for -14) Not sent