Assurance

["Roy, Nicholas S" <>]

Absolutely.  :-)  But something like "you should do something safe with your 
SAML signing keys" might be good to have included by reference somewhere.  
There's also still the prescriptive "you must use a salt when hashing your 
passwords" piece, which I won't argue against, it's a good idea (LinkedIn...) 
but again is not possible with some systems and is not the only good way to 
protect your hashes.

Nick

-----Original Message-----
From: 

 
[mailto:]
 On Behalf Of Renee Shuey
Sent: Wednesday, July 18, 2012 4:56 PM
To: 

Cc: 

Subject: Re: [Assurance] Information Security Guide to InCommon IAP Cross 
Reference

I would caution you from heading down the path of becoming prescriptive. We 
worked very hard to remove such requirements recognizing the diversity of our 
environments. 

Renee

Sent from my iPad

On Jul 18, 2012, at 4:39 PM, "Roy, Nicholas S" 
<>
 wrote:

>> I continue to be surprised/concerned that this is not explicitly addressed 
>> in the Identity Assurance Profile.
> 
> Now that you mention it, yeah, that does seem like a pretty big omission.  
> Maybe that's assumed to be part of secure IdPO operations, but it seems 
> like it's worth explicitly calling out.  I don't know about use of keys in 
> the other FICAM profiles, but at least for the SAML2 profile, I'd think 
> this should be explicitly called out.
> 
> Nick
> 
> -----Original Message-----
> From: 
> 
>  
> [mailto:]
>  On Behalf Of Tom Scavo
> Sent: Wednesday, July 18, 2012 2:19 PM
> To: 
> 
> Subject: Re: [Assurance] Information Security Guide to InCommon IAP Cross 
> Reference
> 
> 
> 
>> I don't see anything that would apply to protecting private keys held
>> by the IdP.
> 
> Thanks for checking.
> 
>> Are you specifically thinking about the keys associated
>> with exchanging information with the IdP, or do you mean something
>> like key escrow for private keys associated with personal
>> certificates?
> 
> The former. Proper handling of the IdP's private signing key 
> (https://spaces.internet2.edu/x/E43NAQ) is critically important in a 
> federated scenario. I continue to be surprised/concerned that this is not 
> explicitly addressed in the Identity Assurance Profile.
> 
> Tom