Re: [TLS] draft-ietf-tls-cached-info-14

Rob Stradling <rob.stradling@comodo.com> Wed, 10 April 2013 14:10 UTC

Return-Path: <rob.stradling@comodo.com>
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 4433C21F9840 for <tls@ietfa.amsl.com>; Wed, 10 Apr 2013 07:10:21 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1FMv8RIzBmud for <tls@ietfa.amsl.com>; Wed, 10 Apr 2013 07:10:20 -0700 (PDT)
Received: from mmmail2.mcr.colo.comodoca.net (mdfw.comodoca.net [91.209.196.68]) by ietfa.amsl.com (Postfix) with ESMTP id 5EB0B21F983F for <tls@ietf.org>; Wed, 10 Apr 2013 07:10:14 -0700 (PDT)
Received: (qmail 32534 invoked from network); 10 Apr 2013 14:10:13 -0000
Received: from ian.brad.office.comodo.net (192.168.0.202) by mail.colo.comodoca.net with ESMTPS (DHE-RSA-AES256-SHA encrypted); 10 Apr 2013 14:10:13 -0000
Received: (qmail 18200 invoked by uid 1000); 10 Apr 2013 14:10:13 -0000
Received: from nigel.brad.office.comodo.net (HELO [192.168.0.58]) (192.168.0.58) (smtp-auth username rob, mechanism plain) by ian.brad.office.comodo.net (qpsmtpd/0.40) with (CAMELLIA256-SHA encrypted) ESMTPSA; Wed, 10 Apr 2013 15:10:13 +0100
Message-ID: <516572C4.8000300@comodo.com>
Date: Wed, 10 Apr 2013 15:10:12 +0100
From: Rob Stradling <rob.stradling@comodo.com>
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130328 Thunderbird/17.0.5
MIME-Version: 1.0
To: Piyush Jain <piyush@ditenity.com>
References: <2C078811-2A81-4B37-82F0-FAD94A7395BD@gmx.net> <51547C0C.20806@ieca.com> <A3EEC7FB-665B-4543-8D42-A997100506E5@gmx.net> <5154B4C9.1070405@comodo.com> <5096AB41-02FD-4E01-A78E-BEF272181F42@gmx.net> <5162C154.1010202@comodo.com> <op.wu76e6o73dfyax@killashandra.invalid.invalid> <5163200D.2030300@comodo.com> <op.wu8nh01v3dfyax@killashandra.invalid.invalid> <51646709.4030803@comodo.com> <op.wvakl2sk3dfyax@killashandra.invalid.invalid> <097601ce3574$f4495c50$dcdc14f0$@ditenity.com> <51656C00.8030200@comodo.com> <0a1001ce35f4$00409d50$00c1d7f0$@ditenity.com>
In-Reply-To: <0a1001ce35f4$00409d50$00c1d7f0$@ditenity.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Cc: tls@ietf.org
Subject: Re: [TLS] draft-ietf-tls-cached-info-14
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
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: <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: Wed, 10 Apr 2013 14:10:21 -0000

On 10/04/13 15:02, Piyush Jain wrote:
>> When you say "The position of the value corresponds to the position of
>> certificate in the certificate chain", I presume you're referring to the
>> CachedObject(s) of type "certificate_chain" that the client sends.
> [Piyush] Correct.
>
>>
>> If a client were to send >1 CachedObjects of type "certificate_chain"
>> and >1 "list of Boolean values" CachedObjects, there could be ambiguity
> over
>> which "certificate_chain" is paired with which "list of Boolean values".
>>
>> Would we simply say that the CachedObject(s) of these two types must be
>> sent in the same order?
>> Or would we need to squeeze the "list of Boolean values" into the
>> "certificate_chain" CachedObject type somehow?
>>
>
> [Piyush]
> Either approach would work (it is just different representation of same
> information). However, keeping them separate would be better just because
> implementations may want to support caching of certificate_chain and may not
> want to support caching of OCSP responses.

Agreed.

Also, we'd have to state that the number of "list of Boolean values" 
CachedObjects sent by the client MUST be either i) zero or ii) exactly 
the same as the number of "certificate_chain" CachedObject(s).

> Given that certificate_chain cached object represents a list of certificates
> with strict rules on ordering,  ocsp cached object would be a list with same
> number of entries and same ordering as those of certificate chain.

Agreed.

-- 
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online