IETF Logo Mail Archive

Re: [TLS] New version of Multiple OCSP mode of Certificate Status extension

"Yngve N. Pettersen" <yngve@opera.com> Tue, 27 July 2010 13:30 UTC

Return-Path: <yngve@opera.com>
X-Original-To: tls@core3.amsl.com
Delivered-To: tls@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0F43E3A6994; Tue, 27 Jul 2010 06:30:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level:
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HbNa+7WH8j9R; Tue, 27 Jul 2010 06:30:45 -0700 (PDT)
Received: from smtp.opera.com (smtp.opera.com [213.236.208.81]) by core3.amsl.com (Postfix) with ESMTP id 39E503A6995; Tue, 27 Jul 2010 06:30:42 -0700 (PDT)
Received: from lessa-ii (dhcp-70b3.meeting.ietf.org [130.129.112.179]) (authenticated bits=0) by smtp.opera.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id o6RDUqos025727 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 27 Jul 2010 13:30:55 GMT
Content-Type: text/plain; charset="iso-8859-15"; format="flowed"; delsp="yes"
To: tls@ietf.org, Rob Stradling <rob.stradling@comodo.com>
References: <op.u87n4tthqrq7tp@acorna> <op.vghzp61ivqd7e2@killashandra.oslo.osa> <201007271329.22243.rob.stradling@comodo.com>
Date: Tue, 27 Jul 2010 15:30:56 +0200
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
From: "Yngve N. Pettersen" <yngve@opera.com>
Organization: Opera Software ASA
Message-ID: <op.vgh7tumrkvaitl@lessa-ii>
In-Reply-To: <201007271329.22243.rob.stradling@comodo.com>
User-Agent: Opera Mail/10.60 (Win32)
Cc: "pkix@ietf.org" <pkix@ietf.org>
Subject: Re: [TLS] New version of Multiple OCSP mode of Certificate Status extension
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.9
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/listinfo/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/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: Tue, 27 Jul 2010 13:30:52 -0000

On Tue, 27 Jul 2010 14:29:21 +0200, Rob Stradling  
<rob.stradling@comodo.com> wrote:

> On Tuesday 27 July 2010 11:35:56 Yngve Nysaeter Pettersen wrote:
>> Hello all,
>>
>> Based on the ongoing PKIX discussion about an update of OCSP, I  
>> (finally)
>> realized the the problem my multiple-ocsp TLS extension is designed to  
>> fix
>> can be fixed in another way, by adding an OCSP extension instead.
>
> Hi Yngve.  That's an interesting idea, but (from my viewpoint as an OCSP
> Responder implementer) I'm not convinced that we should do it.
>
> You ended by suggesting that the Multiple OCSP TLS Extension should  
> still be
> standardized and implemented widely (in clients and servers that support  
> OCSP

Just a clarification: What I was referring to was the  
"CertificateStatus_v2" extension (not the Multiple OCSP method option in  
that extension), which was necessary for a client to be able to signal  
support for both old and new OCSP stapling. The multiple OCSP definition  
would no longer be part of that limite specification.

-- 
Sincerely,
Yngve N. Pettersen

********************************************************************
Senior Developer                     Email: yngve@opera.com
Opera Software ASA                   http://www.opera.com/
Phone:  +47 24 16 42 60              Fax:    +47 24 16 40 01
********************************************************************

v2.23.0 | Report a Bug | By Email