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
- [TLS] Proposed Change to Certificate message (#65… Nick Sullivan
- Re: [TLS] Proposed Change to Certificate message … Brian Smith
- Re: [TLS] Proposed Change to Certificate message … Nick Sullivan
- Re: [TLS] Proposed Change to Certificate message … Ilari Liusvaara
- Re: [TLS] Proposed Change to Certificate message … Eric Rescorla
- Re: [TLS] Proposed Change to Certificate message … Victor Vasiliev
- Re: [TLS] Proposed Change to Certificate message … Nick Sullivan
- Re: [TLS] Proposed Change to Certificate message … Ilari Liusvaara
- Re: [TLS] Proposed Change to Certificate message … Martin Thomson
- Re: [TLS] Proposed Change to Certificate message … Ilari Liusvaara
- Re: [TLS] Proposed Change to Certificate message … Sean Turner
- Re: [TLS] Proposed Change to Certificate message … Ilari Liusvaara
- Re: [TLS] Proposed Change to Certificate message … Martin Thomson
- Re: [TLS] Proposed Change to Certificate message … Ilari Liusvaara
- Re: [TLS] Proposed Change to Certificate message … Martin Thomson
- Re: [TLS] Proposed Change to Certificate message … Nick Sullivan