Yes, of course, there are some parts that must be dealt with by the site, but the article states a list of things that are outside the reach of what a website should have access to:
> They need information on the key generation process.
While a useful documentation of sort can be provided by the website, I don't think having one visually different procedure per website will help the user
> They should allow the user to export the key and to re-import it (just spawning two file dialogs should suffice - of course the key must not be transmitted to the site in the process).
We're talking about things that go outside the browser here. I think we all agree that giving access to the exterior to a website is easily dangerous
> They need a way to list the keys installed in a browser.
... only for the related website; I don't see why a website should be able to list other keys. Of course we could filter that with the browser... or just do it all from the browser anyway. Also, no website can do this for username/passwords
> They need to be able to add and remove keys (on the user's request).
Again, limited to the website, but here again there is no equivalent for passwords
With regards to exporting and importing: The idea is definitely not any more dangerous than the already existant functionality for `<input type="file">`.
And yes, of course in real life such features would be designed in such a way that the site can only access the entries relevant to itself. I do agree that the article was a bit loose in its language here. But why you would ever think that a standard would give more flexibility to certificates than it does cookies?
> But why you would ever think that a standard would give more flexibility to certificates than it does cookies?
Cookies management, as seen from the user, is straightforward: there's a way to delete them all for a given site, and recently, thanks to the EU there's a banner telling him that there are cookies. The user can't do much more than that. Moreover, cookies are a crutch for the server to handle state.
Certificate management, on the other hand, is going to be a whole another animal, not only because there are much more things to handle, but also because we start dealing with crypto; moreover, we're talking about client certificates here, so IMO it should absolutely remain under the user control. I like to think that the website is a potential enemy (whether it wants to or not), and the browser is an ally so the less a website controls, the better.
> They need information on the key generation process.
While a useful documentation of sort can be provided by the website, I don't think having one visually different procedure per website will help the user
> They should allow the user to export the key and to re-import it (just spawning two file dialogs should suffice - of course the key must not be transmitted to the site in the process).
We're talking about things that go outside the browser here. I think we all agree that giving access to the exterior to a website is easily dangerous
> They need a way to list the keys installed in a browser.
... only for the related website; I don't see why a website should be able to list other keys. Of course we could filter that with the browser... or just do it all from the browser anyway. Also, no website can do this for username/passwords
> They need to be able to add and remove keys (on the user's request).
Again, limited to the website, but here again there is no equivalent for passwords