<div dir="ltr"><div dir="ltr">On Tue, Dec 15, 2020 at 10:24 PM Kurt Roeckx <<a href="mailto:kurt@roeckx.be">kurt@roeckx.be</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">If an applications wants to switch from one to the other<br>
algorithm, it should be as easy as possible. But the application<br>
might need to change, and might need to be aware which parameters<br>
are needed.</blockquote><div><br></div><div>A provider may not need any of those parameters - it might just need (for example) a label or key name.</div><div>That could be entirely sufficient and valid for an HSM usage scenario and setting up a key in that manner should be permitted.</div><div>Then you don't have any of the sort of parameters you are talking about and it remains perfectly valid - for that provider.</div><div>For other providers the list may be different.</div><div><br></div><div>This is one of the areas where there is a conceptual difference - it is a collection of things a provider needs to do its work - it isn't necessarily a complete standalone portable definition of a cryptographic object with all elements available and provided by the application.</div><div><br></div><div>Part of the point of this is you should be able to use different algorithms without the application having to change - that is part of the point of the sort of APIs we have - so that applications can work with whatever the user of the application wants to work with and you don't have to always go and add extra code into every application if something new comes along that we want to support.</div><div><br></div><div>Tim.</div><div> </div></div></div>