Similarly, if the browser is not yet V2-capable, it needs the IdP's certificate (generated in Step 1) to be V1-format. It would most likely signal this by handing a V1-format pubkey B to the provisioning frame, and the IdP's backend code would stick to using V1-format certificates. (this is not actually sufficient for the general case, since the pubkey format can evolve independently from the certificate format).
Backing all the way up to the IdP's /.well-known/browserid advertisement, it might be useful for the browser and/or RPs to fetch different URLs from the IdP depending upon what versions they are capable of handling, or using some <tt>Accept:</tt> header negotiation to ask for different versions.Some changes won't require this (e.g. if clients will ignore any keys that they can't parse, then the IdP could publish both new- and old- format keys, and know that old clients will safely ignore the new ones), but others (like publishing multiple keys at all, rather than a single key) may need to be hidden from older clients altogether.