dhwalker
commented
6 years ago Perhaps useful comment on key rollover...
| Subject: | RE: [External] Re: [TAC-InC] Fwd: a glimpse into our world |
|---|
Fri, 18 May 2018 21:52:28 +0000 Eric Goodman Eric.Goodman@ucop.edu tac@incommon.org tac@incommon.org tac@incommon.org
That's more complicated than what I meant. I mean just do standard key rollover, the way we tell clients to do it, but schedule it to happen (and update metadata) automatically every X days.
https://spaces.internet2.edu/display/InCFederation/Certificate+Migration says to wait 1-14 days after publication of the new cert to actually roll the certificate in your Shib config, so pick a duration between 1 and 14 days, and roll the certs rollover on that frequency.
The suggestion of doing it daily was to match Judith's suggested "it works today and it works tomorrow" use case. how long a tester needs to wait to run a second test to validate their software config for consuming metadata properly. The value of doing it less frequently is that it gives a longer "stable" time to support testers that can't do rollover or automatic metadata processing, but can support other functions.
--- Eric
-----Original Message----- From: tac-request@incommon.org tac-request@incommon.org On Behalf Of Nick Roy Sent: Thursday, May 17, 2018 10:42 AM To: tac@incommon.org Subject: Re: [External] Re: [TAC-InC] Fwd: a glimpse into our world
Never mind re: separate validUntil on each entity descriptor, even with per entity metadata that would not work to have duplicate entityDescriptors using different validity dates. I don't know what I was thinking. But the expiration date in certs is still not something we want to use for testing, other than to test that software is ignoring it.
Nick
On 5/17/18 11:39 AM, Nick Roy wrote:
So you'd have separate validUntil for each entityDescriptor? Good SAML software ignores the validity window and other miscellaneous non-key material in certs in metadata, so setting expiration dates on certs actually tests for successful implementation of an anti-pattern that we do not want software to use.
Nick
On 5/17/18 11:35 AM, Eric Goodman wrote:
Well, I actually meant roll over the keys every day. So every day's metadata would have today's and tomorrow's key in there with a "tomorrow" expiration time, then you would actually rollover the test system's key on the next day (and add a new "tomorrow" key), ad infinitum.
Whether the rollover timeframe is one day (today/tomorrow) or something else (this week/next week) is probably negotiable.
--- Eric
-----Original Message----- From: tac-request@incommon.org tac-request@incommon.org On Behalf Of Nick Roy Sent: Thursday, May 17, 2018 8:57 AM To: tac@incommon.org Subject: Re: [External] Re: [TAC-InC] Fwd: a glimpse into our world
That means we have to prevent them from testing the day they publish metadata. There's no way to do that, but I guess the perfect is the enemy of the good enough.
On 5/16/18 4:11 PM, Eric Goodman wrote:
Change the test system's keys every day?
--- Eric
-----Original Message----- From: tac-request@incommon.org tac-request@incommon.org On Behalf Of Nick Roy Sent: Wednesday, May 16, 2018 3:05 PM To: tac@incommon.org Subject: Re: [External] Re: [TAC-InC] Fwd: a glimpse into our world
I'll add that too. So what if this happens, though?
Someone sets up their test IdP, adds its metadata to the test federation, downloads the metadata that day (with that day's keys), manually configures their IdP with that metadata, and it passes.
They never come back $tomorrow or $theDayAfterThat and try to test again. "It worked!"
I hate the idea of implementing things that don't fix the problem I'm trying to solve in a bullet-proof way, because leaving a crack open for people to pass tests with less than compliant software gives them reason to file a support ticket when their crap breaks later.
I guess I should not be designing for people to be clever, which is why I like Judith's suggestion of dropping requests from browsers on the floor. We just have to never tell anyone about wget or curl.
Nick
On 5/16/18 3:37 PM, Cantor, Scott wrote:
Having the test IDP's certs change every day, and the test IDP and SPs rotate through endpoints would be intriguing.
Pretty much what you have to do.
But I know how much work it takes to do real interop harnesses and that's why I never meant to sign anybody up for that job.
Thu, 17 May 2018 10:37:01 -0700 Nick Roy nroy@internet2.edu David Walker dwalker@internet2.edu, Dean Woodbeck woodbeck@internet2.edu, Ann West awest@internet2.edu, Tom Barton tbarton@uchicago.edu, John Krienke jcwk@internet2.edu, Angi Sizemore avs@internet2.edu, Emily Eisbruch emily@internet2.edu
I've reviewed all of this and left comments at the bottom of each page. Let me know if I was incoherent :-)
There is one issue (the deployment checklist for IdPs) that I did not have time to look at. There is another page somewhere called 'new IdPs in metadata' that you should look at and see if you think these things can be deduped. New IdPs in metadata is a good/up-to-date document but doesn't necessarily cover things exhaustively.
Nick
On 5/10/18 10:02 AM, David Walker wrote: