1562770 - [meta] Support Delegated Credentials for TLS Servers

Status: NEW

(Core :: Security: PSM, task, P3)

Description

[J.C. Jones [:jcj] (he/him)]

Delegated Credentials permit holders of specially-enrolled certificates to use those certs as a kind of sub-sub-CA to construct sub-certificates whose authority is delegated by the actual end-entity cert. These delegated certificates are particularly useful when needing to act on behalf of the end-entity in lower-trust environments, like those sometimes found in CDN edge networks.

NSS 3.45 supports delegated credentials draft 3 via Bug 1540403.

To enable this on the Firefox-side, PSM has to call SSL_OptionSet(EnableDelegatedCredentials) and specially handle EE certs with the OID, pulling out sslDelegatedCredential *peerDelegCred from TLSExtensionData to verify it, and one way or another display it to the Firefox user.

This meta bug covers the whole implementation of the Delegated Credentials specification.

Comment 1

[Martin Thomson [:mt:]]

specially handle EE certs with the OID, pulling out sslDelegatedCredential *peerDelegCred from TLSExtensionData to verify it, and one way or another display it to the Firefox user.

The design of delegated credentials is such that special handling is unnecessary. NSS performs all of the validation of the delegated credential. NSS checks for the presence of the OID when accepting a delegated credential. No additional action is required from PSM. PSM can't access TLSExtensionData.

PSM just has to make the decision of whether to enable the feature.

The question of whether to expose the presence of delegated credentials in something like nsITransportSecurityInfo is not important, but worth asking. This would be for diagnostic purposes only.

Comment 2

[Dana Keeler (she/her) (use needinfo) [:keeler] (on leave)]

Are there any policy knobs PSM can use to tune what signatures/keys/parameters are acceptable? (e.g. minimum key size?)

Comment 3

[Martin Thomson [:mt:]]

Good question. This runs off the standard SSL_SignatureSchemePrefSet configuration in terms of what can be enabled. But that is not sufficiently granular to allow setting of policy along the lines of what is done in PSM.

I think that the only problem is with RSA modulus length. Right now, the authKeyBits field in SSLChannelInfo is still set to the length of the key in the certificate. That's a problem. I think that what we want to do is fix that. Then PSM can apply policy based on what is in the certificate chain (including the end-entity) and SSLChannelInfo. From what I can see, mozpkix does the key strength checks, so we only need to concern ourselves with an additional check, once authKeyBits is properly set.

I've opened Bug 1563078 for NSS and have a patch ready.

Comment 4

[James E. A. (any) [:codegeek98]]

When this is added, could you include some kind of exposure of it in webRequest.getSecurityInfo?

When using Delegated Credentials, the delegated credential becomes the effective leaf key, and the nominal "leaf" certificate actually becomes something like an intermediate CA.

I understand that the X.509 leaf certificate might not be considered to be a "CA" even when it's issued delegation certificates, and will probably continue being displayed as the final node for user-facing interfaces, but I'm trying to build a certificate pinning extension to warn users and fail-safe if the leaf SPKI ever changes; if delegated credentials are hidden from extensions because they're not "considered" a new leaf on the TLS trust chain then building such an extension becomes impossible.