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
