[Spec]: Add support to allow package authors to sign packages

[mishra14]

Goal: Tracking the spec for #5904

[mishra14]

The spec is currently in review and it is available here.

Update: I have updated the link to the public spec.

[forki]

404

[mishra14]

@forki please check the link now. You should be able to access it.

[maartenba]

Is a timestamper provided or is this something the package author must provide?

[mishra14]

@maartenba Current spec requires the user to provide a timestamper service url.

[jariq]

I am not sure I understand what is -SigningAlgorithm option good for. It is described as

Signing algorithm to be used. Allowed values are RSA and ECDSA. Defaults to RSA.

but in my experience the signing algorithm is chosen by the type of public key present in the certificate. ECDSA cannot be used with certificate issued to RSA key pair and vice versa. Are you sure this option is needed?

[jariq]

If you plan to provide built-in multiplatform support for HSMs and other hardware based key stores then IMO there is currently only one viable option and that is PKCS#11 ANSI C API. It's been here since 1995 when it was created by RSA Laboratories and currently it is being maintained by OASIS PKCS11 Technical Committee that released latest version of specification in 2015. In my experience, most (if not all) of the commercially available HSMs and smartcards come with an unmanaged library implementing PKCS#11 interface. There is even an pure software implementation available called SoftHSM which is invaluable for testing.

When it comes to .NET support there is an open source PKCS#11 wrapper library called Pkcs11Interop (I am the shameless self-promoting author) that is netstandard1.3 compatible and works well on all major desktop platforms (Windows, Linux and OSX). Pkcs11Interop comes with built-in support for PKCS#11 URIs (defined in RFC 7512) which fit nicely as a value of proposed -CertificatePath parameter. Let me provide an example:

1. After reading a proposal I guess that with CryptoAPI certificate source one would use following command to sign a package:
   nuget.exe sign package.nupkg -CertificatePath "cert:\CurrentUser\My\d5de31ea974f5ea8581d633eeffa8f3ea0d479bb"
   This URI tells NuGet to use certificate with thumbprint d5de31ea974f5ea8581d633eeffa8f3ea0d479bb located in CurrentUser\My certificate store. Please correct me if I am misinterpreting the proposed URI format.

2. With PKCS#11 certificate source one would use following command to sign a package:
   nuget.exe sign package.nupkg -CertificatePath "pkcs11:token=OSSCodeSigning;type=cert;object=jaroslav.imrich@gmail.com?module-path=cardos11_64.dll"
   This PCKS#11 URI tells NuGet/Pkcs11Interop to load cardos11_64.dll unmanaged library, find token with OSSCodeSigning label and certificate object with jaroslav.imrich@gmail.com label.

It would be really nice to have built-in PKCS#11 support in NuGet but I understand it might not be entirely possible. For example it might not be allowed to introduce additional dependencies to NuGet code base or it might not be allowed to load unmanaged libraries into nuget process. So as an alternative to built-in HSM support you may also consider making signing API pluggable so I would be able to write and maintain PKCS#11 plugin and other authors would be able to do the same for other key stores (I can imagine @onovotny and @vcsjones would want to write Azure KeyVault plugin).

[clairernovotny]

@jariq To be clear, we'd most likely reappropriate the signing digest code and wrap it into a different utility. Key Vault doesn't have a PKCS#11 windows api yet (afaik), and we'd want something that doesn't require any installation on the machine. That's one nice thing of our utilities, is that it's pure xcopy.

[mishra14]

@jariq -

I am not sure I understand what is -SigningAlgorithm option good for.

Thanks for the feedback. I will investigate this a bit to make sure that I have the right params outlined.

After reading a proposal I guess that with CryptoAPI certificate source one would use following command to sign a package:
nuget.exe sign package.nupkg -CertificatePath "cert:\CurrentUser\My\d5de31ea974f5ea8581d633eeffa8f3ea0d479bb"
This URI tells NuGet to use certificate with thumbprint d5de31ea974f5ea8581d633eeffa8f3ea0d479bb located in CurrentUser\My certificate store. Please correct me if I am misinterpreting the proposed URI format.

That is correct.

If you plan to provide built-in multiplatform support for HSMs ....

Thanks for your detailed feedback on HSMs. I will look into this and the feasibility of your suggestion.

[vcsjones]

I am not sure I understand what is -SigningAlgorithm option good for.

Agree. That should (must) be dictated by the signing key being used. Regardless, much kudos for supporting ECC. This is often overlooked in code signing. I suppose the standard NIST curves would apply here. However, macOS doesn't readily support some of the curves Windows does (p521, brainpool). I don't know if you want to limit at signing time which curves you support for signing.

I would recommend getting rid of this. It doesn't do anything. You can't set this value to anything other than what the certificate is. This can be determined by the OID of the SPKI of the certificate.

HashingAlgorithm ... Defaults to SHA512.

SHA512 is overboard as a default, in my opinion. I understand the notion of "bigger numbers are better". Frankly I would just use SHA256 though would be perfectly fine with 384 as well if there is some concern around SHA256 weaknesses. Though I see no problem with defaulting with SHA512 except for the next item.

Timestamps

There is no option to specify the digest algorithm for the timestamp (the signtool equivalent is /td when used with the /tr option). Is it intended that this will be the same as HashingAlgorithm? If so, the SHA512 default algorithm makes even a little less sense, some timestamp services don't like SHA512 - 256 or 384 is fine for most).

I would recommend introducing a -TimestampHashAlgorithm option and pick a sane default.

Whats the best way to pass the certificate password to the sign command?

I honestly wouldn't bother too much with this. An encrypted password in a config file would need to be decryptable by the person running the tool, anyhow. If users are serious about the private key's protection they will use the certificate store and keep the key in a KSP, which could be a smart card, HSM, or the Microsoft Software Key Storage Provider.

I would have a -Password option and use it if it is specified. If it is not specified, try opening the PKCS12 file without a password. If it fails, prompt for a password and try again with the password from the prompt. If that fails, then you fail for real. You may want to introduce a -Quiet option to ensure build servers do not prompt and hang.

Do we need to add retry mechanism for the timestamper service?

I don't think so? I would however make sure there is a timeout. Perhaps configurable.

Other things...

It would be really nice if there was support for a signing "callback" mechanism. I don't know if this needs to exist in the CLI, but in the library it would be very help for 3rd parties to sign with whatever they want (selfishly I am thinking of Key Vault support). Windows recently introduced this for Authenticode with SignerSignEx3. The gist would be, instead of signing with a certificate, you have a callback that says "Hey, here's a digest. Go sign it and return it". signtool again supports this with /dlib or the other XML switches. It would still use a certificate for embedding in the signature and verifying the signature, by the private signing operation would be a callback.

It would also be nice if, perhaps later, but the more information the better, it was made clear what different exit codes mean. I assume some people will automate this signing process with a CICD tool, and being able to fail the build for certain exit codes would be nice.

[clairernovotny]

It would be really nice if there was support for a signing "callback" mechanism. I don't know if this needs to exist in the CLI, but in the library it would be very help for 3rd parties to sign with whatever they want (selfishly I am thinking of Key Vault support).

For that callback, it should be async. The signature should essentially be Task<(byte[], X509Certificate2)> SignCallback(byte[] digest, HashAlgorithm algorithm)

Idea being that the public certificate (and its chain) come in externally to the library. It should not assume X509Store at all.