Re: [TLS] Proposed Change to Certificate message (#654)

Ilari Liusvaara <ilariliusvaara@welho.com> Sat, 24 September 2016 12:09 UTC

Return-Path: <ilariliusvaara@welho.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 114D112B70B for <tls@ietfa.amsl.com>; Sat, 24 Sep 2016 05:09:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.216
X-Spam-Level:
X-Spam-Status: No, score=-4.216 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-2.316] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JU3vVhOQ_TxR for <tls@ietfa.amsl.com>; Sat, 24 Sep 2016 05:09:03 -0700 (PDT)
Received: from welho-filter4.welho.com (welho-filter4.welho.com [83.102.41.26]) by ietfa.amsl.com (Postfix) with ESMTP id C263C12B2DA for <TLS@ietf.org>; Sat, 24 Sep 2016 05:09:02 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by welho-filter4.welho.com (Postfix) with ESMTP id 281EE16633; Sat, 24 Sep 2016 15:09:01 +0300 (EEST)
X-Virus-Scanned: Debian amavisd-new at pp.htv.fi
Received: from welho-smtp2.welho.com ([IPv6:::ffff:83.102.41.85]) by localhost (welho-filter4.welho.com [::ffff:83.102.41.26]) (amavisd-new, port 10024) with ESMTP id pE0oKhoInL_g; Sat, 24 Sep 2016 15:09:00 +0300 (EEST)
Received: from LK-Perkele-V2 (87-100-237-87.bb.dnainternet.fi [87.100.237.87]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp2.welho.com (Postfix) with ESMTPSA id DC56327B; Sat, 24 Sep 2016 15:09:00 +0300 (EEST)
Date: Sat, 24 Sep 2016 15:08:57 +0300
From: Ilari Liusvaara <ilariliusvaara@welho.com>
To: Martin Thomson <martin.thomson@gmail.com>
Message-ID: <20160924120857.GA8293@LK-Perkele-V2.elisa-laajakaista.fi>
References: <CAOjisRyDx0Wa5tcFT3gN496jhf-AjLfDH4JNN+w70r8jBsxt5g@mail.gmail.com> <CAFewVt4SOTU18xj45i_Eox2g5zaZyTyD6SP86cjBciXpuC+sDw@mail.gmail.com> <CAOjisRwcR3NUCnCsA+kauGNiOz-TAezskYzM8g3V9nxUCFoaWw@mail.gmail.com> <CABcZeBPOsBXv3yCoVrQmfM99JvaD0P=7Wy0EG5wY_d=dTH_Oug@mail.gmail.com> <CAAZdMacihp1pxk76UY2n66ZqDvcOeqS8vm0n3mObkSBVY0PwBg@mail.gmail.com> <CAOjisRwHUSEthSt6Tt6hYRRnhW6snWiZrCS+sN17VnCRz=e5ow@mail.gmail.com> <20160924091751.GA7834@LK-Perkele-V2.elisa-laajakaista.fi> <CABkgnnWH=3M442s01NsUeJTN+gD2Dr3+3J+s5pECq_PeoBS=Pg@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
In-Reply-To: <CABkgnnWH=3M442s01NsUeJTN+gD2Dr3+3J+s5pECq_PeoBS=Pg@mail.gmail.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
Sender: ilariliusvaara@welho.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/xpX1uywZWrUSzaMxekvYCL_-hE4>
Cc: "tls@ietf.org" <TLS@ietf.org>
Subject: Re: [TLS] Proposed Change to Certificate message (#654)
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.17
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: <https://mailarchive.ietf.org/arch/browse/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: Sat, 24 Sep 2016 12:09:05 -0000

On Sat, Sep 24, 2016 at 09:31:51PM +1000, Martin Thomson wrote:
> On 24 September 2016 at 19:17, Ilari Liusvaara <ilariliusvaara@welho.com> wrote:
> > It occured to me that certain extensions might be considered to be per-
> > chain. Like e.g. type of the certificate. Where do extensions like that
> > go? Always to the extension block of the first certificate (except that
> > might cause somewhat of a cyclic dependency in parsing)?
> 
> The type of which certificate?  The end-entity?  Seems like that
> belongs with the end-entity cert then.

I mean equivalent of the client_certificate_type/server_certificate_type
extensions.

And the way those extensions are defined, those scope the entiere chain.

E.g. There was some discussion about "subcerts"[1]. One way to add those
would be as a new certificate type.

... Or are new certificate types like new CLASSes in DNS: Heavy objects
dropped by bad idea fairy? :->


But in the future, there might very well be new extensions that are
scoped to certificate chain and not and individual certificate. And
those can't be put into EncryptedExtensions if server can send multiple
certificates (like it can in post-handshake auth extension) or if
client needs to send one.


[1] The usecases can't be practically accomplished today: The mode of
operation is just plain alien to X.509.


-Ilari