Need for certificate profile identifier in Sign Requests

[Razumain]

There is a need for a list of certificate profile indicators to guide the Signing service on what information that needs to be in the signing certificate.

An example is if the signing service is used to sign a TrustedList. The specifications for EU trusted lists requires certain information such as a special extended key usage (EKU). Similar cases exists where the signing certificate need to be adapted to certain format requirements beyond what current protocol can handle.

The proposed solution is to add a sequence of profile identifiers where each identifier may have a set of key, value pair properties. We must assume that each profile identifier need to specify certain parameters specifying certain values or options.

[GunnarKlintberg]

I don’t disagree on the enhancement, but I don’t for the moment with only this enhancement alone to improve the real use case by the current implementation we have at governments in Sweden.
From a prioritizing point of view, I see other enhancement more important than this.
We do not have requests by our end clients to implement this and the described use case seems to be a real special case that does not hit the normal end client’s implementation.

In combination with other enhancement that is not today listed I defiantly see use cases for this.
Example, how to solve organization signature that the Standard is lacking on.
In that use case this can be one of the needed puzzle pieces.
But from a generic PKI point of view, we do not like to have different certificate profiles from the same CA if it not really needed (in some cases it is necessary).
Historically we have run over too many implementations when the Subscriber that verify the Certificates does not do this correctly.

[martin-lindstrom]

Moving this to the next version.

[martin-lindstrom]

Will be done in version 2 of the signature specs.