<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<br>
<br>
<div class="moz-cite-prefix">On 6/8/15 10:18 AM, Nate Klingenstein
wrote:<br>
</div>
<blockquote
cite="mid:16720137-BE62-4107-BDFE-F422B15BE8F7@internet2.edu"
type="cite">
<meta http-equiv="Content-Type" content="text/html;
charset=windows-1252">
<br class="">
<div><br>
<blockquote type="cite" class="">
<div class=""><span style="font-family: Helvetica; font-size:
12px; font-style: normal; font-variant: normal;
font-weight: normal; letter-spacing: normal; line-height:
normal; orphans: auto; text-align: start; text-indent:
0px; text-transform: none; white-space: normal; widows:
auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;
float: none; display: inline !important;" class="">A trust
engine can do anything is the point, and you could chain
trust engines together with multiple keys if you really
didn't care who signed what (which itself is a problem, so
that's the main reason edugain really doesn't work like
that).</span></div>
</blockquote>
</div>
<br class="">
</blockquote>
<br>
Right, the new (in v3) ability to specify a single key/cert on the
filter is really just a convenience, since it's the 99% case
probably. If you want to do advanced things, you do a full trust
engine like in v2.<br>
<br>
You could have either multiple engines in a chain, or more likely a
single engine with multiple trusted credentials.<br>
<br>
<br>
<blockquote
cite="mid:16720137-BE62-4107-BDFE-F422B15BE8F7@internet2.edu"
type="cite">
<div class="">I was more interested in the ability to associate
providers with authorities, maybe through an entity tag, the
registrar tag, or even a dumb regex match on the entityID than
the ability for anyone to sign anything -- see browser CA's.</div>
<br>
</blockquote>
<br>
Just thinking out loud: We could in theory support something like a
Function<XMLObject, Set<String>> on the filter, allowing
one to map which trusted credentials' managed by an explicit key
trust engine were resolved by the underlying credential resolver,
and therefore acceptable for validating a particular signature. I
could imagine it being configured via one or more a
Map<String,String>. E.g. Key A is valid for entityIDs X, Y,
Z; key B is valid for EntitiesDescriptors with @name of D, E, F,
etc. If we really want to go there... Also heinous for deployers,
I'm sure. A model where an aggregator/publisher resigns what it
publishes with a single key is probably much more tenable. <br>
<br>
We already did something similar for dynamically constructing the
set of PKIX trusted names used in validating the signing cert with
the PKIX engines. Btw, that is the other way to go here for this
kind of thing: PKIX trust anchors (perhaps just 1) that issue
signing certs to the parties who then self-sign their own metadata;
similar to the above, the trust is based on mapping expected names
from the signed thingies to the name(s) in the cert. E.g. you trust
the signing cert for EntityDescriptor with entityID X because it's
chained to a trusted root and the cert contains the entityID X as a
CN or alt name. That's supported today.<br>
<br>
<br>
</body>
</html>