[Openid-specs-ab] Issue #1161: Key rotation should require a delay between publishing a key and starting to use it? (openid/connect)
bcampbell at pingidentity.com
Mon Mar 23 23:06:43 UTC 2020
In the interest of full disclosure, as the naive fool who originally wrote
those potentially problematic words about key rotation*, I can sometimes
get a little defense to criticism of them. But do keep in mind that
Connect Core is a final published specification and errata changes
can't/shouldn't break existing deployments or functionality. Also, as far
as I know, this stuff has been working okay for many years.
For normal behaviour the "signer can begin using a new key at its
discretion and signals the change to the verifier using the kid value"
works okay. But yes there is an opportunity for abuse by a malicious actor
sending lots of unknown kid values. The verifying party not refetching the
jwks_uri content more than once per some smallish time period, as Filip
described, is a reasonable means of guarding against something like that.
But a legitimate key roll to a newly published key during an 'attack' like
that with those protections in place might result in some service
disruption with erroneous invalid signatures until the new key at the
jwks_uri is successfully retrieved. If the signer also waits a bit after
publishing the new key before using it, that service disruption would
presumably be avoided because (as long as the throttling period and the
wait period matched up okay) the verifying party would have gotten the new
key at some point previously.
I think that mandating that stuff is probably too far for an errata 6 or 7
years later. But maybe some text with suggestions along those lines and
descriptions of why would be useful and reasonable for an errata?
On Mon, Mar 23, 2020 at 5:29 AM Torsten Lodderstedt via Openid-specs-ab <
openid-specs-ab at lists.openid.net> wrote:
> Thanks for the explanation.
> > On 23. Mar 2020, at 09:54, Filip Skokan <panva.ip at gmail.com> wrote:
> > So the WG questions
> > • should we do something about that language to suggest that
> signature recipients may omit fetching external jwks_uri resources if they
> already did so recently?
> Sounds reasonable to me. Is it feasible? I’m asking since I assume this
> requires a particular cashing strategy, which aligns with the test suite’s
> > • should we extend the attestation statement to allow for other
> rotation tests to be attested to allow implementers to have mechanisms that
> protect their infrastructure.
> Openid-specs-ab mailing list
> Openid-specs-ab at lists.openid.net
<https://www.pingidentity.com>[image: Ping Identity]
bcampbell at pingidentity.com
w: +1 720.317.2061
c: +1 303.918.9415
Connect with us: [image: Glassdoor logo]
LinkedIn logo] <https://www.linkedin.com/company/21870> [image: twitter
logo] <https://twitter.com/pingidentity> [image: facebook logo]
<https://www.facebook.com/pingidentitypage> [image: youtube logo]
<https://www.youtube.com/user/PingIdentityTV> [image: Blog logo]
*If you’re not a current customer, click here
a more relevant offer.*
_CONFIDENTIALITY NOTICE: This email may contain confidential and privileged
material for the sole use of the intended recipient(s). Any review, use,
distribution or disclosure by others is strictly prohibited. If you have
received this communication in error, please notify the sender immediately
by e-mail and delete the message and any file attachments from your
computer. Thank you._
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Openid-specs-ab