On 08/15/2013 03:21 AM, Gervase Markham wrote:
On 15/08/13 01:19, Robert Relyea wrote:On 08/09/2013 02:57 AM, Gervase Markham wrote:Can an NSS hacker please tell me, in the fashion of the attempt by the IE representative below, what types of certificate NSS accepts for making SSL connections? What features must the cert or chain have or not have?Or, if this is a PSM question, tell me that :-) GervI think you already have the answer, but here's the basic: The code to determine the type a cert is in in certdb.c called cert_ComputeCertType().For those following along: http://dxr.mozilla.org/mozilla-central/source/security/nss/lib/certdb/certdb.c#l489It's rather complex to allow historical issued certificates to function: If the cert has neither an extended key usage or a netscape cert extension, then the cert is considered legacy and OK for use for everything except code signing (Email/SSL client/SSL Server).Do we have any idea of the compatibility impact of changing that behaviour so that we do not accept such certs for authenticating SSL servers?
That's an instrumentation issue. It was true back in 1995/6 when the code was added I don't know how true it is today. My guess is the biggest compatibility issue is self-issued certs, not CA issued certs... but then again most of those are self-signed...
We should also check the use of the NS Cert Type extension. My guess is in the real world, if it exists, it's data is mirrored by basic constraints and extended key usage.
The reason for line 523 is because S/MIME usage predates EKU_Email_Protection, so SSL_Client certs were used.If the cert as either an extended key usage or a netscape cert extension, then the cert must have the SSL_Server type set. Exception, if it has the extended key usage and the Govt_approved, it is assumed to also have SSL_Server. The code has some comment that "COMMODO needs this behavior until 2020". If the cert has both an extended key usage and a netscape cert extension, only one of these need to indicate that it's an SSL_Server cert. Also, the cert can't be a CA cert (SSL Server+CA maps to a CA that can issue SSL_Server certs, not an SSL_Server cert).So the logic of that code block, as I read it, is: SSL_Server == !(NS_Type_Extension || EKU_Extension) // 608-621 || NS_Type_SSL_Server // 516 || !BC_isCA && ( EKU_Server_Auth // 553-562 || NS_Govt_Approved // 563-576 ) SSL_Client == !(NS_Type_Extension || EKU_Extension) // 608-621 || NS_Type_SSL_Client // 516 || EKU_SSL_Client_Auth // 577-586 SSL_CA == NS_SSL_CA // 516 || BC_isCA && ( !(NS_Type_Extension || EKU_Extension) // 608-621 || NS_Type_Email_CA // 531-537 || EKU_SSL_Server_Auth // 553-562 || NS_Govt_Approved // 563-576 || EKU_SSL_Client_Auth // 577-586 ) Email == NS_Type_Email // 516 || !(NS_Type_Extension || EKU_Extension) // 608-621 || (NS_Type_SSL_Client && Has_Email_Address) // 523-530 || (EKU_Email_Protect && !BC_isCA) // 538-552
Email_CA == NS_Type_Email_CA // 516
|| BC_isCA && (
!(NS_Type_Extension || EKU_Extension) // 608-621
|| EKU_Email_Protect // 538-552
)
Code_Sign == NS_Type_Object_Signing // 516
|| (EKU_Code_Sign && !BC_isCA) // 587-596
Code_Sign_CA == NS_Type_Object_Signing_CA // 516
|| (EKU_Code_Sign && BC_isCA) // 587-596
Time_Stamp == EKU_Time_Stamp // 597-601
OCSP_Resp == OID_OCSP_Responder // 602-606
|| is_Any_CA_Type &&
!(NS_Type_Extension || EKU_Extension) // 608-621
Questions:
* Line 608ff: why does this part of the code use two ways of determining
whether a cert is a CA cert?
Also, if we have extKeyUsage, it's meaning is modified by spec by the basic constraint, not by whether or not NSS really thinks the cert is a CA cert.
I'm not sure what you mean by this. A responder is either a CA, or a certificate that has been delegated as such by the CA. Remember that CA certificates are more likely to be primitive than a leaf certificate. NOTE: certtype != trusted type. It's a necessary, but not sufficient condition. Even though many certs can be responders, the certs are trusted for OCSP responses certs issued by the cert itself (case where the responder == CA) or the cert that signed it (case where the responder is delegated).It seems the conditions under which a cert is given EXT_KEY_USAGE_STATUS_RESPONDER are wider than those for the other types...
yes, the NS Cert extension pre-dates both extended key usage and basic constraints. I suspect that it drove the implementation of the latter two. It's been several decades since we have the general constraints and the NS Cert extension is basically redundant in face of that, so I think it would be good to look at deprecating the support for parsing NS Cert extensions altogether. (It may even be safer to do this than to drop support for certs with neither extension). While CA certificates tend to be more primitive, at least the intermediates are likely to have basic constraints these days. Back in 2002/2003 when Microsoft wasn't looking at basic constraints, it could be possible that an intermediate only had a NS Cert extension, but since that time it's highly unlikely that and intermediate would not have a basic constraint.* I believe that even if something does not have basicConstraints: CA=TRUE, it can be declared as a CA cert by the Netscape Cert Type extension. Is that correct?
bob
smime.p7s
Description: S/MIME Cryptographic Signature
-- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
