> If you do not trust keystone to give you the right information you have > already lost as keystone is used (afaik) to check for authorization > anyway. >
This is true. > Can you be a little bit more explicit on the threat model you have in > mind and what guarantees Barbican would give you that would make it more > suitable to store public key than Keystone ? 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. 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. 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. -bryan
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
