Communicate to CAs about stopping use of SGC EKU

RESOLVED FIXED

Status

task
RESOLVED FIXED
5 years ago
2 years ago

People

(Reporter: kwilson, Assigned: kwilson)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

Assignee

Description

5 years ago
Communicate to CAs that they need to stop using the "Netscape Server Gated Crypto (2.16.840.1.113730.4.1)" (SGC) EKU. 

For all new certificate issuance, they should use the "TLS Web Server Authentication (1.3.6.1.5.5.7.3.1)" EKU instead of the SGC EKU.

Also consider having CAs send Mozilla replacement intermediate certs for the old intermediate certs that use the SGC EKU. CAs can supply Mozilla with a new version of the intermediate cert that has the same subject name and the same public key, but with a different serial number, with the "TLS Web Server Authentication (1.3.6.1.5.5.7.3.1)" EKU. Then, Mozilla would embed the certificate into NSS without any trust records. This way, Mozilla could reject the intermediate cert sent by the web server and use the new certificate with the new EKU.
(In reply to Kathleen Wilson from comment #0)
> Also consider having CAs send Mozilla replacement intermediate certs for the
> old intermediate certs that use the SGC EKU. CAs can supply Mozilla with a
> new version of the intermediate cert that has the same subject name and the
> same public key, but with a different serial number, with the "TLS Web
> Server Authentication (1.3.6.1.5.5.7.3.1)" EKU. Then, Mozilla would embed
> the certificate into NSS without any trust records. This way, Mozilla could
> reject the intermediate cert sent by the web server and use the new
> certificate with the new EKU.

Would this then lead to us removing the workaround which makes the original certs work?

If no, then what's the point?

If yes, then it makes the "correct" (compatible) functioning of NSS dependent on using the Mozilla root store in a non-obvious way. Because including the relevant roots is not enough; one would also need to include the new-intermediates which chain up to those roots. And that may not be obvious to a user, and such certs are not massively common so they may only discover this mistake when their code is in production. It's a heffalump trap.

So I don't think we should do this. Instead, we should constrain the compatibility workaround as far as possible, to avoid the problem getting worse.

Gerv

Comment 2

5 years ago
+1 to Gerv.

IINM, the "compatibility workaround" (i.e. treat the Step-Up/SGC OIDs as equivalent to the TLS Server Authentication OID) is implemented in the "classic" NSS code, libpkix and by Microsoft CryptoAPI, so arguably it is de facto standard behaviour rather than a "problem".
Assignee

Comment 3

5 years ago
(In reply to Rob Stradling from comment #2)
> +1 to Gerv.

I'm OK with that too.

> 
> IINM, the "compatibility workaround" (i.e. treat the Step-Up/SGC OIDs as
> equivalent to the TLS Server Authentication OID) is implemented in the
> "classic" NSS code, libpkix and by Microsoft CryptoAPI, so arguably it is de
> facto standard behaviour rather than a "problem".

But I think CAs should not use the obsolete EKU when they issue new intermediate certs. So I think this should be communicated to CAs, and possibly become part of the BRs.

Comment 4

5 years ago
(In reply to Kathleen Wilson from comment #3)
<snip>
> But I think CAs should not use the obsolete EKU when they issue new
> intermediate certs. So I think this should be communicated to CAs, and
> possibly become part of the BRs.

Agreed.

Comment 5

5 years ago
(In reply to Kathleen Wilson from comment #3)
> (In reply to Rob Stradling from comment #2)
> > +1 to Gerv.
> 
> I'm OK with that too.
> 
> > 
> > IINM, the "compatibility workaround" (i.e. treat the Step-Up/SGC OIDs as
> > equivalent to the TLS Server Authentication OID) is implemented in the
> > "classic" NSS code, libpkix and by Microsoft CryptoAPI, so arguably it is de
> > facto standard behaviour rather than a "problem".
> 
> But I think CAs should not use the obsolete EKU when they issue new
> intermediate certs. So I think this should be communicated to CAs, and
> possibly become part of the BRs.

I agree as well.

Comment 6

5 years ago
My feeling is that CAs should stop issuing SGC certificates altogether and transition all of them to normal certs (without the EKUs) on renewal.
Assignee

Comment 7

3 years ago
See:
https://wiki.mozilla.org/CA:Communications#March_2016
Status: NEW → RESOLVED
Last Resolved: 3 years ago
Resolution: --- → FIXED

Updated

2 years ago
Product: mozilla.org → NSS
You need to log in before you can comment on or make changes to this bug.