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

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.

Nit, in the Abstract "This document describes a mechanism to to", s/to//.

** 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”

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

# 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

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?

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