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 +0000 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 dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
