<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<br>
<div class="moz-cite-prefix">On 4/15/14 12:10 PM, Rod Widdowson
wrote:<br>
</div>
<blockquote
cite="mid:00ba01cf58c5$309ad9d0$91d08d70$@steadingsoftware.com"
type="cite">
<pre wrap="">The security schema supports one or more <SecretKey> elements inside the
xsi:type="BasicCredential".
</pre>
</blockquote>
<br>
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>. <br>
<br>
If the schema really does indicate multiples of these, then that's
just wrong.<br>
<br>
<br>
<blockquote
cite="mid:00ba01cf58c5$309ad9d0$91d08d70$@steadingsoftware.com"
type="cite">
<pre wrap="">
In V2 we parse the first one of these (silently dropping the rest on the
floor),</pre>
</blockquote>
<br>
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.)<br>
<br>
<br>
<blockquote
cite="mid:00ba01cf58c5$309ad9d0$91d08d70$@steadingsoftware.com"
type="cite">
<pre wrap=""> 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.
</pre>
</blockquote>
<br>
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.<br>
<br>
<br>
<blockquote
cite="mid:00ba01cf58c5$309ad9d0$91d08d70$@steadingsoftware.com"
type="cite">
<pre wrap="">
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?
</pre>
</blockquote>
<br>
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.<br>
<br>
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. <br>
<br>
I'll put in an issue to look into that, but I don't think it's a lot
of work.<br>
<br>
<br>
</body>
</html>