Re: Domain-validated name-constrained CA certificates?
Matt McCutchen wrote: On Apr 6, 5:54 am, Jean-Marc Desperrierjmd...@gmail.com wrote: Matt McCutchen wrote: An extended key usage of TLS Web Server Authentication on the intermediate CA would constrain all sub-certificates, no? You are here talking about a proprietary Microsoft extension of the X509 security model. No, I'm talking about the Extended Key Usage extension defined in RFC 5280 section 4.2.1.12. I repeat, you *are* talking about a proprietary Microsoft extension, which is to take into account the EKU inside path validation. The EKU as defined in section 4.2.1.12 of RFC 5280 only applies to the certificate that contains it, it has no effect on certification paths that include that certificate. -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Domain-validated name-constrained CA certificates?
On Apr 7, 4:54 am, Jean-Marc Desperrier jmd...@gmail.com wrote: Matt McCutchen wrote: On Apr 6, 5:54 am, Jean-Marc Desperrierjmd...@gmail.com wrote: Matt McCutchen wrote: An extended key usage of TLS Web Server Authentication on the intermediate CA would constrain all sub-certificates, no? You are here talking about a proprietary Microsoft extension of the X509 security model. No, I'm talking about the Extended Key Usage extension defined in RFC 5280 section 4.2.1.12. I repeat, you *are* talking about a proprietary Microsoft extension, which is to take into account the EKU inside path validation. The EKU as defined in section 4.2.1.12 of RFC 5280 only applies to the certificate that contains it, it has no effect on certification paths that include that certificate. Ah, you are right. Bummer! We do need a way to limit the intermediate certificate to SSL server usage, otherwise it will be difficult to anticipate and close off all the possibilities for abuse with other EKUs. I will raise this with the PKIX working group. The Microsoft behavior makes complete sense to me, so maybe it could just be adopted by the standard. -- Matt -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Domain-validated name-constrained CA certificates?
On 2010-04-07 01:54 PST, Jean-Marc Desperrier wrote: Matt McCutchen wrote: On Apr 6, 5:54 am, Jean-Marc Desperrierjmd...@gmail.com wrote: Matt McCutchen wrote: An extended key usage of TLS Web Server Authentication on the intermediate CA would constrain all sub-certificates, no? You are here talking about a proprietary Microsoft extension of the X509 security model. No, I'm talking about the Extended Key Usage extension defined in RFC 5280 section 4.2.1.12. I repeat, you *are* talking about a proprietary Microsoft extension, which is to take into account the EKU inside path validation. The EKU as defined in section 4.2.1.12 of RFC 5280 only applies to the certificate that contains it, it has no effect on certification paths that include that certificate. Once RFC 3280 and 5280 were published, that did indeed become the specification of EKU. But long before that, both Netscape (where NSS originated) and Microsoft did just what Matt is describing, and they still do. I can point to some email from former a Microsoft PM (product? project? program? manager) saying that Microsoft adopted it because their competition was already using it, and that Microsoft has no plans to stop it. -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Domain-validated name-constrained CA certificates?
On Apr 7, 12:47 am, Kurt Seifried k...@seifried.org wrote: What about www.paypal.com[NULL].yourcompany.com? I assume that would be allowed by the name constraint with respect to fixed software, but still hit some older software that has the NULL certificate bug. I think www.paypal.com[NULL].yourcompany.com would match the name constraint, but it isn't important, since modern software will not allow that to match a requested hostname of www.paypal.com. If some people are still using software that is vulnerable, that's their fault; we can't let them tie our hands indefinitely. I'm also curious what about www.paypal.com[lotsof spaces or underscores or something like that].yourcompany.com? Spaces are not a problem because Firefox will not parse a URL where the hostname contains a space. Barring spaces, this is the same concern raised in the Problematic Practices for wildcard certificates, except that the name constraints allow multiple labels (i.e., dots): https://wiki.mozilla.org/CA:Problematic_Practices#Wildcard_DV_SSL_certificates Personally I'm not worried about this weak attempt to fool the user. It will be pretty obvious when the Larry button shows yourcompany.com (browser.identity.ssl_domain_display = 1) or the whole www.paypal.com__.yourcompany.com (2). -- Matt -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Domain-validated name-constrained CA certificates?
Matt McCutchen wrote: An extended key usage of TLS Web Server Authentication on the intermediate CA would constrain all sub-certificates, no? You are here talking about a proprietary Microsoft extension of the X509 security model. -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Domain-validated name-constrained CA certificates?
Matt McCutchen wrote: A name-constrained intermediate certificate could be quite convenient for the large organizations that are presently demanding their users to trust private CAs for the whole Web (see bug 501697). Ah ! The direction of restricting people who currently use sub-CA for their purpose to make it more secure will certainly be much more successful than presenting it as allowing many more people to have their own sub-CA. -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Domain-validated name-constrained CA certificates?
On Tuesday 06 April 2010 10:54:49 Jean-Marc Desperrier wrote: Matt McCutchen wrote: An extended key usage of TLS Web Server Authentication on the intermediate CA would constrain all sub-certificates, no? You are here talking about a proprietary Microsoft extension of the X509 security model. Mozilla has its own proprietary certificate extension (Netscape Cert Type) that (IINM) can be used to achieve the same outcome (by setting the SSL CA bit). http://www.mozilla.org/projects/security/pki/nss/tech-notes/tn3.html has some old notes from Nelson. AFAIK, this extension is still supported by NSS, but having said that I wouldn't be surprised if Nelson replies to this message with words to the effect of that extension is deprecated, so please don't use it any more! Rob Stradling Senior Research Development Scientist C·O·M·O·D·O - Creating Trust Online Office Tel: +44.(0)1274.730505 Office Fax: +44.(0)1274.730909 www.comodo.com Comodo CA Limited, Registered in England No. 04058690 Registered Office: 3rd Floor, 26 Office Village, Exchange Quay, Trafford Road, Salford, Manchester M5 3EQ This e-mail and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the sender by replying to the e-mail containing this attachment. Replies to this email may be monitored by Comodo for operational or business reasons. Whilst every endeavour is taken to ensure that e-mails are free from viruses, no liability can be accepted and the recipient is requested to use their own virus checking software. -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Domain-validated name-constrained CA certificates?
On Apr 6, 5:54 am, Jean-Marc Desperrier jmd...@gmail.com wrote: Matt McCutchen wrote: An extended key usage of TLS Web Server Authentication on the intermediate CA would constrain all sub-certificates, no? You are here talking about a proprietary Microsoft extension of the X509 security model. No, I'm talking about the Extended Key Usage extension defined in RFC 5280 section 4.2.1.12. -- Matt -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Domain-validated name-constrained CA certificates?
On Apr 6, 5:58 am, Jean-Marc Desperrier jmd...@gmail.com wrote: Ah ! The direction of restricting people who currently use sub-CA for their purpose to make it more secure will certainly be much more successful than presenting it as allowing many more people to have their own sub-CA. But I do want to allow many more people to have their own sub-CAs, unless there is an actual technical reason why it is a bad idea, in which case I am hoping you will tell me. The only issues I am aware of are the two from my original message. -- Matt -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Domain-validated name-constrained CA certificates?
On 04/07/2010 05:01 AM, Matt McCutchen: On Apr 6, 5:58 am, Jean-Marc Desperrierjmd...@gmail.com wrote: Ah ! The direction of restricting people who currently use sub-CA for their purpose to make it more secure will certainly be much more successful than presenting it as allowing many more people to have their own sub-CA. But I do want to allow many more people to have their own sub-CAs, unless there is an actual technical reason why it is a bad idea, in which case I am hoping you will tell me. Yes, for example do all potential client software enforce name-constraining? How are the keys secured? Are the sub CAs going to be audited (including site visit) as the root CA? How are the validation requirements enforce? And a couple of more such questions... If NSS would enforce name-constraining it will not automatically mean that CAs would from then on happily issue intermediate CA certificates to whomever asking. It however would allow to limit certain roots to their specific field of activity if certain concerns exist or in case it would make sense to do so. It's interesting mainly for CA roots, much less for CAs issuing intermediate CAs to third parties. -- Regards Signer: Eddy Nigg, StartCom Ltd. XMPP:start...@startcom.org Blog:http://blog.startcom.org/ Twitter: http://twitter.com/eddy_nigg -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Domain-validated name-constrained CA certificates?
On Wed, 2010-04-07 at 05:17 +0300, Eddy Nigg wrote: On 04/07/2010 05:01 AM, Matt McCutchen: But I do want to allow many more people to have their own sub-CAs, unless there is an actual technical reason why it is a bad idea, in which case I am hoping you will tell me. Yes, for example do all potential client software enforce name-constraining? No. But since the name constraint extension is critical, client software that does not support name constraints is required to reject the intermediate certificate, which is safe. If client software accepts the certificate but does not properly enforce the name constraints (e.g., NSS bug 394919), that is the client software's vulnerability. CAs could start doing as I propose today. NSS users would be vulnerable and, strictly speaking, it would be their own fault. Users of client software that does not support name constraints (MSIE?) would be completely unaffected since their software would reject all the new sub-CAs. How are the keys secured? Are the sub CAs going to be audited (including site visit) as the root CA? How are the validation requirements enforce? And a couple of more such questions... This is not an issue. The name constraint makes it impossible for a domain registrant to issue a certificate that validates for a server name outside that domain. Hence, anything bad I do with my intermediate certificate could only hurt me as registrant of mattmccutchen.net. -- Matt -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Domain-validated name-constrained CA certificates?
This is not an issue. The name constraint makes it impossible for a domain registrant to issue a certificate that validates for a server name outside that domain. Hence, anything bad I do with my intermediate certificate could only hurt me as registrant of mattmccutchen.net. What about www.paypal.com[NULL].yourcompany.com? I assume that would be allowed by the name constraint with respect to fixed software, but still hit some older software that has the NULL certificate bug. I'm also curious what about www.paypal.com[lots of spaces or underscores or something like that].yourcompany.com? -- Matt -Kurt -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Domain-validated name-constrained CA certificates?
[This thread is to continue the discussion from bug 554442; this message recaps the substance of the existing discussion.] It would be great if a Mozilla-recognized CA would be willing to give me, as the registrant of mattmccutchen.net, an intermediate CA certificate with a critical name constraint limiting it to mattmccutchen.net. That would give me unlimited flexibility to issue certificates for subdomains without bothering the CA. Such a certificate would be an alternative to a wildcard certificate that removes some limitations without fundamentally changing the security model. What are the technical obstacles that stand in the way of issuing such certificates? I am aware of two: #1. Bug 394919: NSS accepts the subject common name as an SSL server name but does not constrain it. In bug 554442, I requested a hack so that CAs could start using critical name constraints without NSS versions lacking the fix for bug 394919 becoming vulnerable, but Nelson Bolyard decided that wasn't necessary. #2. The tooltip of the Firefox SSL badge (a.k.a. Larry site identity button) shows the Organization field of the lowest CA certificate, i.e., the immediate signer of the server certificate. The registrant could put a misleading value in this field. For example: Some Mozilla-recognized CA \_ Matt's CA (name constraint: mattmccutchen.net) \_ your evil twin \_ foo.mattmccutchen.net +--+ +-+ | [icon] foo.mattmccutchen.net | --- | Verified by: your evil twin | +--+ +-+ Setting a maximum path length of 0 on the registrant's certificate would prevent this outcome, but it's a disappointing solution. Should Firefox show the organization name of the root CA instead, since it is ultimately responsible for all validation paths that end at its trust bit? -- Matt -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Domain-validated name-constrained CA certificates?
On 04/04/2010 08:32, Matt McCutchen wrote: [...] It would be great if a Mozilla-recognized CA would be willing to give me, as the registrant of mattmccutchen.net, an intermediate CA certificate with a critical name constraint limiting it to mattmccutchen.net. I don't believe this taking a hammer to crack a nut approach will have much success. Especially since there's also the fact the CA would not be able to constraint the *usage* you give to your certs. #2. The tooltip of the Firefox SSL badge (a.k.a. Larry site identity button) shows the Organization field of the lowest CA certificate, [...] The registrant could put a misleading value in this field. [...] Should Firefox show the organization name of the root CA instead, since it is ultimately responsible for all validation paths that end at its trust bit? We are to something much more interesting here. I'm not sure it's really a great practice to have only one level that's taken into account there. But then only the root might be a bit too much in the other side. So, maybe something better is needed but it's not easy to decide what. -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Domain-validated name-constrained CA certificates?
On Apr 4, 6:30 pm, Jean-Marc Desperrier wrote: On 04/04/2010 08:32, Matt McCutchen wrote: [...] It would be great if a Mozilla-recognized CA would be willing to give me, as the registrant of mattmccutchen.net, an intermediate CA certificate with a critical name constraint limiting it to mattmccutchen.net. I don't believe this taking a hammer to crack a nut approach will have much success. A name-constrained intermediate certificate could be quite convenient for the large organizations that are presently demanding their users to trust private CAs for the whole Web (see bug 501697). Users with new enough NSS would see the sites just work; other users could trust the intermediate certificate as if it were a root. Especially since there's also the fact the CA would not be able to constraint the *usage* you give to your certs. An extended key usage of TLS Web Server Authentication on the intermediate CA would constrain all sub-certificates, no? -- Matt -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
