Subject: [Trans] Murray Kucherawy's Discuss on draft-ietf-trans-rfc6962-bis-36: (with DISCUSS)

From: Murray Kucherawy via Datatracker <[email-masked]>
Date: Thu, 13 May 2021 10:53:59 -0700

Murray Kucherawy has entered the following ballot position for
draft-ietf-trans-rfc6962-bis-36: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-trans-rfc6962-bis/

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

Thanks for addressing Alexey's DISCUSS position.  In -36, a few important
IANA-related issues remain, all easy fixes:

* Section 10.4 has some messed up markdown around its Specification Required
guidance.

* Section 10.7 needs to name the sub-registry it's creating.  (If it's the
title of the section, that should be made clear; the prose doesn't say.)

* It should be clear that all of these are sub-registries of "Transport Layer
Security (TLS) Extensions".  Either say that in each section (i.e., refer to
the XYZ sub-registry of the "Transport Layer Security (TLS) Extensions"
registry), or say in Section 10 that everything below is a sub-registry of that
one.

---

From: "Salz, Rich" <[email-masked]>
Date: Thu, 13 May 2021 19:19:32 +0000

Thanks for the feedback.  A PR is at https://github.com/google/certificate-transparency-rfcs/pull/332  Summary follows.

Missing newline added.

Name made explicit.

Most of this section (10) is new CT registries; only the TLS Type and the URN sub-namespace are modifications of existing entries.  I changed section 10 to divide this into 10.1 and 10.2 with subjections.

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 13 May 2021 15:33:00 -0700

On Thu, May 13, 2021 at 12:19 PM Salz, Rich <[email-masked]> wrote:

>
> Most of this section (10) is new CT registries; only the TLS Type and the
> URN sub-namespace are modifications of existing entries.  I changed section
> 10 to divide this into 10.1 and 10.2 with subjections.
>
>
What I'm suggesting is something like this for each new registry:

OLD:

### Signature Algorithms {#signature_algorithms}

IANA is asked to establish a registry of signature algorithm values, named
"CT Signature Algorithms".

NEW:

### Signature Algorithms {#signature_algorithms}

IANA is asked to establish a new sub-registry of the "Transport Layer
Security
(TLS) Extensions" registry called "CT Signature Algorithms".

END

Or, if you don't want to do that for each registry, then at the top of the
main IANA Considerations section, include something like:

All new registries created in this section should become sub-registries of
the existing "Transport Layer Security (TLS) Extensions" registry.

-MSK

---

From: "Salz, Rich" <[email-masked]>
Date: Fri, 14 May 2021 01:53:07 +0000

*   IANA is asked to establish a new sub-registry of the "Transport Layer Security

But they are not new TLS sub-registries.  They are new CT registries.  Are we missing some text that makes this clear?

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 13 May 2021 22:24:26 -0700

On Thu, May 13, 2021 at 6:53 PM Salz, Rich <[email-masked]> wrote:

> But they are not new TLS sub-registries.  They are new CT registries.  Are
> we missing some text that makes this clear?
>
Well maybe I'm making some wrong assumptions here.  Here's the question
from another angle:

It looks like you're making six related registries in Sections 10.2.1
through 10.2.6.  Would it make sense to create a main registry called
"Certificate Transparency Parameters" that contains these six
sub-registries?

-MSK

---

From: "Salz, Rich" <[email-masked]>
Date: Fri, 14 May 2021 16:06:17 +0000

*   It looks like you're making six related registries in Sections 10.2.1 through 10.2.6.  Would it make sense to create a main registry called "Certificate Transparency Parameters" that contains these six sub-registries?

I was not familiar with that distinction until now.  Sure, I’ll do that.  Is there standard wording one should use?

---

From: "Salz, Rich" <[email-masked]>
Date: Fri, 14 May 2021 17:33:38 +0000

>> I was not familiar with that distinction until now.  Sure, I’ll do that.  Is there standard wording one should use?

I tried to follow RFC 8126.

https://github.com/google/certificate-transparency-rfcs/pull/334

---

From: Rob Stradling <[email-masked]>
Date: Fri, 14 May 2021 18:27:03 +0000

Although TRANS is set to wind down without really looking beyond 6962-bis, the original Charter also envisaged exploring "mechanisms and techniques that allow cryptographically verifiable logs to be deployed to improve the security of protocols other than HTTP over TLS, for example SMTP/TLS or software distribution", and this was a consideration when we planned the (sub-)registries that 6962-bis requests to be created.  Perhaps there will be renewed interest in exploring such things in the future, and if so, it's conceivable that folks will want to reuse mechanisms from 6962-bis and reuse the (sub-)registries.

So I would prefer to name the new, main registry "Public Notary Transparency" (the full name of this WG - see https://datatracker.ietf.org/wg/trans), and either (i) strip the "CT " prefix from the sub-registry names or (ii) change the prefix from "CT " to "Transparency ".

Does that make sense?

________________________________
From: Salz, Rich <[email-masked]>
Sent: 14 May 2021 18:33
To: Salz, Rich <rsalz=[email-masked]>; Murray S. Kucherawy <[email-masked]>
Cc: [email-masked] <[email-masked]>; Paul Wouters <[email-masked]>; [email-masked] <[email-masked]>; The IESG <[email-masked]>; [email-masked] <[email-masked]>
Subject: Re: [Trans] Murray Kucherawy's Discuss on draft-ietf-trans-rfc6962-bis-36: (with DISCUSS)

CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.

https://github.com/google/certificate-transparency-rfcs/pull/334<https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fgoogle%2Fcertificate-transparency-rfcs%2Fpull%2F334&data=04%7C01%7C%7Ca79b9e57bc674a5bc40f08d916fe6f97%7C0e9c48946caa465d96604b6968b49fb7%7C0%7C0%7C637566104446649926%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=cR69ul1vCZSqNb7vivgsFtDbKWtbSTJbvmWKCHdI5Y8%3D&reserved=0>

---

From: Paul Wouters <[email-masked]>
Date: Fri, 14 May 2021 14:42:33 -0400 (EDT)

On Fri, 14 May 2021, Rob Stradling wrote:

> Although TRANS is set to wind down without really looking beyond 6962-bis, the original Charter also envisaged exploring
> "mechanisms and techniques that allow cryptographically verifiable logs to be deployed to improve the security of protocols other
> than HTTP over TLS, for example SMTP/TLS or software distribution", and this was a consideration when we planned the
> (sub-)registries that 6962-bis requests to be created.  Perhaps there will be renewed interest in exploring such things in the
> future, and if so, it's conceivable that folks will want to reuse mechanisms from 6962-bis and reuse the (sub-)registries.
> 
> So I would prefer to name the new, main registry "Public Notary Transparency" (the full name of this WG -
> see https://datatracker.ietf.org/wg/trans), and either (i) strip the "CT " prefix from the sub-registry names or (ii) change the
> prefix from "CT " to "Transparency ".
> 
> Does that make sense?

(no hats on)

It makes sense to me.

Paul

---

From: "Salz, Rich" <[email-masked]>
Date: Fri, 14 May 2021 18:43:02 +0000

*   So I would prefer to name the new, main registry "Public Notary Transparency" (the full name of this WG - see https://datatracker.ietf.org/wg/trans<https://urldefense.com/v3/__https:/datatracker.ietf.org/wg/trans__;!!GjvTz_vk!Bo7jfZKkixzxPHHLzViz0jeQMnIrAVR9rczmzAG3my-y1dc4DR5qm5pPDEFT$>), and either (i) strip the "CT " prefix from the sub-registry names or (ii) change the prefix from "CT " to "Transparency ".

It makes sense to me that the registries follow the official name.  I pushed a commit to the PR that makes the rename and just strips the initial “CT” word from the sub-registries.