Subject: [Trans] 6962bis and signed_certificate_timestamp issue

From: Paul Wouters <[email-masked]>
Date: Fri, 22 Feb 2019 10:24:23 -0500 (EST)

This issue is still open:

 	TLS 1.3 (https://tools.ietf.org/html/rfc8446) has several mentions of
 	the RFC6962 signed_certificate_timestamp TLS extension.  Since 6962-bis
 	intends to obsolete RFC6962 and replace signed_certificate_timestamp
 	with a new TLS extension (transparency_info), should we also add a
 	sentence to the 6962-bis Abstract along these lines...
 	   "This document also specifies new requirements for TLS 1.0, 1.1, 1.2
 	    and 1.3 implementations."
 	?

 	Do we even need to mark 6962-bis as Updating RFC8446?

 	(Can an Experimental RFC update a Standards Track RFC?)

---

From: Rob Stradling <[email-masked]>
Date: Fri, 22 Feb 2019 15:34:40 +0000

Hi Paul.  That issue is from an offline discussion between the A-Ds, the 
TRANS WG Chairs, and the 6962-bis authors.  Ben K answered those 
questions (on 3rd Nov 2018) as follows:

"> Do we even need to mark 6962-bis as Updating RFC8446?

Creating a new TLS extension does not require uptading the core TLS spec.
But the suggested text about "new requirements for [...] TLS
implementations" is not good; better to talk about defining an extension
that is used for [stuff].

 > (Can an Experimental RFC update a Standards Track RFC?)

No."

I addressed this in PR#302 [1] by adding [2] the following text to the 
Abstract:

"It also specifies a new TLS extension that is used to send various CT 
log artifacts."

[1] https://github.com/google/certificate-transparency-rfcs/pull/302

[2] 
https://github.com/google/certificate-transparency-rfcs/commit/e18322235c409bf7150eb0b86384fbddaecc9660

On 22/02/2019 15:24, Paul Wouters wrote:
> _______________________________________________
> Trans mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/trans

-- 
Rob Stradling
Senior Research & Development Scientist
Email: [email-masked]
Bradford, UK
Office: +441274024707
Sectigo Limited

This message and any files associated with it may contain legally 
privileged, confidential, or proprietary information. If you are not the 
intended recipient, you are not permitted to use, copy, or forward it, 
in whole or in part without the express consent of the sender. Please 
notify the sender by reply email, disregard the foregoing messages, and 
delete it immediately.

---

From: Paul Wouters <[email-masked]>
Date: Fri, 22 Feb 2019 11:41:59 -0500 (EST)

> questions (on 3rd Nov 2018) as follows:

ah thanks. I thought it was a followup to the pull request and never saw
an answer. So this is covered in -30 then.

Paul