808839 - Active Distrust based on Subject + Subject Public Key Info

Status: NEW

(NSS :: CA Certificates Code, task, P3)

Description

[Kathleen Wilson]

Actively Distrusting by Subject allows us to distrust all certs chaining to a particular root or intermediate certificate, even if there are intermediate certificates in that chain that we don't know about.

DigiNotar is an example. We found if we removed the DigiNotar root, that it was possible that the certs would still be trusted because the DigiNotar root was cross-signed by other roots in the NSS root module.

It is fairly common practice when a CA starts up a new root certificate to set up their infrastructure, get their audit, then go to one of the major CAs and pay to get a cross-signed certificate good for 3-5 years. This allows the new CA to have their root certificate trusted in browsers while they are working to get their certificate added directly to each browser.  

Currently Active Distrust is done with a combination of Subject and Issuer. But if the certificate to be distrusted is cross-signed by another certificate in NSS, then the subject/issuer for that certificate chain also has to be found and distrusted. 

Actively Distrusting based on Subject will also handle the situations where cross-signing is involved.

Comment 1

[Kathleen Wilson]

Correction:
"Currently Active Distrust is done with a combination of Subject and Issuer. But if the certificate to be distrusted is cross-signed by another certificate in NSS, then the subject/issuer for that certificate chain also has to be found and distrusted. "

Should have been:
"Currently Active Distrust is done with a combination of Serial Number and Issuer. But if the certificate to be distrusted is cross-signed by another certificate in NSS, then the Serial Number and Issuer for that certificate chain also has to be found and distrusted."

Comment 2

[Ryan Sleevi]

Kathleen,

Just to make sure I'm clear on the technical side, you're talking about active distrust based on the Subject DN and the Subject Public Key Info, correct? Preferably with the Subject DN compared based on normalized form (eg: whitespace folded, case insensitive for the common attributes), rather than on the raw (binary) form?

Subject itself isn't enough to uniquely identify an (issuing) certificate, but the combination of Subject plus SPKI *should* cover all trees that may be used to validate leaf certs within that PKI hierarchy.

Comment 3

[Robert Relyea]

> Peferably with the Subject DN compared based on normalized form (eg: whitespace folded,
> case insensitive for the common attributes), rather than on the raw (binary) form?

The trick with the normalized reference is looking it up. Ideally I would go with normalized, but for historical reason NSS doesn't use normalized in chain construction, so it's really not as critical (if the cross cert doesn't have the same binary subject, then NSS won't chain to it, so it doesn't matter if we catch it in the non-matching intermediate or not in the net.

> Subject itself isn't enough to uniquely identify an (issuing) certificate, but the combination
> of Subject plus SPKI *should* cover all trees that may be used to validate leaf certs within
> that PKI hierarchy.

Your are right, we probably need both. A Subject plus and optional SPKI. We include the SPKI depending on if we are taking out a specific compromised CA server, or a fully compromised CA.

bob

Comment 4

[Kathleen Wilson]

Kai, Can we get this onto your list of things to do?

Comment 5

[Kai Engert (:KaiE:)]

It seems there hasn't yet been an agreement on how this would be done technically, Kathleen hasn't given feedback to Ryan's question.

Kathleen suggested the simple approach based on subject names, only.

IIUC Ryan asked to require additional details for distrust, such as a match with a specific "Subject Public Key Info", which seems to mean, to a specific public key.

But what if a CA uses multiple keys? When searching for a trusted issuer cert, will software commonly accept any trust issuer with the matching name, regardless of the public key used by the issuer cert? If yes, then I'd conclude that Kathleen doesn't want to limit things to a specific key - because not all keys might be known. I understand the request to easily enable broad blocking based on a name, without knowing all details of all certificates that are desired to be blocked.

Comment 6

[Ryan Sleevi]

No, no software will trust any issuer with the same matching name. That's because certificates have signatures, and in order to verify the signature, you need a public key. As RFC5280 documents, a CA is identified by its (Subject, SPKI) tuple. There may be multiple certificates with that same tuple, but a trust anchor/logical CA is always identified by that tuple, and all certificates can only be verified by that tuple.

Distrusting based on Subject is fundamentally unsafe. Consider Evil CA who wishes to disrupt Good CA, they merely create their own public/private key tuple, and then get that added to OneCRL. If you do not limit to key, then Evil CA can negatively impact Good CA - even though it's impossible (because the signatures don't verify) for Evil CA to be considered for "Good CA"

I do not believe SPKI could ever be optional - it's fundamentally unsafe to do so, but also unnecessary - if the issuer doesn't know the key, the issuer should be removed (and their key is known).

Levels of revocation:
- By key (for any name)
  - Only affects the keyholder
  - Safe as long as you require proof of possession of the key (so that someone else can't nuke Good CA)
- By Subject & Key
  - Only affects the keyholder
  - Safe as long as you require proof of possession of the key (so that someone else can't nuke Good CA)
- By Certificate
  - Only affects a subset of certificates
  - Does not address if there are other matching Certs (possibly by different issues)
  - Not generally recommended because of this
- By Issuer & Serial
  - Fundamentally same as "by cert"

Bob, would you agree with that taxonomy? This matches what Google, Apple, and Microsoft have done in this space.

Comment 7

[Robert Relyea]

It depends on what you are revoking. Certainly revoking a key. In the diginotar case we really were revoking a cert (the key wasn't compromised only the CA behind it).

Subject name will kill a whole CA (including any additional keys used by that CA). It may be desirable to do that. It wouldn't kill any reuse of those keys by the CA, but then neither does Subject & Key, which kills a the use of a key by a CA but allows the same CA to use other keys (rekey case).

Issuer/Serial was the general way of revoking certs until recently (OCSP and CRLs initially had no way to specify key). The existing method was just mirroring that.

On a separate note, while spki is useful, it's just a number and we are dependent on the CA to generate properly. Does RFC5280 specify how spki is generated from the public key (in which case it would be useful, but NSS would have to start generating the spki from the public key rather than reading it from the certificate).

Upshot. There appears to be utility in the Subject only kill case as well as the Subject SPKI (assuming we use SPKI to kill a key, not certs with the same SPKI extension like we do now). The latter would require a fair amount of surgery.

Comment 8

[Ryan Sleevi]

(In reply to Robert Relyea from comment #7)
> It depends on what you are revoking. Certainly revoking a key. In the
> diginotar case we really were revoking a cert (the key wasn't compromised
> only the CA behind it).

No, we killed by key, because there were multiple (later-discovered) cross-certificates, so we killed by key to ensure that regardless of the certificate used, it was killed.

> Subject name will kill a whole CA (including any additional keys used by
> that CA). It may be desirable to do that. It wouldn't kill any reuse of
> those keys by the CA, but then neither does Subject & Key, which kills a the
> use of a key by a CA but allows the same CA to use other keys (rekey case).

Why would this ever be desirable? It doesn't matter what additional keys are used - I don't believe there should ever be a reason to kill just by subject, because it burns an entire name from the Web PKI, and names can overlap (and aren't unique), and killing all keys with a name is unnecessary - you just need to kill all the keys you trust.

> On a separate note, while spki is useful, it's just a number and we are
> dependent on the CA to generate properly. Does RFC5280 specify how spki is
> generated from the public key (in which case it would be useful, but NSS
> would have to start generating the spki from the public key rather than
> reading it from the certificate).

I'm not sure I understand your point here. Are you suggesting that a given (Evil, revoked) CA may have
1) Cert 1
  - Uses SPKI (say, RSA) with absent params
2) Cert 2
  - Uses SPKI (RSA) with NULL params

And wanting to kill both certs simultaneously?

I agree, that's a normalization problem - but it's also an implementation problem that you accept both, when the RFCs (and thus the BRs) do state the canonical requirement.

> 
> Upshot. There appears to be utility in the Subject only kill case as well as
> the Subject SPKI (assuming we use SPKI to kill a key, not certs with the
> same SPKI extension like we do now). The latter would require a fair amount
> of surgery.

I believe that's a real downside - it's a scorched earth policy that doesn't align with RFC5280 or how the Web PKI goes. I'm also not sure why it would require a lot of surgery - when we lookup matching Subjects, we look for trust records for the associated key.

Comment 9

[Robert Relyea]

> I'm not sure I understand your point here. Are you suggesting that a given (Evil, revoked) CA may have
> 1) Cert 1
>   - Uses SPKI (say, RSA) with absent params
> 2) Cert 2
>   - Uses SPKI (RSA) with NULL params
> 
> And wanting to kill both certs simultaneously?

My bad I thought you meant Subject Key Id , not Subject Public Key Info. The SPKI is sufficient (though it's not a great key to search on through a PKCS #11 interface).


In any case I hear your objections to subject only, but don't share your concerns. I don't very seriously that anyone will want to resurrect the DigiNotar Subject with another key. In that case you truly want to kill anything from that CA because it wasn't a key compromise but a complete CA failure.

Comment 10

[Ryan Sleevi]

(In reply to Robert Relyea from comment #9)
> In any case I hear your objections to subject only, but don't share your
> concerns. I don't very seriously that anyone will want to resurrect the
> DigiNotar Subject with another key. In that case you truly want to kill
> anything from that CA because it wasn't a key compromise but a complete CA
> failure.

But even if they did - it wouldn't matter - nothing of the old (bad) would validate, and anything new would be, well, new. So revoking by Subject only doesn't resolve/address any security threats not addressed by the other bits, but it introduces new risks, so I'm not sure why it would be desirable if it's more risk and no reward.

Comment 11

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

I'm pretty sure we mean subject and subject public key info here. If we're concerned about key compromise or we have some reason to kill off an entire hierarchy below an intermediate (or root, even), then revoking it by issuer and serial number is insufficient because that certificate could simply be cross-signed by another CA (hello, StartCom and Certnomis: https://groups.google.com/forum/m/#!msg/mozilla.dev.security.policy/hNOJJrN6WfE/5i46-wV5AAAJ ).

Revoking by subject alone could affect unrelated hierarchies (odd as it may be for them to exist).
Revoking by subject public key info alone would work but it's nice to have the subject as an easy identifier for us humans (arguably in the case of key compromise we should revoke just the key, in case it's used elsewhere, however...)