Closed
Bug 982936
Opened 10 years ago
Closed 8 years ago
Communicate to CAs about stopping use of SGC EKU
Categories
(CA Program :: CA Certificate Root Program, task)
CA Program
CA Certificate Root Program
Tracking
(Not tracked)
RESOLVED
FIXED
People
(Reporter: kathleen.a.wilson, Assigned: kathleen.a.wilson)
Details
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.
Comment 1•10 years ago
|
||
(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•10 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•10 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•10 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.
(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•10 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•8 years ago
|
||
See: https://wiki.mozilla.org/CA:Communications#March_2016
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → FIXED
Updated•7 years ago
|
Product: mozilla.org → NSS
Updated•1 year ago
|
Product: NSS → CA Program
You need to log in
before you can comment on or make changes to this bug.
Description
•