<div dir="ltr"><br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">If you do not trust keystone to give you the right information you have<br>



already lost as keystone is used (afaik) to check for authorization<br>
anyway.<br></blockquote><div><br></div><div>This is true.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Can you be a little bit more explicit on the threat model you have in<br>



mind and what guarantees Barbican would give you that would make it more<br>
suitable to store public key than Keystone ?</blockquote><div><br></div><div style>I'm concerned about malicious tampering with the keys.  If the keys are then use for validating that a user is presenting the correct private key, this could result in an instance compromise.  Yes, if someone tampers with other data in keystone then it could result in a compromise as well.  This is true.</div>

<div style><br></div><div style>As I think about this some more, I think the best way to frame it is that -- for me -- key data and user / password data are two different classes that may have different security requirements.  It is nice to not mix the two, IMHO.  However, I can appreciate the simplicity that comes with just not using Barbican and throwing everything in Keystone.</div>

<div style><br></div><div style>WIth this in mind, I do like the idea of having Keystone return a pointer to the key location as URL.  This can be a ref back to a Keystone route.  Or it can be a ref to a Barbican route.  This would be most flexible and allow people to fullfil different security and auditing requirements.</div>

<div style><br></div><div style>-bryan</div><div> </div></div></div></div>