Subject: Re: [TLS] I-D Action: draft-ietf-tls-subcerts-10.txt

From: Michael Richardson <[email-masked]>
Date: Mon, 22 Mar 2021 17:17:13 -0400

On 2021-01-24 6:03 p.m., [email-masked] wrote:
> 	Filename        : draft-ietf-tls-subcerts-10.txt

I was looking at the DT, wondering what's up, wondering if there was any 
implementation report in the document.  (When can I use this?... )
I see in the DT that it is waiting for WG chair go-ahead.  I see -10 
posted in January, and a few comments on it, so I'm guessing that we are
waiting for the authors to put out a -11, and then it can go on the IESG?

---

From: Sean Turner <[email-masked]>
Date: Tue, 23 Mar 2021 15:08:37 -0400

> On Mar 22, 2021, at 17:17, Michael Richardson <[email-masked]> wrote:
> 
> I was looking at the DT, wondering what's up, wondering if there was any implementation report in the document.  (When can I use this?... )
> I see in the DT that it is waiting for WG chair go-ahead.  I see -10 posted in January, and a few comments on it, so I'm guessing that we are

It is stuck on me. We are resolving some Directorate review comments.

spt

---

From: Joseph Birr-Pixton <[email-masked]>
Date: Sat, 27 Mar 2021 17:01:22 +0000

On Sun, 24 Jan 2021 at 23:03, <[email-masked]> wrote:
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> This draft is a work item of the Transport Layer Security WG of the IETF.
>
>         Title           : Delegated Credentials for TLS

I'm a little confused too by the meaning of 4.1.3:

#   1.  Validate that DelegatedCredential.cred.valid_time is no more than
#       7 days.

I read this as saying that a certificate can only be usable for
delegation in the first 7 days after it's notBefore. That follows from
valid_time being an offset in seconds from notBefore, and validation
step 3 covers the "maximum validity period" mentioned elsewhere in the
draft. This sounds a bit odd.

Honestly, I find the name and definition of valid_time a little
unclear. It's neither a "validity time" instant, or a period. Perhaps
"validity_offset"? But it may be simpler to just make it 64 bits and
_make_ it a UTC instant -- with the added benefit that this may result
in fewer implementations doing unsigned 32-bit arithmetic on times in
seconds and breaking ~15 years hence.

I think this draft would also benefit from explicitly drawing out (d)
in this thought process:

a) for performance reasons[1], it seems unlikely that RSA keys are
workable as delegated credentials.
b) a huge amount of the webpki is still built on RSA.
c) given (a) and (b), a common deployment strategy will mean mixed
authentication cryptography in handshake authentication: RSA for the
webpki portion, ECDSA/EdDSA perhaps for delegation.
d) and this is OK (as it is in webpki), and totally allowed, and expected.

Thanks,
Joe

[1] expensive, non-deterministic key generation; large key sizes