Re: nameConstraints : leading . in permission list items
Perhaps I am biased a bit!, but if there are no objections maybe the patch should be considered by those with permissions for merging to master? On 13/08/2014 09:31 μμ, Vyronas Tsingaras wrote: Your proposed transition strategy sounds good. Maybe as a first step OpenSSL could tolerate a leading dot and in a future version implement item 6 ? mozilla:pkix and SChannel tolerate this. -Original Message- From: owner-openssl-...@openssl.org [mailto:owner-openssl-...@openssl.org] On Behalf Of John Denker Sent: Wednesday, August 13, 2014 7:59 PM To: openssl-dev@openssl.org Subject: Re: nameConstraints : leading . in permission list items On 08/13/2014 03:46 AM, Vyronas Tsingaras wrote: If you could also take a look at https://github.com/openssl/openssl/pull/111 we have listed a number of reasons. What are your thoughts on this? I agree with the reasoning given there. In particular, one point that I left as an open question in my original post is now persuasively answered. I apologize for not finding that item earlier. I did look; I just missed it somehow. To summarize my current understanding: 1) The pattern /foo.bar/ should match foo.bar and nothing else. It is not a wildcard. 2) The pattern /.foo.bar/ is a wildcard that should match any left-extension, including a.foo.bar, a.b.foo.bar, et cetera ... but not foo.bar itself. 3) If somebody wants to match both, they can include both on the list. 4) AFAICT this is nice and logical and consistent with what users expect and what other SSL implemenations are doing. The argument is strong for the permission list, and even stronger for the exclusion list. 5) Here is the only counterargument I can see: enforcing the non-wildcard requirement (item 1 above) will break applications that are relying on the current undocumented behavior as implemented in v3_ncons.c in openssl-1.0.1i. Therefore I suggest a transition strategy, as follows: 6) We would rather not have a situation where a given cert does one thing on some versions of openssl and different things on other versions (and on competing products). Here is a possible way to survive the transition: We could carefully and conspicuously document the following: Anybody who can tolerate matching foo.com and all of its subdomains should include both /foo.com/ and /.foo.com/ on the list. This covers the most common use-case. Anybody who wants this behavior should issue the appropriate cert ASAP, before the openssl update goes out. Note that anybody who wants to permit the subdomains but not foo.com itself has a problem until openssl gets fixed. The current code provides no way to exclude foo.com without excluding all the subdomains. I see no workaround for this. AFAICT the only fix is to patch the openssl code. I will rewrite my patch code accordingly. It will take me a little while to do this and test it. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org smime.p7s Description: S/MIME Cryptographic Signature
Re: nameConstraints : leading . in permission list items
On 08/13/2014 09:59 AM, at the end of a long message I wrote: [.] I will rewrite my patch code accordingly. It will take me a little while to do this and test it. This is now done. The improved patch can be found at http://www.av8n.com/openssl/leading-dot-better.diff The patch applies against the openssl-1.0.1i tarball. Good discussion so far. Any other helpful ideas out there? __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: nameConstraints : leading . in permission list items
Hey John et al, If you could also take a look at https://github.com/openssl/openssl/pull/111 we have listed a number of reasons. What are your thoughts on this? Regards, Vyronas Tsingaras On 13/08/2014 11:57 πμ, John Denker wrote: Hi Folks -- 0) Beware that I am not an expert in this area. What follows is probably mostly true, but I'm still feeling my way to some extent. 1) There are actually some people who are using v3 nameConstraints. Not a lot, but some. An example can be found in one of the fully-trusted root certificates that is distributed in the current Ubuntu release, and several previous releases: /etc/ssl/certs/Hellenic_Academic_and_Research_Institutions_RootCA_2011.pem which is a symlink to /usr/share/ca-certificates/mozilla/Hellenic_Academic_and_Research_Institutions_RootCA_2011.crt Let's take a look at it: openssl x509 -text -noout Hellenic_Academic_and_Research_Institutions_RootCA_2011.crt [snip] X509v3 Name Constraints: Permitted: DNS:.gr DNS:.eu DNS:.edu DNS:.org email:.gr email:.eu email:.edu email:.org 2) Note the leading . in each item in the permission list. a) This seems entirely logical and reasonable to me. b) All the documentation and examples I've seen on the web assume the . should be there. It's not even a topic of discussion. 3) Desired behavior: openssl should tolerate the leading . Question: Does anybody think the leading . should be mandatory? Or should we tolerate it either way 4) Observed behavior: As of openssl-1.0.1i the leading . is not tolerated. In particular: openssl verify -verbose -check_ss_sig -CAfile $CA_NAME-cert.pem $TARGET-cert.pem server.example.net-cert.pem: C = US, CN = server.example.net error 47 at 0 depth lookup:permitted subtree violation In more detail: I added some debugging printf statements: checking DNS 'www.example.net' against '.example.net' ... result: 47 checking DNS 'www.example.net' against 'example.net' ... result: 0 The certs I used to test this can be found at http://www.av8n.com/openssl/namecon-ca-cert.pem http://www.av8n.com/openssl/server.example.net-cert.pem If somebody wants the ugly little config files I used to create those certs, they can be provided. 5) Here is a patch that seems to make the problem go away. http://www.av8n.com/openssl/leading-dot.patch I do not guarantee that this is high-security industrial-strength code, but it should suffice to let people know where I think the issue lies. If somebody wants to take a closer look at what the code is doing, here is a bundle of debugging printf statements: http://www.av8n.com/openssl/namecon-printf.patch This is not meant to be elegant. It's quick-and-dirty experimentation. I found it useful. YMMV. --- Let's discuss this on the -dev list for a little while to see if anybody has any better insight as to what's going on. Then maybe we can send it over to the request tracker. There's more I could say about this, but I'll stop here for now. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
RE: nameConstraints : leading . in permission list items
Your proposed transition strategy sounds good. Maybe as a first step OpenSSL could tolerate a leading dot and in a future version implement item 6 ? mozilla:pkix and SChannel tolerate this. -Original Message- From: owner-openssl-...@openssl.org [mailto:owner-openssl-...@openssl.org] On Behalf Of John Denker Sent: Wednesday, August 13, 2014 7:59 PM To: openssl-dev@openssl.org Subject: Re: nameConstraints : leading . in permission list items On 08/13/2014 03:46 AM, Vyronas Tsingaras wrote: If you could also take a look at https://github.com/openssl/openssl/pull/111 we have listed a number of reasons. What are your thoughts on this? I agree with the reasoning given there. In particular, one point that I left as an open question in my original post is now persuasively answered. I apologize for not finding that item earlier. I did look; I just missed it somehow. To summarize my current understanding: 1) The pattern /foo.bar/ should match foo.bar and nothing else. It is not a wildcard. 2) The pattern /.foo.bar/ is a wildcard that should match any left-extension, including a.foo.bar, a.b.foo.bar, et cetera ... but not foo.bar itself. 3) If somebody wants to match both, they can include both on the list. 4) AFAICT this is nice and logical and consistent with what users expect and what other SSL implemenations are doing. The argument is strong for the permission list, and even stronger for the exclusion list. 5) Here is the only counterargument I can see: enforcing the non-wildcard requirement (item 1 above) will break applications that are relying on the current undocumented behavior as implemented in v3_ncons.c in openssl-1.0.1i. Therefore I suggest a transition strategy, as follows: 6) We would rather not have a situation where a given cert does one thing on some versions of openssl and different things on other versions (and on competing products). Here is a possible way to survive the transition: We could carefully and conspicuously document the following: Anybody who can tolerate matching foo.com and all of its subdomains should include both /foo.com/ and /.foo.com/ on the list. This covers the most common use-case. Anybody who wants this behavior should issue the appropriate cert ASAP, before the openssl update goes out. Note that anybody who wants to permit the subdomains but not foo.com itself has a problem until openssl gets fixed. The current code provides no way to exclude foo.com without excluding all the subdomains. I see no workaround for this. AFAICT the only fix is to patch the openssl code. I will rewrite my patch code accordingly. It will take me a little while to do this and test it. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
