[TLS] clarifications on TLS extension "Certificate Status Request"
Nagendra Modadugu <ngm+ietf@google.com> Mon, 22 June 2009 19:14 UTC
Return-Path: <ngm@google.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 20C803A6C40 for <tls@core3.amsl.com>; Mon, 22 Jun 2009 12:14:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.977
X-Spam-Level:
X-Spam-Status: No, score=-101.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, USER_IN_WHITELIST=-100]
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 N3oXY2ZEjRAB for <tls@core3.amsl.com>; Mon, 22 Jun 2009 12:14:05 -0700 (PDT)
Received: from smtp-out.google.com (smtp-out.google.com [216.239.45.13]) by core3.amsl.com (Postfix) with ESMTP id C79343A6DDF for <tls@ietf.org>; Mon, 22 Jun 2009 12:13:41 -0700 (PDT)
Received: from spaceape8.eur.corp.google.com (spaceape8.eur.corp.google.com [172.28.16.142]) by smtp-out.google.com with ESMTP id n5MJDuRZ031788 for <tls@ietf.org>; Mon, 22 Jun 2009 12:13:57 -0700
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1245698037; bh=NwyG3vrs7GNM3ykF5dnwdtrdbYE=; h=DomainKey-Signature:MIME-Version:Date:Message-ID:Subject:From:To: Content-Type:Content-Transfer-Encoding:X-System-Of-Record; b=MS5zp FzDtzz/60NlkCTpPmVGycD5uF0hcrCaZlt5HADVebmT/irVJvmvcekD2d4bQ5mU6D8B ym4wbnKKNRUMVQ==
DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:date:message-id:subject:from:to:content-type: content-transfer-encoding:x-system-of-record; b=Zmj7XMgg8wJ20VlkNLFnwkCaXRNrmjGhMUf9wUfxl3XEnVzgPV1KO1A4z/4HMDsyH GD8FOvgGqC+lH8Ge8TdxA==
Received: from gxk28 (gxk28.prod.google.com [10.202.11.28]) by spaceape8.eur.corp.google.com with ESMTP id n5MJDPOC009235 for <tls@ietf.org>; Mon, 22 Jun 2009 12:13:54 -0700
Received: by gxk28 with SMTP id 28so6377950gxk.14 for <tls@ietf.org>; Mon, 22 Jun 2009 12:13:53 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.90.74.7 with SMTP id w7mr5487050aga.33.1245697555688; Mon, 22 Jun 2009 12:05:55 -0700 (PDT)
Date: Mon, 22 Jun 2009 12:05:54 -0700
Message-ID: <28425e380906221205k573972eblcff591d51634621d@mail.gmail.com>
From: Nagendra Modadugu <ngm+ietf@google.com>
To: TLS wg <tls@ietf.org>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
X-System-Of-Record: true
Subject: [TLS] clarifications on TLS extension "Certificate Status Request"
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: Mon, 22 Jun 2009 19:14:06 -0000
I am currently implementing the "Certificate Status Request" extension (RFC4366) for NSS. The primary use of this implementation will be OCSP verification of certificates presented by SSL websites. For the general Internet context, I am unable to find a case where a client should specify a non-empty responder_id_list. But in any case, say that the client does specify a responderID (to a general SSL webserver), what is the server supposed to do? The responderID is supposed to be either 1) the hash of the responder public key, or 2) a name (convention appears to be SubjectName of the responder). Unless convention for a responderID "name" is a AIA URL (and clients use a URL over a hash), the webserver will have to be pre-configured to determine appropriate end-points for each possible responder. What is the recommended way to specify responderIDs? Also, for the next revision of this RFC, it would useful to allow servers to return multiple OCSP responses, as EV certificates tend to be chained. nagendra
- [TLS] clarifications on TLS extension "Certificat… Nagendra Modadugu