Can we ditch support for <SecretKey> in credentials?

[Brent Putman]

On 4/15/14 12:10 PM, Rod Widdowson wrote:
> The security schema supports one or more <SecretKey> elements inside the
> xsi:type="BasicCredential". 

For the record, unless I'm misreading the schema, I think it's only 1
SecretKey.  It's a <choice> over either a <SecretKey>, or a <PublicKey>
+ optional <PrivateKey>. 

If the schema really does indicate multiples of these, then that's just
wrong.


> In V2 we parse the first one of these (silently dropping the rest on the
> floor),

Yeah, if it's trying to parse multiples, I think that's a mistake... 
(Actually, looking at it, I think that's just a reuse of helper code
that can support multiples.)


>  but as soon as we try to make some sense of these (prior to
> inserting them into a BasicCredential) the support code throws an exception
> because that is not yet supported.
>
> In V3 the support code is in the same state.

Yeah, I think Chad stubbed those out, but we obviously didn't really
support or document any symmetric key usage in v2.  So it just got left
in a TODO'ed state.


> I'm not an expert in this domain and so I just don't have the insight into
> the requirements.  So the question is whether I should duplicate the V3
> parsing (allowing us to bolt in SecretKey support at a later date without
> having to jiggle the parsers), or whether it suffices to issue a log.WARN if
> we discover such a declaration? Or both?

Given that in v3 we're trying to support other protocols than SAML, and
some of those might very well want to make use of shared secrets or
symmetric key crypto, I'd say we should just leave it in if possible.  I
think the only reason the support method is TODO'ed was a lack of
clarity about how to represent a symmetric key on disk.  In fact, Chad
had Javadoc-ed the decodeSecretKey method as "Decodes secret keys in DER
and PEM format.", which AFAIK doesn't make any sense, since I'm not
aware of any (commonly used) ASN.1 structures that represent symmetric
keys.  That's mostly because a struct isn't needed, since symmetric keys
tend to just be a single array of octets, and otherwise don't have any
structure.

In hindsight, I *think* it's pretty simple to turn a (probably
Base64-encoded) byte[] into a Java SecretKey using SecretKeySpec,
although you have to supply the key algorith and that's not currently
represented in the schema or in that helper method.  Maybe also some
validation as to acceptable key lengths.

I'll put in an issue to look into that, but I don't think it's a lot of
work.
 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://shibboleth.net/pipermail/dev/attachments/20140416/9827867f/attachment.html