IETF Logo Mail Archive

Re: [TLS] PR#448: CertificateStatus to extension

"Yngve N. Pettersen" <yngve@spec-work.net> Mon, 02 May 2016 21:05 UTC

Return-Path: <yngve@spec-work.net>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E605B12D63C for <tls@ietfa.amsl.com>; Mon, 2 May 2016 14:05:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level:
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kexo9Ob1sYpF for <tls@ietfa.amsl.com>; Mon, 2 May 2016 14:05:28 -0700 (PDT)
Received: from smtp.domeneshop.no (smtp.domeneshop.no [IPv6:2a01:5b40:0:3005::1]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3E9B612D64C for <tls@ietf.org>; Mon, 2 May 2016 14:05:28 -0700 (PDT)
Received: from 137.71.202.84.customer.cdi.no ([84.202.71.137]:55951 helo=killashandra.invalid.invalid) by smtp.domeneshop.no with esmtpsa (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from <yngve@spec-work.net>) id 1axL1y-0001aY-Bz for tls@ietf.org; Mon, 02 May 2016 23:05:26 +0200
Content-Type: text/plain; charset="iso-8859-15"; format="flowed"; delsp="yes"
To: tls@ietf.org
References: <CABcZeBOBTe7juB1Ni=wkT3RJT8YJoy9KyGe5pbCaZFAL2JmmLw@mail.gmail.com>
Date: Mon, 02 May 2016 23:04:59 +0200
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
From: "Yngve N. Pettersen" <yngve@spec-work.net>
Message-ID: <op.ygusulhp3dfyax@killashandra.invalid.invalid>
In-Reply-To: <CABcZeBOBTe7juB1Ni=wkT3RJT8YJoy9KyGe5pbCaZFAL2JmmLw@mail.gmail.com>
User-Agent: Opera Mail/12.17 (Win32)
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/xJ0rhboF7VuVWiqVnx-q6mf2nis>
Subject: Re: [TLS] PR#448: CertificateStatus to extension
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tls/>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 02 May 2016 21:05:31 -0000

Hi,

On Mon, 02 May 2016 22:43:09 +0200, Eric Rescorla <ekr@rtfm.com> wrote:

> PR: https://github.com/tlswg/tls13-spec/pull/448
> Targe landing date: Wednesday
>
> In Buenos Aires we discussed moving CertificateStatus to part of the
> Certificate message. In offline conversations, it started to look like  
> that
> wasn't optimal in part because it created an asymmetry wrt Signed
> Certificate Timestamps. Instead, I propose just carrying the response in
> the response extensions.
>
> I just created PR#443, which moves the CertificateStatus response to an
> extension in EncryptedExtensions. Comments welcome.
>
> -Ekr

Regarding Certificate Status, is it such a good idea to keep both the  
original extension and the newer status_request_v2 extension in TLS 1.3?  
The client may have to signal the original extension in order to be  
interoperable with older TLS implementations, but wouldn't it be best if  
TLS 1.3 mandated the v2 extension in the server response?

-- 
Sincerely,
Yngve N. Pettersen

v2.23.0 | Report a Bug | By Email