[websec] Service auto-configuration and certificate pinning
Marten Gajda <marten@dmfs.org> Wed, 22 June 2016 21:39 UTC
Return-Path: <marten@dmfs.org>
X-Original-To: websec@ietfa.amsl.com
Delivered-To: websec@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0588512DD38 for <websec@ietfa.amsl.com>; Wed, 22 Jun 2016 14:39:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.02
X-Spam-Level:
X-Spam-Status: No, score=-2.02 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=dmfs.org
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 ncUeCFCS8wqH for <websec@ietfa.amsl.com>; Wed, 22 Jun 2016 14:39:28 -0700 (PDT)
Received: from mailrelay6.public.one.com (mailrelay6.public.one.com [91.198.169.200]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 08B6E12D991 for <websec@ietf.org>; Wed, 22 Jun 2016 14:38:13 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dmfs.org; s=20140924; h=from:subject:date:message-id:to:mime-version:content-type: content-transfer-encoding; bh=QDku8qyU6QCHf1+Amimch4CQdEGTN1HPas4xOomtoxA=; b=YtnxqDnLhcwkCXGy+pu3UAJ/hjhjO7PKopcrrdunfQYvQ8HCwRCRAmeywZOo809sd+B93OQY++zbZ zXgUYo6MVGD839UKexL7Eo7EUlxDeqUD/ncckkUFuLQypqhTc27j1PC67DUw6HPErOd6CkEtTAQBam ZToI14vCpTIq7KRQ=
X-HalOne-Cookie: 5ca078c0160d77276743912f44628a3bc43f3df4
X-HalOne-ID: 9d8e55cf-38c1-11e6-9f37-b82a72d06996
Received: from smtp.dmfs.org (unknown [217.234.107.6]) by smtpfilter3.public.one.com (Halon Mail Gateway) with ESMTPSA for <websec@ietf.org>; Wed, 22 Jun 2016 21:38:10 +0000 (UTC)
Received: from localhost.localdomain (p5DDABB85.dip0.t-ipconnect.de [93.218.187.133]) by smtp.dmfs.org (Postfix) with ESMTPSA id 987B52F5 for <websec@ietf.org>; Wed, 22 Jun 2016 23:32:36 +0200 (CEST)
Message-ID: <576B0541.7040708@dmfs.org>
Date: Wed, 22 Jun 2016 23:38:09 +0200
From: Marten Gajda <marten@dmfs.org>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0
MIME-Version: 1.0
To: websec@ietf.org
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/websec/lVB0L1p7wr5grZIPOqKvyEftEZg>
Subject: [websec] Service auto-configuration and certificate pinning
X-BeenThere: websec@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Web Application Security Minus Authentication and Transport <websec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/websec>, <mailto:websec-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/websec/>
List-Post: <mailto:websec@ietf.org>
List-Help: <mailto:websec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/websec>, <mailto:websec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 22 Jun 2016 21:39:31 -0000
Hi list, I'm currently working on an update of a draft that specifies a way for clients to configure themselves with a minimum of user-provided information. The current draft is available at https://tools.ietf.org/html/draft-daboo-aggregated-service-discovery-03 (it's a bit outdated, but we're working on it). This draft specifies a member to contain a server certificate, which presumably was meant to support some sort of certificate pinning. During my research on how to improve this I came across RFC 7469 and https://tools.ietf.org/html/draft-hallambaker-webseccaa-00 I'd like to ask the members of this list whether they think that "bootstrapping" certificate pinning for individual services (like so: https://github.com/CalConnect/AUTODISCOVERY/issues/8#issuecomment-227857982) would be useful to have in a service configuration document or if they have any concerns or other comments about this. I'd also like to hear about opinions if this could be an acceptable solution for certificate pinning with non-HTTP based protocols, i.e. for protocols that don't have an in-band pinning mechanism the client would reload the service configuration document whenever the cached pinning information is outdated (i.e. <max-age> seconds have passed since it was downloaded). Any comments (whether in response to this post or at GitHub) are very welcome. Regards, Marten Gajda -- Marten Gajda CEO dmfs GmbH Schandauer Straße 34 01309 Dresden GERMANY phone: +49 177 4427167 email: marten@dmfs.org Managing Director: Marten Gajda Registered address: Dresden Registered No.: AG Dresden HRB 34881 VAT Reg. No.: DE303248743
- Re: [websec] Service auto-configuration and certi… Yaron Sheffer
- Re: [websec] Service auto-configuration and certi… Marten Gajda
- Re: [websec] Service auto-configuration and certi… Stephen Farrell
- Re: [websec] Service auto-configuration and certi… D.Rogers
- [websec] Service auto-configuration and certifica… Marten Gajda