archive)" <shibboleth-users@googlegroups.com>
Received: by 10.216.134.5 with SMTP id r5mr283821wei.6.1331770922737;
        Wed, 14 Mar 2012 17:22:02 -0700 (PDT)
X-BeenThere: shibboleth-users@googlegroups.com
Received: by 10.180.146.202 with SMTP id te10ls5301480wib.4.gmail; Wed, 14 Mar
 2012 17:22:02 -0700 (PDT)
Received: by 10.180.72.229 with SMTP id g5mr853258wiv.3.1331770922589;
        Wed, 14 Mar 2012 17:22:02 -0700 (PDT)
Received: by 10.180.72.229 with SMTP id g5mr853257wiv.3.1331770922543;
        Wed, 14 Mar 2012 17:22:02 -0700 (PDT)
Return-Path: <users-boun...@shibboleth.net>
Received: from shibboleth.net (dlib-shibdev1.ucs.ed.ac.uk. [129.215.128.28])
        by gmr-mx.google.com with ESMTP id n1si151145wiy.0.2012.03.14.17.22.02;
        Wed, 14 Mar 2012 17:22:02 -0700 (PDT)
Received-SPF: neutral (google.com: 129.215.128.28 is neither permitted nor denied by best guess record for domain of users-boun...@shibboleth.net) client-ip=129.215.128.28;
Authentication-Results: gmr-mx.google.com; spf=neutral (google.com: 129.215.128.28 is neither permitted nor denied by best guess record for domain of users-boun...@shibboleth.net) smtp.mail=users-boun...@shibboleth.net
Received: from dlib-shibdev1.ucs.ed.ac.uk (localhost.localdomain [127.0.0.1])
	by shibboleth.net (Postfix) with ESMTP id 39E3E101169;
	Thu, 15 Mar 2012 00:21:56 +0000 (GMT)
X-Original-To: us...@shibboleth.net
Delivered-To: us...@shibboleth.net
Received: from dalziel.ucs.ed.ac.uk (dalziel.ucs.ed.ac.uk [129.215.13.80])
	by shibboleth.net (Postfix) with ESMTP id DD5311010B5
	for <us...@shibboleth.net>; Thu, 15 Mar 2012 00:21:54 +0000 (GMT)
Received: from mail-yw0-f45.google.com (mail-yw0-f45.google.com
	[209.85.213.45])
	by dalziel.ucs.ed.ac.uk (8.13.8/8.13.4) with ESMTP id q2F0Lm22005946
	for <us...@shibboleth.net>; Thu, 15 Mar 2012 00:21:54 GMT
Received: by yhoo21 with SMTP id o21so3096413yho.32
	for <us...@shibboleth.net>; Wed, 14 Mar 2012 17:21:48 -0700 (PDT)
	d=google.com; s=20120113;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:content-type:x-gm-message-state;
	bh=HtBnkbwyQNmzQdVFn8Kf/g6mOClk6Ca6wNkttXi98rI=;
	b=d/TmjuNDEDR+15eNhDjInduXtIFScrh7xhjpbUvyfAvVk5u5Fq7pbXxffrGUHEbOFG
	WVZe+ReElM+92+qSXp/QUBxzbQCLqri/mmowTgGtSoh9l2UOu6uwrYLl46mIw7i2sM/f
	13JsDtllLLykfYs8gYJG5RCVDUDqA2iSiLvGYUit8wjgU7iXFi/IAWxqjn7oQ+mCEG8B
	F0ghAn/xhugR3MDrhMb9/xBsGD8e1L0B4hD3S/FOnX5L6d6391YFPf89GdTIAQuH3a/n
	xXqmw43SzJXhKBx8SbIV7QpggZ/Apd9nY2VgYg2MpW7uoJGSShAFpt1OO1ZSv1Tfyh/Q
	BQbg==
MIME-Version: 1.0
Received: by 10.60.25.196 with SMTP id e4mr5713062oeg.53.1331770907840; Wed,
	14 Mar 2012 17:21:47 -0700 (PDT)
Received: by 10.182.74.161 with HTTP; Wed, 14 Mar 2012 17:21:47 -0700 (PDT)
In-Reply-To: <4F612BB4.4020...@ucdavis.edu>
References: <4F612BB4.4020...@ucdavis.edu>
Date: Wed, 14 Mar 2012 20:21:47 -0400
Message-ID: <CACTY7uDB7sSN+wkHh7zFjZ1UcQFKdoSkjm9zyD0gdFfE99K...@mail.gmail.com>
Subject: Re: Metadata "trust"
From: Chad La Joie <laj...@itumi.biz>
To: Shib Users <us...@shibboleth.net>
X-Gm-Message-State: ALoCoQm8LrSWls863dkYDOB8CwTaYQ+j33VPpvgiwkYobh/oUzTcitvzWPXujoGaHAf8IP+aWzjN
X-Spam-Score: 0
X-Spam-Level: 
X-Spam-Status: hits=0.747 tests=BIZ_TLD version=2.64+local
X-Edinburgh-Scanned: at dalziel.ucs.ed.ac.uk
	with MIMEDefang 2.60, Sophie, Sophos Anti-Virus, Clam AntiVirus
X-Scanned-By: MIMEDefang 2.60 on 129.215.13.80
X-BeenThere: us...@shibboleth.net
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: Shib Users <us...@shibboleth.net>
List-Id: Shib Users <users.shibboleth.net>
List-Unsubscribe: <http://shibboleth.net/mailman/listinfo/users>,
	<mailto:users-requ...@shibboleth.net?subject=unsubscribe>
List-Archive: <http://shibboleth.net/pipermail/users>
List-Post: <mailto:us...@shibboleth.net>
List-Help: <mailto:users-requ...@shibboleth.net?subject=help>
List-Subscribe: <http://shibboleth.net/mailman/listinfo/users>,
	<mailto:users-requ...@shibboleth.net?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: users-boun...@shibboleth.net
Errors-To: users-boun...@shibboleth.net

There isn't "one true way" for establishing trust.

I think most rational and informed people, by now, harbor concerns
about the entire public CA infrastructure and what, exactly, it's
providing them.  That doesn't mean it's wrong but people certainly
need to take claims about CAs infallibility with a grain (or 5 pound
block) of salt. If you know their processes, and you're good with
them, then go for it.

Added to the general issues of public CAs, trusting metadata because
it's delivered over a trust SSL/TLS connection means that you are
willing to trust any information anyone with access to that server
publishes.   If you know their processes, and you're good with them,
then go for it.

In both cases there are dozens of switches and knobs that can be
adjusted.  In most cases you probably can get to a point where you're
comfortable.  How much work that will be will depend on where you set
the bar.

I think most technical people who have to deploy this stuff at scale
unanimously agree that PKI is very brittle and a source of a great
deal of pain and that blindly trusting everything published to a
server isn't good.  So we recommend self-signed certs and signed
metadata, ideally signed with an offline of HSM-protected key.

Specifically related to the metadata endpoints for the IdP and SP.
Scott and I have said repeatedly, those endpoints provide deployers a
starting point they can use to prepare their real metadata.  *Staring
point*, not ending state.

On Wed, Mar 14, 2012 at 19:37, Tom Poage <tfpo...@ucdavis.edu> wrote:
> I have a vendor telling me their decision to use an X.509 certificate
> signed by a well-known CA as SP encryption/signing key is to satisfy
> some clients requiring identity verification by a third-party CA (cf.
> high-assurance, EV, ... certs).
>
> The same also tells me to to use their
> https://.../Shibboleth.sso/Metadata URL with a
> FileBackedHTTPMetadataProvider in our IdP to accommodate key/certificate
> rollover when this encryption/signing certificate expires in three years.
>
> I haven't convinced myself to buy into this quite yet, except ...
>
> Section 4.3.3 (third bullet) of the saml-metadata-2.0 doc suggests (to
> me) fetching metadata over an SSL/TLS connection is sufficient as long
> as I trust the server. OK, so XML digital signature is perhaps not
> absolutely required to "trust" the metadata.
>
> Down side, the SP /Metadata URL does not provide a validUntil nor a
> digital signature, and I don't know if /Metadata end point knows how to
> respond to HTTP If-Modified-Since (doesn't appear to), so it looks like
> I'd need to poll every so many hours/days (maxRefreshDelay).
>
> As long as the vendor adheres to good key rollover practice, cf.
> https://wiki.shibboleth.net/confluence/display/SHIB2/NativeSPMultipleCredentials,
> then this might be workable.
>
> I'm wondering if the vendor is perhaps confused over differing roles of
> the web server certificate vs. the SP encryption/signing cert.
>
> Comments/suggestions/guidance?
>
> Thanks.
> Tom.
>
> --
> To unsubscribe from this list send an email to users-unsubscr...@shibboleth.net



-- 
Chad La Joie
www.itumi.biz
trusted identities, delivered
--
To unsubscribe from this list send an email to users-unsubscr...@shibboleth.net