...

As with so many questions that arise in the CVD process, there is no single right answer. So rather than trying to solve an underspecified set of inequalities, let's have a look at some of the factors that tend to play into timing choices. This will give us an opportunity to see where some of the variability comes from.

Conference Schedules and Disclosure Timing

...

Avoiding surprise was one of the principles in Section 2. To that end, explicitly declared policies (from both researchers and vendors) are a good thing. Expected disclosure timing is an important question to ask whenever a report is received. Sometimes the reporter or coordinator acting on the reporter's behalf has a standing policy of X days with no exceptions. Other reporters may be more flexible. If in doubt, ask.

All Disclosure Agreements Are Contingent 

When vendors, reporters, and/or coordinators negotiate and agree to a release timeline for a vulnerability, they may behave as if they've reached some state of détente with the world. But that's an illusion. True, they may have reached an agreement with each other, but it ignores another relevant role in the disclosure process: the adversary. Adversaries do not care whether the vendor plans to release the patch in a month, whether they need more time to test it prior to release, whether the reporter wants to break the news at a conference event, whether the reporter hopes to get paid for the work, or any other reason that reporters and vendors may have for agreeing to the terms they came to. Furthermore, because the vulnerability's existence is an observable fact in the world, anyone else who happens to notice it might also choose to disclose that knowledge on their own terms without being party to any existing embargo agreements. Therefore it's important for vendors, reporters, and coordinators alike to recognize that all disclosure embargo agreements are necessarily contingent on circumstances beyond the control of the parties involved; and that those circumstances are not simply random events but may be controlled by actors who are indifferent to their concerns. 

Diverting from the Plan

Je n'ai jamais eu un plan d'opérations.

...

When considering what information to release about a vulnerability, our advice is "Don't tease." Our experience shows that the mere knowledge of a vulnerability's existence in a feature of some product is sufficient for a skillful person to discover it for themselves. Rumor of a vulnerability draws attention from knowledgeable people with vulnerability finding skills—and there's no guarantee that all those people will have users' best interests in mind. Thus, teasing the existence of a vulnerability in a product can sometimes provide an adversarial advantage that increases risk to end users.

References

1. Black Hat, "Black Hat," [Online]. Available: https://www.blackhat.com/. [Accessed 23 May 2017].
2. DEF CON, "DEF CON," [Online]. Available: https://www.defcon.org/. [Accessed 23 May 2017].
3. USENIX, "USENIX Security Conferences," [Online]. Available: https://www.usenix.org/conferences/byname/108. [Accessed 23 May 2017].
4. RSA, "RSA Conference," [Online]. Available: https://www.rsaconference.com/. [Accessed 23 May 2017].
5. CanSecWest, "CanSecWest Vancouver 2018," [Online]. Available: https://cansecwest.com/. [Accessed 23 May 2017].