[Cscwg-public] Signing Service Model

Tomas Gustavsson tomas.gustavsson at primekey.com
Mon Aug 24 22:37:58 MST 2020

I'm not sure I understand the models, so please excuse my elaboration
below to understand/map.

On 2020-08-24 21:11, Bruce Morton via Cscwg-public wrote:
> I was working on separating the warranties of the CA and the Signing
> Service. In review it is starting to get confusing, as such it would be
> great to discuss the Signing Service model. I believe that it can be
> based in 2 ways:
>  1. Signing Authority – In this case the SA has its own certificates
>     with keys guaranteed to be managed on an HSM. The old requirement
>     allowed these certificates to be valid up to 135 months. The SA
>     could then verify entities that would like their code signed. The SA
>     could then sign the code using the SA’s keys. The code signature
>     could be valid for 135 months.

This sounds to me like an enterprise service. Internally withing a large
enterprise a code signing authority service is operated. Code is signed
published by the company, and internally there is authentication and
authorization of who can sign/publish code on behalf of the company.
This is a common setup in production, and should be attractive to both
enterprises and platforms.

>  2. Subscriber Key Hosting and Signing Service – In this case the
>     Subscriber must be verified and can then have their keys hosted on
>     an HSM by the CA or a third party. When the Subscriber wants to
>     sign, they have to authenticate and use the signing service which
>     will use their key. The certificate has a validity period of 39 months. 

The keys can be hosted by the signing service (not necessarily the same
organization as the CA), making it very similar to case 1, but the
Signing Authority uses the subscribers keys instead of the SAs own keys
to sign with.

I.e. similar to the distinction between an eSeal (organization keys) and
eSignature (individual key) in eIDAS. eSeal and eSignature can very well
be offered by the same signing service/signing authority.

For code signing is it always an organization in the certificate? Then
it can still be:
- organization's private key and cert (i.e. eSeal)
- individual certificate and key, within an organization (i.e. eSignature)

> Please advise if there are other models.
> I don’t believe that anyone is using the item 1 model. We have also
> reduced the validity period to 39 months.
> The item 2 model appears to allow the keys to be hosted by the CA or a
> third party. Could this be a cloud provider. If cloud provider is
> included, then I don’t think that we can push out the Signing Service
> requirements to the cloud providers.

If the keys are held in an Azure/AWS/GCP KMS, would they be considered
hosted by the cloud provider? The SA controls the activation of the
keys, but naturally it's hard to know if the cloud provider has access
to the keys in the background as no HW/DC audit can be done.

In eIDAS it comes down to who controls the activation of the key, i.e.
"sole control". Perhaps that's a useful concept, i.e. one is how the key
is protected (FIPS 140-2 etc) and one is who controls the use of the key.

> I think we should define the model(s) that we want to support, then
> update the BRs to support these model(s).
> This should work with the key protection which Ian will be proposing for
> section 16.3.
> Bruce.
> _______________________________________________
> Cscwg-public mailing list
> Cscwg-public at cabforum.org
> https://lists.cabforum.org/mailman/listinfo/cscwg-public

More information about the Cscwg-public mailing list