<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<br>
<div class="moz-cite-prefix">On 5/14/14 7:49 PM, Cantor, Scott
wrote:<br>
</div>
<blockquote cite="mid:CF997833.CD60%25cantor.2@osu.edu" type="cite"><br>
<pre wrap="">
Yeah, that's the issue I had. What I meant was whether the encryption
resolver would add the usage criterion that limits the lookup to
encryption usage or if I had to do that myself. From what I can tell, I
have to do that, because otherwise it will use UNSPECIFIED, and return
arbitrary keys. That was why it wasn't working.</pre>
</blockquote>
<br>
No it wasn't doing that, but I agree that it should. Other
components do similar things as far as forcing the UsageType, this
was just an oversight. It doesn't make sense that it would resolve
non-encryption creds from metadata. I just checked that change in.
I'm literally in the middle of doing the unit tests for the SAML
encryption resolver, and hadn't gotten to all the edge cases yet,
but I probably would have eventually caught this. I guess we're
meeting in the middle....<br>
<br>
<br>
<blockquote cite="mid:CF997833.CD60%25cantor.2@osu.edu" type="cite">
<pre wrap="">
Separately, I don't know why I saw that Bouncy Castle stack trace on one
particular failed run, but I definitely did. I don't have a record of it
unfortunately.
</pre>
</blockquote>
<br>
<br>
It occurred to me after I left the house: I was taking your
statement literally, that the BC *provider* was involved. We
definitely don't want that - at least we don't want to auto-load
it. I'll double-check that there isn't something somewhere still
programatically adding the provider.<br>
<br>
But I did want to note for the record that we absolutely are using
BC classes, actually now more than in the past. In v2 we were mostly
just using some ASN.1 stuff from them. However, in v3 now we're
using cryptacular for the key and cert decoding. That is AFAIK 100%
based on the BC library - using the BC API directly, not using the
JCA Security provider architecture. So going forward most or all of
our keys and certs will be BC impl classes. So if you just saw a
org.bouncycastle.something class in the stack trace, that's not
necessarily unexpected.<br>
</body>
</html>