Server Gated Cryptography (SGC) is an extension to the SSL protocol that was introduced in the 1990's in response to United States Federal export control regulations related to the export of products that utilized "Strong Cryptography" outside of the United States; these products from a export control standpoint were considered to be a munition, that's right in the same category as missiles, warheads, guns and bombs and as such could not be sold without prior approval from the US government (see "A Brief History of Cryptography Policy").
Since the world market for technology is much larger than the United States this policy resulted in products that utilized cryptography coming in two forms, "Weak" and "Strong"; Weak cryptography was defined as systems that offered effective security of 56 bits or less, the key point here is that even at this point in computing history 56 bit cryptography was easily crack-able. The reason for this distinction was that historically wars have been won on intelligence and the governments ability to read communications protected with strong cryptography was significantly limited, it was clearly their hope that this restriction would help mitigate that risk.
In comes SGC, with the majority of the world only having access to weak forms of cryptographic protection and financial transactions increasingly going over the Internet a real problem existed it was just as easy for "bad guys" to break Weak cryptography as it was for the US government thus the introduction of SGC.
So how exactly does SGC work? Well its fairly simple, the client and server negotiate a unmodified SSL session but the client only presents the weak cryptographic suites it supports, then at the end of the session if the certificate of the server proves to be valid, was issued by an "SGC Certificate Authority" and contains an Extended Key Usage (EKU) extension with one of the SGC Object Identifiers (OIDs) the client will trigger a session re-negotiation, this time including the "Strong" cryptographic suites it supports also.
What is a SGC Certificate Authority? Well for SGC to actually restrict where "Strong" cryptography will be used there must be both procedural and technological controls around who can get SGC certificates as well as who can issue them. The entity that issues a certificate is referred to as a Certificate Authority (CA), SGC Certificate Authorities are ones that promise to only issue certificates with the special EKUs in them if the subscriber (the web server in this case) meet the regulatory constraints associated with the usage of strong cryptography.
Since there are many CAs trusted by Browsers and Operating Systems these components must be able to differentiate between one that has made the afore mentioned promise and those that have not; although not explicitly part of the protocol a common way these components did this was via Cross Certificates.
A cross-certificate is a certificate issued by one CA that signs the public key for the root certificate of another CA. Cross-certificates provide a means to group all CAs that agree to conform to a common set of rules under a common certification hierarchy.
Earlier I mentioned how the products decide if a server is entitled to do a SGC re-negotiation was out of the scope of the protocol, a great example of this is that each of the products that supported SGC used their own EKUs as part for the decision, for example:
Last thing I wanted to say is that in 2000 the export controls that resulted in the need for SGC were lifted and SGC itself is really no longer needed; for more information on SGC see another post I did on Understanding Server Gated Cryptography.