Re: Fwd: RE: [cabfpub] Ballot 108: Clarifying the scope of the baseline requirements
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 :-) Gerv I 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#l489 It'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. 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 The reason for line 523 is because S/MIME usage predates EKU_Email_Protection, so SSL_Client certs were used. 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 Technically this is EXT_KEY_USAGE_TIME_STAMP || EKU_TIME_STAMP. NOTE that the Netscape Cert Type extension can set any bit in NSCertType, including bits that didn't exist at the time the cert was issued. (OR even combinations of bits you couldn't get otherwise, like both SSL_SERVER and SSL_SERVER_CA. 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? Certs that have neither a NS_Cert extention nor an EKU Extension are most likely a primitive certificate (primitive in it's use of the standards). CA certs are particularly likely to be
Re: Fwd: RE: [cabfpub] Ballot 108: Clarifying the scope of the baseline requirements
On 15/08/13 19:01, Robert Relyea wrote: 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... Are we currently gathering cert data using Telemetry? Perhaps this could be added. Time_Stamp == EKU_Time_Stamp // 597-601 Technically this is EXT_KEY_USAGE_TIME_STAMP || EKU_TIME_STAMP. What is the difference between these two? Looking at the wording, they seem identical - EKU stands for EXT_KEY_USAGE... It seems the conditions under which a cert is given EXT_KEY_USAGE_STATUS_RESPONDER are wider than those for the other types... I'm not sure what you mean by this. I mean that (for certs with no NS extension and no EKU) the cert is given type EXT_KEY_USAGE_STATUS_RESPONDER if CERT_IsCACert() returns true. This is a more expansive check than merely seeing if basicConstraint.isCA is true - which is what is checked for the other cert types. I am talking about lines 610-618. 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). Feel free to file a bug :-) Gerv -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Fwd: RE: [cabfpub] Ballot 108: Clarifying the scope of the baseline requirements
Time_Stamp == EKU_Time_Stamp // 597-601 Technically this is EXT_KEY_USAGE_TIME_STAMP || EKU_TIME_STAMP. What is the difference between these two? Looking at the wording, they seem identical - EKU stands for EXT_KEY_USAGE... One is the bit set in the Netscape Certificate extension and the other is the oid in the EKU extension. The point is that the Netscape Cert type extension can set any bit in our certType. It seems the conditions under which a cert is given EXT_KEY_USAGE_STATUS_RESPONDER are wider than those for the other types... I'm not sure what you mean by this. I mean that (for certs with no NS extension and no EKU) the cert is given type EXT_KEY_USAGE_STATUS_RESPONDER if CERT_IsCACert() returns true. This is a more expansive check than merely seeing if basicConstraint.isCA is true - which is what is checked for the other cert types. I am talking about lines 610-618. Right if you don't have a NS cert type or EKU extension, then you likely have a primitive cert, which requires a whole lot more futzing to tell if it's a CA cert or not (basically the extra futzing is did someone tell us this is a CA cert in the certdb, which in general happens with root certs primarily). 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). Feel free to file a bug :-) It depends on how critical it is to parsing BR certs. Is it important to know a CA is only treated as a CA if it has basic constraints (barring the database override). I was offering that it might be possible to remove it, but I don't have a pressing need to remove it.;). Gerv 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
Re: Fwd: RE: [cabfpub] Ballot 108: Clarifying the scope of the baseline requirements
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 :-) Gerv I 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(). It'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). 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). We do not parse 'AnyEKU' (though it's reasonable for us to do so). bob Original Message Subject: RE: [cabfpub] Ballot 108: Clarifying the scope of the baseline requirements Date: Thu, 8 Aug 2013 17:10:36 + From: Kelvin Yiu kelv...@exchange.microsoft.com To: jeremy.row...@digicert.com jeremy.row...@digicert.com, 'Gervase Markham' g...@mozilla.org CC: 'CABFPub' pub...@cabforum.org One way to make progress is perhaps for browsers to summarize the certificate profile (e.g. required fields and extensions) that their browsers accept as SSL, code signing, or any other public certificates they accept. For example, I believe IE expects SSL certificates require at least the following: (I will need to do some research to confirm) 1. Either no EKU extension, anyEKU, or the server auth EKU in all certificates in the chain. IE may still accept the old SGC olds as well 2. Valid DNS name in either the CN field in the subject name, or one or more dNSNames or IPv4 address in the SubjectAltName extension 3. Root CA must be enabled for server auth For code signing certificates: 1. Either no EKU extension, anyEKU, or the code signing auth EKU in all certificates in the chain. 2. Root CA must be enabled for code signing 3. Subject name must have either CN, or O, (and maybe OU) field. Hence, OV SSL certificates that do not have an EKU extension (or include the anyEKU OID) are valid for both SSL and code signing. Arguably it is probably not the intention of the CA to issue SSL certificates that can be also used for code signing. At a high level from the MS perspective, I want all CAs that issue certificates that would be interpreted as SSL, code signing, or whatever other usages allowed by the root program) to be in scope of the discussion. The high level principle here is to prevent or at least minimize unintended certificate usages that opens up security vulnerabilities. So if while PIV certificates may include the anyEKU but do not contain any valid DNS name, browsers may reject it for SSL so they can be considered out of scope. I agree the much harder problem to resolve is whether to include CAs with no EKUs that are capable of issuing SSL certificates, but I don't have a good answer yet. Kelvin -Original Message- From: public-boun...@cabforum.org [mailto:public-boun...@cabforum.org] On Behalf Of Jeremy Rowley Sent: Thursday, August 8, 2013 9:04 AM To: 'Gervase Markham' Cc: 'CABFPub' Subject: Re: [cabfpub] Ballot 108: Clarifying the scope of the baseline requirements Yes - I am officially withdrawing the ballot pending further consideration. I'm not sure how to overcome these obstacles since: 1) PIV-I in the US space requires the anyEKU 2) Qualified Certs may require no EKU 3) Certificates without an EKU or the anyEKU may be used as SSL certificates 4) All SSL certificates should be covered by the BRs 5) Qualified and PIV-I Certs cannot be covered by the BRs since they lack a FQDN 6) SSL Certificates without an FQDN are considered local host and explicitly covered by the BRs I think the best option might be to simply acknowledge the inconsistency and change the definition as follows: All root certificates included in a browser's trust store, all subordinate CA certificates signed by one of these root certificates, and all end-entity certificates that either lack any Extended Key Usage extension or contain an Extended Key Usage extension that contain (i) either an Internal Server Name or a FQDN and (ii) one of the following: - Server Authentication (1.3.6.1.5.5.7.3.1) - anyExtendedKeyUsage (2.5.29.37.0) - Netscape Server Gated Cryptography (2.16.840.1.113730.4.1) - Microsoft Server Gated
Fwd: RE: [cabfpub] Ballot 108: Clarifying the scope of the baseline requirements
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 :-) Gerv Original Message Subject: RE: [cabfpub] Ballot 108: Clarifying the scope of the baseline requirements Date: Thu, 8 Aug 2013 17:10:36 + From: Kelvin Yiu kelv...@exchange.microsoft.com To: jeremy.row...@digicert.com jeremy.row...@digicert.com, 'Gervase Markham' g...@mozilla.org CC: 'CABFPub' pub...@cabforum.org One way to make progress is perhaps for browsers to summarize the certificate profile (e.g. required fields and extensions) that their browsers accept as SSL, code signing, or any other public certificates they accept. For example, I believe IE expects SSL certificates require at least the following: (I will need to do some research to confirm) 1. Either no EKU extension, anyEKU, or the server auth EKU in all certificates in the chain. IE may still accept the old SGC olds as well 2. Valid DNS name in either the CN field in the subject name, or one or more dNSNames or IPv4 address in the SubjectAltName extension 3. Root CA must be enabled for server auth For code signing certificates: 1. Either no EKU extension, anyEKU, or the code signing auth EKU in all certificates in the chain. 2. Root CA must be enabled for code signing 3. Subject name must have either CN, or O, (and maybe OU) field. Hence, OV SSL certificates that do not have an EKU extension (or include the anyEKU OID) are valid for both SSL and code signing. Arguably it is probably not the intention of the CA to issue SSL certificates that can be also used for code signing. At a high level from the MS perspective, I want all CAs that issue certificates that would be interpreted as SSL, code signing, or whatever other usages allowed by the root program) to be in scope of the discussion. The high level principle here is to prevent or at least minimize unintended certificate usages that opens up security vulnerabilities. So if while PIV certificates may include the anyEKU but do not contain any valid DNS name, browsers may reject it for SSL so they can be considered out of scope. I agree the much harder problem to resolve is whether to include CAs with no EKUs that are capable of issuing SSL certificates, but I don't have a good answer yet. Kelvin -Original Message- From: public-boun...@cabforum.org [mailto:public-boun...@cabforum.org] On Behalf Of Jeremy Rowley Sent: Thursday, August 8, 2013 9:04 AM To: 'Gervase Markham' Cc: 'CABFPub' Subject: Re: [cabfpub] Ballot 108: Clarifying the scope of the baseline requirements Yes - I am officially withdrawing the ballot pending further consideration. I'm not sure how to overcome these obstacles since: 1) PIV-I in the US space requires the anyEKU 2) Qualified Certs may require no EKU 3) Certificates without an EKU or the anyEKU may be used as SSL certificates 4) All SSL certificates should be covered by the BRs 5) Qualified and PIV-I Certs cannot be covered by the BRs since they lack a FQDN 6) SSL Certificates without an FQDN are considered local host and explicitly covered by the BRs I think the best option might be to simply acknowledge the inconsistency and change the definition as follows: All root certificates included in a browser's trust store, all subordinate CA certificates signed by one of these root certificates, and all end-entity certificates that either lack any Extended Key Usage extension or contain an Extended Key Usage extension that contain (i) either an Internal Server Name or a FQDN and (ii) one of the following: - Server Authentication (1.3.6.1.5.5.7.3.1) - anyExtendedKeyUsage (2.5.29.37.0) - Netscape Server Gated Cryptography (2.16.840.1.113730.4.1) - Microsoft Server Gated Cryptography (1.3.6.1.4.1.311.10.3.3) are expressly covered by these requirements. Jeremy -Original Message- From: Gervase Markham [mailto:g...@mozilla.org] Sent: Thursday, August 08, 2013 9:20 AM To: jeremy.row...@digicert.com Cc: 'CABFPub' Subject: Re: [cabfpub] Ballot 108: Clarifying the scope of the baseline requirements On 02/08/13 12:19, Jeremy Rowley wrote: There is a potential conflict that I think needs more data and discussion: We agree; hence Mozilla votes NO on the ballot in its current form. We would like to see it withdrawn until further information can be gathered. We very much support the goal of this ballot; we want the BRs to cover all certs capable of being used by SSL servers. But we need to figure out whether this requires a change in the definition of what the BRs cover, or a change (e.g. on clients) in the definition of capable of being used by SSL servers. Or something else. Gerv ___ Public mailing list pub...@cabforum.org https://cabforum.org/mailman/listinfo/public -- dev-tech-crypto mailing list
