[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