search

mozilla / persona-roadmap

A repository for user stories related to Mozilla's Identity efforts.
3 stars 1 forks source link

As an IdP developer, I want to be able to publish several public keys, so that I can rotate my signing keys without invalidating the credentials of already-provisioned users. #44

Open callahad opened 11 years ago

r0bl0rd commented 11 years ago

The benefit of being able to seamlessly rotate them isn't clear. Perhaps the story is "As an IdP developer I want to able to publish several, seemlessly rotateably keys to that ____."

Also, at what stage of evaluation does an IdP consider this, that is, where would no having this story block IdP adoption? Need to know to pick proper label.

Finally, what's you current best thinking wrt priority? Nedd to know to pick label.

callahad commented 11 years ago

I took a shot at updating the title.

Generally speaking, the use case is an IdP that wants to change their signing keys, but without harming their currently provisioned users. Right now, IdPs can only publish one key at at time, so if they swap in a new key, it invalidates all previously signed certificates.

That invalidation may not be desirable if the IdP is simply upgrading to a longer key length.

I believe this is a blocker to getting out of Beta.

callahad commented 11 years ago

(Important, but not urgent)

r0bl0rd commented 11 years ago

Hrm. So, at what point of adoption does an IdP recognize this need? I'm tempted to make a new label IdP.5.Post-Deployment.

And you pick stars. It's your story. :)

callahad commented 11 years ago

Yep -- IdPs are only likely to need this at some point after deployment.

fmarier commented 11 years ago

One thing to note is that given that we don't have any key revocation mechanism, we rely on keys being short-lived. Therefore, it's important that key rotation be easy because security-conscious IdPs are likely to be swapping keys regularly (daily?).

chilts commented 11 years ago

Does this mean that an RP (which perhaps has stored a public key for an IdP) needs to recheck for newer/other keys if a verification fails and needs to re-verify?

Just curious, since we'd probably have to have a plan for this when we add local verification to the verifier libraries (obviously the hosted verifier would take care of this extra step for us).