IETF Logo Mail Archive

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

Peter Gutmann <pgut001@cs.auckland.ac.nz> Thu, 05 August 2010 11:10 UTC

Return-Path: <pgut001@cs.auckland.ac.nz>
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 471F23A6860; Thu, 5 Aug 2010 04:10:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.211
X-Spam-Level:
X-Spam-Status: No, score=-3.211 tagged_above=-999 required=5 tests=[AWL=0.388, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
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 ZkSU5gFNvyON; Thu, 5 Aug 2010 04:10:48 -0700 (PDT)
Received: from mx2-int.auckland.ac.nz (mx2-int.auckland.ac.nz [130.216.12.41]) by core3.amsl.com (Postfix) with ESMTP id 8A9873A6A95; Thu, 5 Aug 2010 04:10:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=pgut001@cs.auckland.ac.nz; q=dns/txt; s=uoa; t=1281006678; x=1312542678; h=from:to:subject:cc:in-reply-to:message-id:date; z=From:=20Peter=20Gutmann=20<pgut001@cs.auckland.ac.nz> |To:=20rob.stradling@comodo.com,=20yngve@opera.com |Subject:=20Re:=20[pkix]=20[TLS]=20New=20version=20of=20M ultiple=20OCSP=20mode=20of=20Certificate=20Status=20exten sion|Cc:=20pgut001@cs.auckland.ac.nz,=20pkix@ietf.org,=20 tls@ietf.org|In-Reply-To:=20<201008042304.05996.rob.strad ling@comodo.com>|Message-Id:=20<E1OgyM1-0007un-Db@winterm ute02.cs.auckland.ac.nz>|Date:=20Thu,=2005=20Aug=202010 =2023:11:17=20+1200; bh=om83Ge1VT5YZ5p42xNpYMKJpqi22ax2P/LlDZqjMywA=; b=D/tRIaPSotn1C2ifLx45nPoJPjSedYtPL4jSeLIHgAHexrKZAqSjf75+ EX6snOQTFRrHuFrKZR3Uuh1xlJvY7DkTW+AtvXvyE0VXyUCWMqzW3hFxv N4NwThCvNG6inVaYo2WEwuzAM1m9X0t+IB4kB/4A1+PBybcahJK/ZVfSf U=;
X-IronPort-AV: E=Sophos;i="4.55,321,1278244800"; d="scan'208";a="19395863"
X-Ironport-HAT: UNIVERSITY - $RELAY-THROTTLE
X-Ironport-Source: 130.216.207.92 - Outgoing - Outgoing
Received: from wintermute02.cs.auckland.ac.nz ([130.216.207.92]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 05 Aug 2010 23:11:17 +1200
Received: from pgut001 by wintermute02.cs.auckland.ac.nz with local (Exim 4.69) (envelope-from <pgut001@cs.auckland.ac.nz>) id 1OgyM1-0007un-Db; Thu, 05 Aug 2010 23:11:17 +1200
From: Peter Gutmann <pgut001@cs.auckland.ac.nz>
To: rob.stradling@comodo.com, yngve@opera.com
In-Reply-To: <201008042304.05996.rob.stradling@comodo.com>
Message-Id: <E1OgyM1-0007un-Db@wintermute02.cs.auckland.ac.nz>
Date: Thu, 05 Aug 2010 23:11:17 +1200
Cc: pkix@ietf.org, tls@ietf.org
Subject: Re: [TLS] [pkix] 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: Thu, 05 Aug 2010 11:10:49 -0000

Rob Stradling <rob.stradling@comodo.com> writes:

>I suspect not.  BasicOCSPResponse already allows a single Response to contain
>status information about multiple certificates for the same issuer.

This was being used by Identrus(t) a decade ago.

(I'm not aware of anything else that uses it and from what I heard back then
support for it in implementations was basically nonexistent).

>In fact, BasicOCSPResponse already allows a single Response to contain status
>information about multiple certificates from *multiple issuers*.  The problem,
>of course, is that a BasicOCSPResponse may only be signed by a single entity,
>so this kind of Response could only ever be useful in a "local configuration
>of OCSP signing authority" (RFC 2560 section 4.2.2.2 option 1) context.

Identrus did this with their transaction coordinators (OCSP gateways), with a
single responder signing for all responders that it crawled to build a
response.

Peter.

v2.23.0 | Report a Bug | By Email