Bouncy Castle?

[Brent Putman]

On 5/14/14 7:49 PM, Cantor, Scott wrote:
>
> 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.

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....


>
> 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.


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.

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://shibboleth.net/pipermail/dev/attachments/20140515/5b70ef55/attachment.html