Added proposal to improve support for packages signed with a Trusted Signing certificate.

[dlemstra]

edit by @joelverhagen:@JonDouglas(feedback/upvote section)

This is a proposal to address NuGet/NuGetGallery#10027.

Rendered Markdown

Please 👍 or 👎 this comment to help us with the direction of this feature & leave as much feedback/questions/concerns as you'd like on this issue itself and we will get back to you shortly.

Thank You 🎉

[joelverhagen]

To be clear, we will allow an EKU to be linked to multiple users/orgs right? This is possible today since the same .cer file can be uploaded by multiple users and this means the same fingerprint is possible.

I think it is okay to allow this because a) both users/orgs would need access to signing permission for this to matter and b) there may be legitimate scenarios for this, such as one signing identity (TS account) but multiple NuGet.org profiles (one user with multiple orgs).

[ianjmcm]

The unique EKU for the validated identity in Trusted Signing is tied to the Subscription, so other accounts and certificate profiles will be able to use that unique EKU. This allows orgs to organize their account resources with their business/development units as they see fit.

Please consider that the signing certs will not be signed by the root directly, Microsoft Identity Verification Root Certificate Authority 2020, but its issuer will be chained to the Microsoft ID Verified Code Signing PCA 2021 that is signed by the root. Only code signing certs under this CA in the hierarchy should be accepted for NuGet author signing from Trusted Signing.

[dlemstra]

I have updated the PR to make it more clear that it should be the root CA.

[ianjmcm]

Only a couple of minor clarifications on the signing cert's signer not being directly the root CA, and clarification on subjectDN value changes may not have an impact on the EKU.

[ianjmcm]

The unique EKU for the validated identity in Trusted Signing is tied to the Subscription, so other accounts and certificate profiles will be able to use that unique EKU. This allows orgs to organize their account resources with their business/development units as they see fit.

Please consider that the signing certs will not be signed by the root directly, Microsoft Identity Verification Root Certificate Authority 2020, but its issuer will be chained to the Microsoft ID Verified Code Signing PCA 2021 that is signed by the root. Only code signing certs under this CA in the hierarchy should be accepted for NuGet author signing from Trusted Signing.

[joelverhagen]

I think we can implement and deploy each step individually. I am concerned that Step 1 has a part this is not self-service (the deletion, potentially increasing on-call/support load) and Step 2 requires the user to extract the .cer themselves somehow. This is fine, but we can limit exposure but putting the new behavior behind a flight -- this is a feature flag but has a username filter. This means we can add specific people (perhaps MVPs who ask) to the feature until we get to step 3 and then we can open it up to everyone.

What do you think?

[dlemstra]

Sounds like a good plan. Not sure if we should limit this to just MVP's though. There are probably also other people that would want to try out this feature.

[joelverhagen]

Yes, I take MVPs as an example because it's easy to have tight, proactive communication with them. But certainly, we can definitely open it up to anyone that asks. Maybe a small announcement with "contact us if you want to try it", or perhaps a set of people Ian knows. Initial adoption efforts can be TBD. We can add any username to the flight system with ease.

[joelverhagen]

This looks great, @dlemstra! I will work on getting at least one more team member on board with this design, then we can merge it and talk about implementation.

[JonDouglas]

LGTM

[clairernovotny]

The signing tool name isn't dotnet sign, it's Sign CLI. Would probably be useful to have it as a link to the repo.

[dlemstra]

I have corrected the name and included a link.

[clairernovotny]

It's three days now but it could be shorter--do we want to say a specific number or say "short".

[dlemstra]

I have updated it to "a short time" now.

[dtivel]

I made a related comment elsewhere in this PR. This looks to me like a screenshot from the Trusted Signing website, not a mockup for NuGet.org. I'm not sure though, because I don't have a Trusted Signing account to verify.

As we look to this screenshot as prior art, I take issue with the label "Enhanced key usage." "Enhanced key usage" is not an accurate description of its right-hand value. The value is the Trusted Signing subscriber identity. (@ianjmcm, correct me if mistaken.) Certificates can have many EKU's, and the Trusted Signing subscriber identity is just one of them.

It is true that the subscriber identity is stored in an EKU, but I think of this like a library card or driver's license. There's a barcode on those which is unique to you. You wouldn't label that value "Barcode", you'd label it "Library user ID" or "Driver ID", respectively.

I think "Trusted Signing subscriber ID" would be a more accurate and useful label than some other terms in this proposal ("Trusted Signing EKU's", "Public Trust identity EKU", "Public trust identity", ...). This proposal should use consistent terminology throughout. That the value is stored in an EKU is an implementation detail.

[dlemstra]

Maybe both NuGet and Azure should use the same name for this? Would it be possible to change this in the interface of Azure @ianjmcm?

[dtivel]

@dlemstra, @ianjmcm's feedback here was that the signing certificate's issuer should not be the root CA. Certainly, the signing certificate should chain to this root, but that's not the same thing. The signing certificate's issuer should chain to the "Microsoft ID Verified Code Signing PCA 2021" intermediate CA (or policy CA), like I've illustrated below.

I don't know if there is a hard restriction on chain length. In the abstract, there could be not just 1 but more than one intermediate CA's between the PCA and the subscriber certificate. @ianjmcm's point was that we can expect that the subscriber certificate will eventually chain up to "Microsoft ID Verified Code Signing PCA 2021". I think it's safest to not hard-code expectations in our code as to the chain length (i.e.: whether there is 1 or more CA's between the PCA and the end certificate).

graph TD
    A["Microsoft Identity Verification Root Certificate Authority 2020"]
    click A "https://crt.sh/?q=5367f20c7ade0e2bca790915056d086b720c33c1fa2a2661acf787e3292e1270" "Root CA"
    A --> B["Microsoft ID Verified Code Signing PCA 2021"]
    click B "https://crt.sh/?q=3d29798cc5d3f0644a7e0dc9cb1cade523ea5ec83b335109b605bfeaa7d5f5c1" "Intermediate CA"
    B --> C["issuing CA (e.g.:  Microsoft ID Verified CS AOC CA 02"]
    C --> D["subscriber certificate"]

Loading

[dtivel]

This is nonsensical. There isn't standard way to countersign (or timestamp) a certificate.

I think what you meant is that the package signature has a valid timestamp.

[dtivel]

Actually, I think you should avoid restating unchanged requirements like this. It creates confusion around what the authoritative, complete requirements are.

This public document already states this requirement.

You can remove any requirement here that is already in that list.

[dlemstra]

The reason this requirement was included is to make sure that the EKU is one that was added by the Trusted Signing service in Azure.

[dtivel]

• The signing certificate has a valid counter-signature (timestamp).

This requirement no relevance to ensuring "that the EKU is one that was added by the Trusted Signing service in Azure."

The next line expresses the requirement you describe.

You should remove this requirement.

[dtivel]

I think we should use the same label/term everywhere, whether that is "Trusted Signing subscriber ID", "Public trust identity", or something else. Find and replace.

[dtivel]

How do we (NuGet.org) get a Trusted Signing certificate for testing this feature?

[joelverhagen]

I can help with manual testing since I am personally onboarded. I am not sure if we need regular E2E testing (needing a new Trusted Signing signature per test run). Are you referring to manual or automated testing?

[dtivel]

I can help with manual testing since I am personally onboarded.

Suppose you go on leave for a while.

Are you referring to manual or automated testing?

Neither specifically at this time, though automated testing is preferrable. I'm thinking about E2E testability during development, release, and post-release.

[dtivel]

Isn't an alternative solution that we integrate with Trusted Signing and retrieve the subscriber ID directly?

[dlemstra]

That would still require some kind of integration with the Azure API that would require authorization setup. That feels more complicated?

[dtivel]

I'm not suggesting this as a replacement for the current proposal.

The purpose of this section is to present alternatives and rationale "[w]hy this is the best design compared to other designs." Complexity and cost are solid motivators.

When someone looks back and wonders if we considered option ___, ideally, it would have been captured in this section.

[clairernovotny]

I can also help with testing as I am also onboarded with Trusted Signing.

[dtivel]

I assume that this screenshot is from Trusted Signing website, but I don't know for sure. It does not look like a mockup for NuGet.org. I think it's important to call out that this is a screenshot from the Trusted Signing website not exactly what you're proposing for NuGet.org.

[dlemstra]

This is a mermaid diagram? Are you referring to another image?

[zooba]

I'd love to see this! Copying the EKU manually (rather than uploading .cer) is fine by me, though I'd also be happy with uploading an entire package for certificates to be extracted, or using an existing package (uploaded prior to enabling checks). But it's a one-time operation as far as I'm concerned, so as long as I don't need to install any extra tools or sign up at new websites just to do it, it can be a few manual steps.