Re: Use cases of publicly-trusted certificates
On 30/12/2018 14:18, Nick Lamb wrote: On Thu, 27 Dec 2018 22:43:19 +0100 Jakob Bohm via dev-security-policy wrote: You must be traveling in a rather limited bubble of PKIX experts, all of whom live and breathe the reading of RFC5280. Technical people outside that bubble may have easily misread the relevant paragraph in RFC5280 in various ways. It's practically a pub quiz question. I appreciate that I might be unusual in happening to care about this as a lay person, but for a public CA in the Web PKI correctly understanding this stuff was _their job_. It isn't OK for them to be bad at their jobs. Pub quiz questions are particularly tailored to refer to arcane and unexpected facts, which some punters have memorized. The documents that prescribes the exact workings of DNS do not prohibit (only discourage) DNS names containing underscores. Web browser interfaces for URL parsing may not allow them, which would be a technical benefit for at least one usage of such certificates reported in the recent discussion. We get it, you don't accept that not all DNS names can be names of hosts. That you still seem determined not to understand this even when it's explained repeatedly shows that my characterization of this position was correct. I accept that not all DNS names can be names of hosts. I do not accept (without further proof) that certificate issuance is banned for DNS labels that do not refer to hosts at all. In this case because some (unknown) higher level protocol requires the TLS server name to be a label of a special form, specifically designed not to be a host name. And I certainly do not expect subscribers to be aware of such arcane details, subscribers know that certain proof of domain control is required, and if they provide that proof and get a certificate accordingly, they expect that to be perfectly valid and reliable until otherwise informed by the issuing CA. That I disagree with you on certain questions of fact doesn't mean I'm unreliable, merely that you have not presented any persuasive arguments that you are not the one being wrong. I can't distinguish people who are "actually" unreliable from people who claim the plain facts are "unpersuasive" to their point of view, and so I don't. Likewise m.d.s.policy largely doesn't care whether a CA's problems are a result of incompetence or malfeasance, same outcome either way: distrust. You keep ignoring that I am arguing the perspective of the subscribers, not the CAs. I merely dispute that this was obvious to every reader of those documents Since you like legal analogies, the usual standard in law is that something was known _or should have been known_. This means that a declaration that you didn't know something holds no weight if a court concludes that you _should_ have known it. If you have a responsibility to know, "I didn't know" is not usually an excuse. I don't believe subscribers should have known, but I do believe Certificate Authorities should have known, or, as corporate entities, should have employed someone who knew that this was an important thing to understand, did their research and came back with a "No" that had the effect of setting issuance policy. Which is precisely my point. There are lots of people outside the tiny public CA technical and policy community who are technical experts but unaware of that highly obscure reading of RFC5280. Doubtless some ordinary subscribers believe Africa is a country. I don't have a problem with that. But I hope we agree that a CA should not sign a certificate which gives C=AP (an ISO code reserved for other reasons associated with Africa) on the rationale that they thought Africa is a country. Our disagreement would be if multiple such CAs had issued a bunch of C=AP certificates to relevant organizations for use in some scheme that has been technically locked to this aspect. In such a case it would be reasonable to allow those organizations to remove that technical lock, then get new certificates in an orderly fashion. A better example is the pre-2015 issuing of .onion names, which do not exist in the IANA-rooted DNS. A better example in the sense that, if this happened today we would expect CAs not to issue for such a name without first getting a change to the BRs saying this hierarchy is special ? If the situation was that CAs had sensibly not issued for underscores, then asked if they could and been turned down this entire thread would not exist. I strongly suspect (but have no data) that underscore certificates may date back a long time as a practice, perhaps even before the CAB/F was established. I wrote this in opposition to someone seemingly insisting that the _name_ implied that all non-web uses are mistakes that should not be given any credence. You wrote it in reply to me, and you quoted me. I don't know whether my reciting these facts will be "persuasive" to you, but once again refusing to believe something won't stop it being
Re: Use cases of publicly-trusted certificates
On Thu, 27 Dec 2018 16:56:39 -0800 Peter Bowen via dev-security-policy wrote: > - The character Asterisk (U+002A, '*') is not allowed in dNSName SANs > per the same rule forbidding Low Line (U+005F, '_'). RFC 5280 does > say: "Finally, the semantics of subject alternative names that > include wildcard characters (e.g., as a placeholder for a set of > names) are not addressed by this specification. Applications with > specific requirements MAY use such names, but they must define the > semantics." However it never defines what "wildcard characters" are > acceptable. As Wikipedia helpfully documents, there are many > different characters that can be wildcards: > https://en.wikipedia.org/wiki/Wildcard_character. The very same > ballot that attempted to clarify the status of the Low Line character > tried to clarify wildcards, but it failed. The current BRs state > "Wildcard FQDNs are permitted." in the section about subjectAltName, > but the term "Wildcard FQDN" is never defined. Given the poor > drafting, I might be able to argue that Low Line should be considered > a wildcard character that is designed to match a single character, > similar to Full Stop (U+002E, '.') in regular expressions. Are you, in fact, now arguing this? If you, in fact, ever believed this, do you not think it has very significant implications that should have been raised previously? e.g. If these are wildcards, putting one in an EV cert would be a serious problem. Did you go back and check there were problem reports for any cases where EV certs have these imaginary underscore wildcards? Let's be real: There was never any such idea, the underscores are not "wildcards" they're present because some CAs took a lackadaisical approach to name validation that suited their customers better. > - The meaning of the extendedKeyUsage extension in a CA certificate is > unclear. There are at least two views: 1) It constrains the use of > the public key in the certificate and 2) It constrains the use of > end-entity public keys certified by the CA named in the CA > certificate. This has been discussed multiple times on the IETF PKIX > mailing list and no consensus has been reached. Similarly, the X.509 > standard does not clarify. Mozilla takes the second option, but it > is entirely possible that a clarification could show up in a future > RFC or X.500-series doc that goes with the first option. In the absence of a consensus from the relevant IETF Working Groups I don't see why you'd expect a future RFC. Certainly there shouldn't be any mechanism to get a Standards Track RFC without consensus. We can't do anything about ISO, if they go completely off the rails I guess we'd have to decide what to do about that when it happens, it doesn't feel tempting to try to get ahead of that particular calamity. > Of course people are going to try to do better, but part of that is > understanding that people are not perfect and that even automation can > break. I wrote certlint/cablint with hundreds of tests and continue > to get reports of gaps in the tests. Yes, things will get better, > but we need to get them there in an orderly way. This feels pretty orderly to me? We're a pretty long way from, say, the end of Vernor Vinge's novel "Rainbows End", where government spooks issue blanket revocations for all certificates under a major root CA. (It's fun to imagine how disappointingly little effect this would have in our real world) Nick. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Use cases of publicly-trusted certificates
On Thu, 27 Dec 2018 22:43:19 +0100 Jakob Bohm via dev-security-policy wrote: > You must be traveling in a rather limited bubble of PKIX experts, all > of whom live and breathe the reading of RFC5280. Technical people > outside that bubble may have easily misread the relevant paragraph in > RFC5280 in various ways. It's practically a pub quiz question. I appreciate that I might be unusual in happening to care about this as a lay person, but for a public CA in the Web PKI correctly understanding this stuff was _their job_. It isn't OK for them to be bad at their jobs. > The documents that prescribes the exact workings of DNS do not > prohibit (only discourage) DNS names containing underscores. Web > browser interfaces for URL parsing may not allow them, which would be > a technical benefit for at least one usage of such certificates > reported in the recent discussion. We get it, you don't accept that not all DNS names can be names of hosts. That you still seem determined not to understand this even when it's explained repeatedly shows that my characterization of this position was correct. > That I disagree with you on certain questions of fact doesn't mean > I'm unreliable, merely that you have not presented any persuasive > arguments that you are not the one being wrong. I can't distinguish people who are "actually" unreliable from people who claim the plain facts are "unpersuasive" to their point of view, and so I don't. Likewise m.d.s.policy largely doesn't care whether a CA's problems are a result of incompetence or malfeasance, same outcome either way: distrust. > I merely > dispute that this was obvious to every reader of those documents Since you like legal analogies, the usual standard in law is that something was known _or should have been known_. This means that a declaration that you didn't know something holds no weight if a court concludes that you _should_ have known it. If you have a responsibility to know, "I didn't know" is not usually an excuse. I don't believe subscribers should have known, but I do believe Certificate Authorities should have known, or, as corporate entities, should have employed someone who knew that this was an important thing to understand, did their research and came back with a "No" that had the effect of setting issuance policy. Doubtless some ordinary subscribers believe Africa is a country. I don't have a problem with that. But I hope we agree that a CA should not sign a certificate which gives C=AP (an ISO code reserved for other reasons associated with Africa) on the rationale that they thought Africa is a country. > A better example is the pre-2015 issuing of .onion names, which do > not exist in the IANA-rooted DNS. A better example in the sense that, if this happened today we would expect CAs not to issue for such a name without first getting a change to the BRs saying this hierarchy is special ? If the situation was that CAs had sensibly not issued for underscores, then asked if they could and been turned down this entire thread would not exist. > I wrote this in opposition to someone seemingly insisting that the > _name_ implied that all non-web uses are mistakes that should not be > given any credence. You wrote it in reply to me, and you quoted me. I don't know whether my reciting these facts will be "persuasive" to you, but once again refusing to believe something won't stop it being true - it only affects your credibility. Nick. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Use cases of publicly-trusted certificates
On Thu, Dec 27, 2018 at 9:04 AM Nick Lamb via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > On Thu, 27 Dec 2018 15:30:01 +0100 > Jakob Bohm via dev-security-policy > wrote: > > > The problem here is that the prohibition lies in a complex legal > > reading of multiple documents, similar to a situation where a court > > rules that a set of laws has an (unexpected to many) legal > > consequence. > > I completely disagree. This prohibition was an obvious fact, well known > to (I had assumed prior to this present fever) everyone who cared about > the Internet's underlying infrastructure. > > The only species of technical people I ever ran into previously who > professed "ignorance" of the rule were the sort who see documents like > RFCs as descriptive rather than prescriptive and so their position > would be (as it seems yours is) "Whatever I can do is allowed". Hardly > a useful rule for the Web PKI. > As I wrote in the thread on underscores, I am one of the people who believed it was not clear if underscores were allowed or not. This was reflected in the earliest versions of certlint/cablint. If you think it should have been clear, consider the following examples from the real world: - The character Asterisk (U+002A, '*') is not allowed in dNSName SANs per the same rule forbidding Low Line (U+005F, '_'). RFC 5280 does say: "Finally, the semantics of subject alternative names that include wildcard characters (e.g., as a placeholder for a set of names) are not addressed by this specification. Applications with specific requirements MAY use such names, but they must define the semantics." However it never defines what "wildcard characters" are acceptable. As Wikipedia helpfully documents, there are many different characters that can be wildcards: https://en.wikipedia.org/wiki/Wildcard_character. The very same ballot that attempted to clarify the status of the Low Line character tried to clarify wildcards, but it failed. The current BRs state "Wildcard FQDNs are permitted." in the section about subjectAltName, but the term "Wildcard FQDN" is never defined. Given the poor drafting, I might be able to argue that Low Line should be considered a wildcard character that is designed to match a single character, similar to Full Stop (U+002E, '.') in regular expressions. - The meaning of the extendedKeyUsage extension in a CA certificate is unclear. There are at least two views: 1) It constrains the use of the public key in the certificate and 2) It constrains the use of end-entity public keys certified by the CA named in the CA certificate. This has been discussed multiple times on the IETF PKIX mailing list and no consensus has been reached. Similarly, the X.509 standard does not clarify. Mozilla takes the second option, but it is entirely possible that a clarification could show up in a future RFC or X.500-series doc that goes with the first option. These are just two cases where the widely deployed and widely accepted status does not match the RFC. > > It would benefit the honesty of this discussion if the side that won > > in the CAB/F stops pretending that everybody else "should have known" > > that their victory was the only legally possible outcome and should > > never have acted otherwise. > > I would suggest it would more benefit the honesty of the discussion if > those who somehow convinced themselves of falsehood would accept this > was a serious flaw and resolve to do better in future, rather than > suppose that it was unavoidable and so we have to expect they'll keep > doing it. > Of course people are going to try to do better, but part of that is understanding that people are not perfect and that even automation can break. I wrote certlint/cablint with hundreds of tests and continue to get reports of gaps in the tests. Yes, things will get better, but we need to get them there in an orderly way. Thanks, Peter ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
RE: Use cases of publicly-trusted certificates
It clearly wasn't understood by everyone. That's why we had two ballots on it, one of them failing to address the issue. You can just look through the long discussions on the topic to see people didn't agree. -Original Message- From: dev-security-policy On Behalf Of Jakob Bohm via dev-security-policy Sent: Thursday, December 27, 2018 2:43 PM To: mozilla-dev-security-pol...@lists.mozilla.org Subject: Re: Use cases of publicly-trusted certificates On 27/12/2018 18:03, Nick Lamb wrote: > On Thu, 27 Dec 2018 15:30:01 +0100 > Jakob Bohm via dev-security-policy > wrote: > >> The problem here is that the prohibition lies in a complex legal >> reading of multiple documents, similar to a situation where a court >> rules that a set of laws has an (unexpected to many) legal >> consequence. > > I completely disagree. This prohibition was an obvious fact, well > known to (I had assumed prior to this present fever) everyone who > cared about the Internet's underlying infrastructure. > The group who most definitely were unaware of the very specific reading of RFC5280 is the subscribers using such host names in ways that passed all other requirements (including domain name validation). Not the people seeking to allow these names via ballot 202, similar to what was done for other RFC5280 deviations in ballots 75, 88 and 144. > The only species of technical people I ever ran into previously who > professed "ignorance" of the rule were the sort who see documents like > RFCs as descriptive rather than prescriptive and so their position > would be (as it seems yours is) "Whatever I can do is allowed". Hardly > a useful rule for the Web PKI. > You must be traveling in a rather limited bubble of PKIX experts, all of whom live and breathe the reading of RFC5280. Technical people outside that bubble may have easily misread the relevant paragraph in RFC5280 in various ways. Possible ways to overlook the ban on underscores: 1. Not chasing down the RFC1034/RFC1123 references but relying on previously learned rules for what can be in a DNS name. 2. Interpreting the wording in RFC5280 section 4.2.1.6 as simply requiring a canonical encoding of DNS names, thus not allowing e.g. the UTF-8 equivalent of an IDN or duplicate periods, then deferring that encoding job to a 3rd party PKI library. 3. Relying on practice established in certificates without the SAN extension, (thus not subject to section 4.2.1.6 rules) and then continuing without detailed review after it became mandatory to always include the SAN extension for end entities. 4. Trusting the word of others on how to interpret the rules, those others being the ones misreading the standards. > Descriptive documents certainly have their place - I greatly admire > Geoff Pullum's Cambridge Grammar of the English Language, and I do own > the more compact "Student's Introduction" book, both of which are > descriptive since of course a natural language is not defined by such > documents and can only be described by them (and imperfectly, exactly > what's going on in English remains an active area of research). > But that place is not here, the exact workings of DNS are prescribed, > in documents you've called a "complex legal reading of multiple documents" > but more familiarly as "a bunch of pretty readable RFCs on exactly > this topic". > The documents that prescribes the exact workings of DNS do not prohibit (only discourage) DNS names containing underscores. Web browser interfaces for URL parsing may not allow them, which would be a technical benefit for at least one usage of such certificates reported in the recent discussion. The complex reading comes in the understanding that a single sentence in RFC5280 elevates the recommendation in the DNS standards to an absolute requirement in PKIX, combined with the opinion that this particular effect of the wording is not another errata that should be corrected in any later update of the PKIX standard, and/or overridden by a BR clause. >> It would benefit the honesty of this discussion if the side that won >> in the CAB/F stops pretending that everybody else "should have known" >> that their victory was the only legally possible outcome and should >> never have acted otherwise. > > I would suggest it would more benefit the honesty of the discussion if > those who somehow convinced themselves of falsehood would accept this > was a serious flaw and resolve to do better in future, rather than > suppose that it was unavoidable and so we have to expect they'll keep > doing it. > > Consider it from my position. In one case I know Jakob made an error > but has learned a valuable lesson from it and won't be caught the same > way twice. In the ot
Re: Use cases of publicly-trusted certificates
On 27/12/2018 18:03, Nick Lamb wrote: > On Thu, 27 Dec 2018 15:30:01 +0100 > Jakob Bohm via dev-security-policy > wrote: > >> The problem here is that the prohibition lies in a complex legal >> reading of multiple documents, similar to a situation where a court >> rules that a set of laws has an (unexpected to many) legal >> consequence. > > I completely disagree. This prohibition was an obvious fact, well known > to (I had assumed prior to this present fever) everyone who cared about > the Internet's underlying infrastructure. > The group who most definitely were unaware of the very specific reading of RFC5280 is the subscribers using such host names in ways that passed all other requirements (including domain name validation). Not the people seeking to allow these names via ballot 202, similar to what was done for other RFC5280 deviations in ballots 75, 88 and 144. > The only species of technical people I ever ran into previously who > professed "ignorance" of the rule were the sort who see documents like > RFCs as descriptive rather than prescriptive and so their position > would be (as it seems yours is) "Whatever I can do is allowed". Hardly > a useful rule for the Web PKI. > You must be traveling in a rather limited bubble of PKIX experts, all of whom live and breathe the reading of RFC5280. Technical people outside that bubble may have easily misread the relevant paragraph in RFC5280 in various ways. Possible ways to overlook the ban on underscores: 1. Not chasing down the RFC1034/RFC1123 references but relying on previously learned rules for what can be in a DNS name. 2. Interpreting the wording in RFC5280 section 4.2.1.6 as simply requiring a canonical encoding of DNS names, thus not allowing e.g. the UTF-8 equivalent of an IDN or duplicate periods, then deferring that encoding job to a 3rd party PKI library. 3. Relying on practice established in certificates without the SAN extension, (thus not subject to section 4.2.1.6 rules) and then continuing without detailed review after it became mandatory to always include the SAN extension for end entities. 4. Trusting the word of others on how to interpret the rules, those others being the ones misreading the standards. > Descriptive documents certainly have their place - I greatly admire > Geoff Pullum's Cambridge Grammar of the English Language, and I > do own the more compact "Student's Introduction" book, both of which > are descriptive since of course a natural language is not defined by > such documents and can only be described by them (and imperfectly, > exactly what's going on in English remains an active area of research). > But that place is not here, the exact workings of DNS are prescribed, in > documents you've called a "complex legal reading of multiple documents" > but more familiarly as "a bunch of pretty readable RFCs on exactly this > topic". > The documents that prescribes the exact workings of DNS do not prohibit (only discourage) DNS names containing underscores. Web browser interfaces for URL parsing may not allow them, which would be a technical benefit for at least one usage of such certificates reported in the recent discussion. The complex reading comes in the understanding that a single sentence in RFC5280 elevates the recommendation in the DNS standards to an absolute requirement in PKIX, combined with the opinion that this particular effect of the wording is not another errata that should be corrected in any later update of the PKIX standard, and/or overridden by a BR clause. >> It would benefit the honesty of this discussion if the side that won >> in the CAB/F stops pretending that everybody else "should have known" >> that their victory was the only legally possible outcome and should >> never have acted otherwise. > > I would suggest it would more benefit the honesty of the discussion if > those who somehow convinced themselves of falsehood would accept this > was a serious flaw and resolve to do better in future, rather than > suppose that it was unavoidable and so we have to expect they'll keep > doing it. > > Consider it from my position. In one case I know Jakob made an error > but has learned a valuable lesson from it and won't be caught the same > way twice. In the other case Jakob is unreliable on simple matters of > fact and I shouldn't believe anything further he says. > That I disagree with you on certain questions of fact doesn't mean I'm unreliable, merely that you have not presented any persuasive arguments that you are not the one being wrong. I have accepted that a strict, legalistic reading of RFC5280 leads to the ban on underscores in subject alternative names. I merely dispute that this was obvious to every reader of those documents, even if they understood them to be binding technical standards. Hence why I consider the passing of ballot SC12 as similar to a supreme court ruling that a combination of laws constitutes an actually
Re: Use cases of publicly-trusted certificates
On Thu, Dec 27, 2018 at 12:12 PM Wayne Thayer wrote: > On Wed, Dec 26, 2018 at 2:42 PM Peter Bowen via dev-security-policy < > dev-security-policy@lists.mozilla.org> wrote: > >> In the discussion of how to handle certain certificates that no longer >> meet >> CA/Browser Forum baseline requirements, Wayne asked for the "Reason that >> publicly-trusted certificates are in use" by the customers. This seems to >> imply that Mozilla has an opinion that the default should not be to use >> "publicly-trusted certificates". I've not seen this previously raised, so >> I want to better understand the expectations here and what customers >> should >> consider for their future plans. >> > > The context for the question is that at least one of the organizations > having difficulty with the underscore sunset stated that they couldn't just > replace the certificates - they need to ship updates to the client. If you > are hard-coding certificate information into client software, it's fair to > ask why you're using publicly-trusted certificates (PTCs). > I was not aware of this being an issue in this case. Thanks for this explanation. I believe a similar concern was discussed at length during the SHA-1 sunset > in relation to payment terminals. As has been suggested, maybe it's simply > a matter of cost. I suspect, however, that it is more about a lack of > recognition of the responsibilities that come along with using PTCs. In the > spirit of incident reporting, I think it would help to have a better > understanding of the decisions that are driving the use of PTCs in these > use cases > I agree that many people developing products do not understand the fully scope of the responsibilities that come with using Mozilla PTCs. From what I've personally observed, the requirements are frequently: "I want to have a third party manage the CA at no cost to me", "I want that third party to make it relatively easy and fairly inexpensive for arbitrary people and organizations to get certificates that are signed by/chain to the CA", "I want some level of assurance that the third party is doing the right things without having to figure out what the right things are", and (usually only realized much later) "I want to be able to make a decision on whether the risk of not revoking a given a certificate outweigh the benefit of leaving it unrevoked and have the third party not suffer any negative consequences from my decision". I have seen these requirements from organizations large and small. They are not usually written out in these terms, rather there are other requirements that boil down to these. > Is the expectation that "publicly trusted certificates" should only be used >> by customers who for servers that are: >> - meant to be accessed with a Mozilla web browser, and >> > > No. > > - publicly accessible on the Internet (meaning the DNS name is publicly >> resolvable to a public IP), and >> > > No. > > - committed to complying with a 24-hour (wall time) response time >> certificate replacement upon demand by Mozilla? >> >> Committed to comply with section 4.9.1.1 (Reasons for Revoking a > Subscriber Certificate) of the BRs - yes. > In recent revisions to the BRs, it seems that this is extended to 5 days for many cases, including this underscore case. However I think that many customers ("subscribers" in BR terminology) would be very surprised at this requirement, even though it is long standing. > Is the recommendation from Mozilla that customers who want to allow Mozilla >> browsers to access sites but do not want to meet one or both of the other >> two use the Firefox policies for Certificates ( >> >> https://github.com/mozilla/policy-templates/blob/master/README.md#certificates >> ) to add a new CA to the browser? >> >> No, that was not my intent. Rather, I am hoping for a better recognition > of the commitments (per the Subscriber Agreement and CPS) and risks > involved when an organization chooses to use PTCs, especially for > non-browser use cases.] > I think this is a good callout. Mozilla PTCs are a fairly unique situation because there is very little ability to negotiate terms. Most large organizations are accustomed to having a set of requirements as a starting point but working person to person (or organization to organization) to modify the terms to meet their needs. It is clear that this is not an option for Mozilla PTCs and this lack of option is very surprising to the organizations. I'm not sure what can be done about existing deployments of roots in places other than Mozilla software, but it is clear that CAs should be working on options for future non-Mozilla software cases if their customers need more policy flexibility and do not need compatibility with Mozilla software. Thanks, Peter ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Use cases of publicly-trusted certificates
On Thu, Dec 27, 2018 at 8:34 AM Ryan Sleevi via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > On Thu, Dec 27, 2018 at 11:12 AM Jakob Bohm via dev-security-policy < > dev-security-policy@lists.mozilla.org> wrote: > > > Yes, you are consistently mischaracterizing everything I post. > > > > My question was a refinement of the original question to the one case > > where the alternative in the original question (configuring the browser > > to trust a non-default PKI) would not be meaningful. > > > > I hope you can understand my confusion, as again, you've provided a > statement, but not an actual question. > > Peter provided two, fairly simple to understand, very direct questions: > >From earlier messages, I realized that the answer to my initial question is obviously "no", because there is at least one more supported Mozilla product that uses the same trust store: Thunderbird. The second part is also faulty, because it doesn't account for certificates for public IP addresses. Fixing this is makes the question more complex: Is it the expectation of Mozilla that "publicly trusted certificates" for server authentication should only be used by customers for servers that are: a) meant be accessed by Mozilla Firefox and/or Mozilla Thunderbird - This effectively means the server is serving at least one of HTTP, FTP, WS (WebSocket), NNTP, IMAP, POP3, SMTP, IRC, or XMPP over TLS (including iCalendar, CalDAV, WCAP, RSS, and Twitter API over one of the supported protocols) b) are publicly accessible on the Internet - This mean either server is accessed via an IP address is a public IP or via a hostname is publicly resolvable to a public IP - Thunderbird does do SRV record lookups, but SRV records are just pointers to a hostname, so this does not change the above c) committed to complying with a 24-hour (wall time) response time certificate replacement upon demand by Mozilla? This is a longer question, but more accurately reflects how Mozilla uses publicly trusted certificates. Is the expectation that "publicly trusted certificates" should only be used > > by customers who for servers that are: > > - meant to be accessed with a Mozilla web browser, and > > - publicly accessible on the Internet (meaning the DNS name is publicly > > resolvable to a public IP), and > > - committed to complying with a 24-hour (wall time) response time > > certificate replacement upon demand by Mozilla? > Thanks, Peter ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Use cases of publicly-trusted certificates
On 27/12/2018 17:28, Ryan Sleevi wrote: On Thu, Dec 27, 2018 at 11:12 AM Jakob Bohm via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: Yes, you are consistently mischaracterizing everything I post. My question was a refinement of the original question to the one case where the alternative in the original question (configuring the browser to trust a non-default PKI) would not be meaningful. I hope you can understand my confusion, as again, you've provided a statement, but not an actual question. Peter provided two, fairly simple to understand, very direct questions: Is the expectation that "publicly trusted certificates" should only be used by customers who for servers that are: - meant to be accessed with a Mozilla web browser, and - publicly accessible on the Internet (meaning the DNS name is publicly resolvable to a public IP), and - committed to complying with a 24-hour (wall time) response time certificate replacement upon demand by Mozilla? Is the recommendation from Mozilla that customers who want to allow Mozilla browsers to access sites but do not want to meet one or both of the other two use the Firefox policies for Certificates ( https://github.com/mozilla/policy-templates/blob/master/README.md#certificates ) to add a new CA to the browser? You presented a question as: Is the recommendation that customers should not use publicly trusted certificates for servers that are meant to be accessed by the general public using a Mozilla web browser unless they are committed to complying with a 24-hour (wall time) response time certificate replacement upon demand by Mozilla? It would appear that it is merely a rephrasing of that first question, but as a negative question ("should not") rather than Peter's original positive question ("should only"). Could you help me understand what's different about Peter's first question and your question? It's very clear you have opinions as to the second question, but it still seems as if you're merely asking the first question, but in a way that provides less information. If there's something new or unique to the question, rephrasing your question may make it clearer. Doing so without expressing a particular opinion on what the answer should be seems like an even more positive step forward. Once again, the question was about the special case of the combination of Peter's two closely related questions for the case where the option suggested in the second question (using Firefox policies for Certificates) makes no sense, as the "customer" does not control the browser. But you seem insistent on mischaracterizing an unpleasant question in every way possible. Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10 This public discussion message is non-binding and may contain errors. WiseMo - Remote Service Management for PCs, Phones and Embedded ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Use cases of publicly-trusted certificates
On Thu, 27 Dec 2018 15:30:01 +0100 Jakob Bohm via dev-security-policy wrote: > The problem here is that the prohibition lies in a complex legal > reading of multiple documents, similar to a situation where a court > rules that a set of laws has an (unexpected to many) legal > consequence. I completely disagree. This prohibition was an obvious fact, well known to (I had assumed prior to this present fever) everyone who cared about the Internet's underlying infrastructure. The only species of technical people I ever ran into previously who professed "ignorance" of the rule were the sort who see documents like RFCs as descriptive rather than prescriptive and so their position would be (as it seems yours is) "Whatever I can do is allowed". Hardly a useful rule for the Web PKI. Descriptive documents certainly have their place - I greatly admire Geoff Pullum's Cambridge Grammar of the English Language, and I do own the more compact "Student's Introduction" book, both of which are descriptive since of course a natural language is not defined by such documents and can only be described by them (and imperfectly, exactly what's going on in English remains an active area of research). But that place is not here, the exact workings of DNS are prescribed, in documents you've called a "complex legal reading of multiple documents" but more familiarly as "a bunch of pretty readable RFCs on exactly this topic". > It would benefit the honesty of this discussion if the side that won > in the CAB/F stops pretending that everybody else "should have known" > that their victory was the only legally possible outcome and should > never have acted otherwise. I would suggest it would more benefit the honesty of the discussion if those who somehow convinced themselves of falsehood would accept this was a serious flaw and resolve to do better in future, rather than suppose that it was unavoidable and so we have to expect they'll keep doing it. Consider it from my position. In one case I know Jakob made an error but has learned a valuable lesson from it and won't be caught the same way twice. In the other case Jakob is unreliable on simple matters of fact and I shouldn't believe anything further he says. > Maybe because it is not publicly prohibited in general (the DNS > standard only recommends against it, and other public standards > require some such names for uses such as publishing certain public > keys). The prohibition exists only in the certificate standard > (PKIX) and maybe in the registration policies of TLDs (for TLD+1 > names only). Nope. You are, as it seems others in your position have done before, confusing restrictions on all names in DNS with restrictions on names for _hosts_ in DNS. Lots of things can have underscores in their names, and will continue to have underscores in their names, but hosts cannot. Web PKI certs are issued for host names (and IP addresses, and as a special case, TOR hidden services). Imagine if, on the same basis, a CA were to insist that they'd understood Texas to be a US state, and so they'd written C=TX on the rationale that a "state" is essentially the same kind of thing as a "country". I do not doubt they could find a few (mostly Texan) people to defend this view, but it's obviously wrong, and when the City of Austin Independent League of Skateboarders protests that they need to keep getting certificates with C=TX for compatibility reasons we'd have a good laugh and tell the CA to stop being so stupid, revoke these certs and move on. > Also it isn't the "Web PKI". It is the "Public TLS PKI", which is > not confined to Web Browsers surfing online shops and social > networks, and hasn't been since at least the day TLS was made an IETF > standard. It is _named_ the Web PKI. As you point out, it is lots of things, and so "Web PKI" is not a good description but its name remains the Web PKI anyway. The name for people from my country is "Britons". Again it's not a good description, since some of them aren't from the island of Great Britain as the country extends to adjacent islands too. Nevertheless the name is "Britons". Nick. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Use cases of publicly-trusted certificates
On Thu, Dec 27, 2018 at 11:12 AM Jakob Bohm via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > Yes, you are consistently mischaracterizing everything I post. > > My question was a refinement of the original question to the one case > where the alternative in the original question (configuring the browser > to trust a non-default PKI) would not be meaningful. > I hope you can understand my confusion, as again, you've provided a statement, but not an actual question. Peter provided two, fairly simple to understand, very direct questions: Is the expectation that "publicly trusted certificates" should only be used > by customers who for servers that are: > - meant to be accessed with a Mozilla web browser, and > - publicly accessible on the Internet (meaning the DNS name is publicly > resolvable to a public IP), and > - committed to complying with a 24-hour (wall time) response time > certificate replacement upon demand by Mozilla? Is the recommendation from Mozilla that customers who want to allow Mozilla > browsers to access sites but do not want to meet one or both of the other > two use the Firefox policies for Certificates ( > > https://github.com/mozilla/policy-templates/blob/master/README.md#certificates > ) to add a new CA to the browser? You presented a question as: Is the recommendation that customers should not use publicly > trusted certificates for servers that are meant to be accessed by the > general public using a Mozilla web browser unless they are committed > to complying with a 24-hour (wall time) response time certificate > replacement upon demand by Mozilla? It would appear that it is merely a rephrasing of that first question, but as a negative question ("should not") rather than Peter's original positive question ("should only"). Could you help me understand what's different about Peter's first question and your question? It's very clear you have opinions as to the second question, but it still seems as if you're merely asking the first question, but in a way that provides less information. If there's something new or unique to the question, rephrasing your question may make it clearer. Doing so without expressing a particular opinion on what the answer should be seems like an even more positive step forward. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Use cases of publicly-trusted certificates
The main reason that publicly trusted certificates are used by organizations for all infrastructure (internal and external) is that it's far cheaper than building and maintaining an internal PKI. On Thu, Dec 27, 2018 at 4:14 PM Jakob Bohm via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > On 27/12/2018 17:02, Rob Stradling wrote: > > On 27/12/2018 15:38, Jakob Bohm via dev-security-policy wrote: > > > >> For example, the relevant EKU is named "id-kp-serverAuth" not "id-kp- > >> browserWwwServerAuth" . WWW is mentioned only in a comment under the > >> OID definition. > > > > Hi Jakob. > > > > Are you suggesting that comments in ASN.1 specifications are meaningless > > or that they do not convey intent? > > > > Also, are you suggesting that a canonical OID name must clearly convey > > the full and precise intent of the purpose(s) for which the OID should > > be used? > > > > In general no. However in this special case, the comment is > inconsistent with everything else. > > Enjoy > > Jakob > -- > Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com > Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10 > This public discussion message is non-binding and may contain errors. > WiseMo - Remote Service Management for PCs, Phones and Embedded > ___ > dev-security-policy mailing list > dev-security-policy@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-security-policy > ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Use cases of publicly-trusted certificates
On 27/12/2018 17:13, Jakob Bohm wrote: On 27/12/2018 17:02, Rob Stradling wrote: On 27/12/2018 15:38, Jakob Bohm via dev-security-policy wrote: For example, the relevant EKU is named "id-kp-serverAuth" not "id-kp- browserWwwServerAuth" . WWW is mentioned only in a comment under the OID definition. Hi Jakob. Are you suggesting that comments in ASN.1 specifications are meaningless or that they do not convey intent? Also, are you suggesting that a canonical OID name must clearly convey the full and precise intent of the purpose(s) for which the OID should be used? In general no. However in this special case, the comment is inconsistent with everything else. Furthermore, this particular comment is absent in the actual ASN.1 module at the end of RFC5280, making it clear that it isn't a semantic comment. Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10 This public discussion message is non-binding and may contain errors. WiseMo - Remote Service Management for PCs, Phones and Embedded ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Use cases of publicly-trusted certificates
On 27/12/2018 17:02, Rob Stradling wrote: On 27/12/2018 15:38, Jakob Bohm via dev-security-policy wrote: For example, the relevant EKU is named "id-kp-serverAuth" not "id-kp- browserWwwServerAuth" . WWW is mentioned only in a comment under the OID definition. Hi Jakob. Are you suggesting that comments in ASN.1 specifications are meaningless or that they do not convey intent? Also, are you suggesting that a canonical OID name must clearly convey the full and precise intent of the purpose(s) for which the OID should be used? In general no. However in this special case, the comment is inconsistent with everything else. Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10 This public discussion message is non-binding and may contain errors. WiseMo - Remote Service Management for PCs, Phones and Embedded ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Use cases of publicly-trusted certificates
On 27/12/2018 16:55, Ryan Sleevi wrote: On Thu, Dec 27, 2018 at 10:41 AM Jakob Bohm via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: He described three combined conditions to be met. You've described a situation "What if you meet two, but not three". I believe that was originally captured in his question, so what new information is being asked about here? Using Firefox policies to reconfigure the browser is not a relevant alternative for genuinely public web servers in the age of HTTPS- everywhere. That's the difference from the other combinations. I'm sorry, but I still fail to see the question there. That seems to be a statement of opinion. Do you believe it's mischaracterizing your question as effectively restating "What happens if you meet two, but not all three?" If you do, perhaps you could help clarify what your original question is, without any statement about what you believe or presume the answer to be. That seems the best way to get the information you feel is lacking. Yes, you are consistently mischaracterizing everything I post. My question was a refinement of the original question to the one case where the alternative in the original question (configuring the browser to trust a non-default PKI) would not be meaningful. Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10 This public discussion message is non-binding and may contain errors. WiseMo - Remote Service Management for PCs, Phones and Embedded ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Use cases of publicly-trusted certificates
On 27/12/2018 15:38, Jakob Bohm via dev-security-policy wrote: > For example, the relevant EKU is named "id-kp-serverAuth" not "id-kp- > browserWwwServerAuth" . WWW is mentioned only in a comment under the > OID definition. Hi Jakob. Are you suggesting that comments in ASN.1 specifications are meaningless or that they do not convey intent? Also, are you suggesting that a canonical OID name must clearly convey the full and precise intent of the purpose(s) for which the OID should be used? -- Rob Stradling Senior Research & Development Scientist Sectigo Limited ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Use cases of publicly-trusted certificates
On Thu, Dec 27, 2018 at 10:41 AM Jakob Bohm via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > > He described three combined conditions to be met. You've described a > > situation "What if you meet two, but not three". I believe that was > > originally captured in his question, so what new information is being > asked > > about here? > > > > Using Firefox policies to reconfigure the browser is not a relevant > alternative for genuinely public web servers in the age of HTTPS- > everywhere. That's the difference from the other combinations. > I'm sorry, but I still fail to see the question there. That seems to be a statement of opinion. Do you believe it's mischaracterizing your question as effectively restating "What happens if you meet two, but not all three?" If you do, perhaps you could help clarify what your original question is, without any statement about what you believe or presume the answer to be. That seems the best way to get the information you feel is lacking. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Use cases of publicly-trusted certificates
On Thu, Dec 27, 2018 at 10:38 AM Jakob Bohm via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > PKIX clearly uses definitions that make it clear that the same PKI > should be used for most/all TLS implementations for the public Internet, > and this is indeed the common practice on any OS that installs a root > store in a shared location rather than inside browser source code. > This is also not correct, and I'm afraid may be a result of a confusion between certificate profile and what a PKI is. While I would be more than happy to help identify your confusion and resolve it, I don't think this would be the best thread. Unfortunately, both your statement of intent and history are, thankfully, false. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Use cases of publicly-trusted certificates
On 27/12/2018 16:24, Ryan Sleevi wrote: > On Thu, Dec 27, 2018 at 9:34 AM Jakob Bohm via dev-security-policy < > dev-security-policy@lists.mozilla.org> wrote: > >> On 26/12/2018 22:42, Peter Bowen wrote: >>> In the discussion of how to handle certain certificates that no longer >> meet >>> CA/Browser Forum baseline requirements, Wayne asked for the "Reason that >>> publicly-trusted certificates are in use" by the customers. This seems >> to >>> imply that Mozilla has an opinion that the default should not be to use >>> "publicly-trusted certificates". I've not seen this previously raised, >> so >>> I want to better understand the expectations here and what customers >> should >>> consider for their future plans. >>> >>> Is the expectation that "publicly trusted certificates" should only be >> used >>> by customers who for servers that are: >>> - meant to be accessed with a Mozilla web browser, and >>> - publicly accessible on the Internet (meaning the DNS name is publicly >>> resolvable to a public IP), and >>> - committed to complying with a 24-hour (wall time) response time >>> certificate replacement upon demand by Mozilla? >>> >>> Is the recommendation from Mozilla that customers who want to allow >> Mozilla >>> browsers to access sites but do not want to meet one or both of the other >>> two use the Firefox policies for Certificates ( >>> >> https://github.com/mozilla/policy-templates/blob/master/README.md#certificates >>> ) to add a new CA to the browser? >>> >> >> Also, is the recommendation that customers should not use publicly >> trusted certificates for servers that are meant to be accessed by the >> general public using a Mozilla web browser unless they are >> >>> - committed to complying with a 24-hour (wall time) response time >>> certificate replacement upon demand by Mozilla? >> > > Could you help me understand how that question is meaningfully different > than what Peter originally asked? > > He described three combined conditions to be met. You've described a > situation "What if you meet two, but not three". I believe that was > originally captured in his question, so what new information is being asked > about here? > Using Firefox policies to reconfigure the browser is not a relevant alternative for genuinely public web servers in the age of HTTPS- everywhere. That's the difference from the other combinations. Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10 This public discussion message is non-binding and may contain errors. WiseMo - Remote Service Management for PCs, Phones and Embedded ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Use cases of publicly-trusted certificates
On 27/12/2018 16:16, Ryan Sleevi wrote: On Thu, Dec 27, 2018 at 9:30 AM Jakob Bohm via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: Also it isn't the "Web PKI". It is the "Public TLS PKI", which is not confined to Web Browsers surfing online shops and social networks, and hasn't been since at least the day TLS was made an IETF standard. This reply is filled with a number of unrelated and unproductive non-sequitors, but this one is particularly worth calling out as wrong - historically and factually. And I would say that this more accurately describes your reply. TLS has, as with the specifications that preceded it (SSL, PCT), treated PKI as an opaque black box for which inputs go in, and a yes/no come out. TLS has entirely, and intentionally, left unspecified what goes on within that box. The existence of TLS, much like the existence of S/MIME, no more defines the PKI than it defines the color of the sky or what time to set your alarm for the morning. The concept of the PKI has, even in traces of the X.500 DIT, considered itself a loose amalgamation of various different PKIs, interoperating where they are compatible (technology, policies, implementation), but otherwise managed distinct. This can be seen from the first discussions of audits, which were concerned about assessing the interoperability of these distinct PKIs, to the development and foundation of the PKIX WG, which produced a number of documents to smooth the technological differences (e.g. RFC 5280-and-predecessors) and policy differences (3647 and predecessors). PKIX clearly uses definitions that make it clear that the same PKI should be used for most/all TLS implementations for the public Internet, and this is indeed the common practice on any OS that installs a root store in a shared location rather than inside browser source code. For example, the relevant EKU is named "id-kp-serverAuth" not "id-kp- browserWwwServerAuth" . WWW is mentioned only in a comment under the OID definition. Yes, it very much is the "Web PKI", and has been for some time. Considering those sets of CAs bundled in the context for SSL 2.0 and Netscape Navigator were very much intended for the Web, it would be demonstrable ignorance to argue otherwise. Netscape Navigator/Communicator used the same PKI for mail and news servers, Mozilla Thunderbird still does, and both Google and Mozilla use such certificates for their public mail and NNTP servers. Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10 This public discussion message is non-binding and may contain errors. WiseMo - Remote Service Management for PCs, Phones and Embedded ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Use cases of publicly-trusted certificates
On Thu, Dec 27, 2018 at 9:34 AM Jakob Bohm via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > On 26/12/2018 22:42, Peter Bowen wrote: > > In the discussion of how to handle certain certificates that no longer > meet > > CA/Browser Forum baseline requirements, Wayne asked for the "Reason that > > publicly-trusted certificates are in use" by the customers. This seems > to > > imply that Mozilla has an opinion that the default should not be to use > > "publicly-trusted certificates". I've not seen this previously raised, > so > > I want to better understand the expectations here and what customers > should > > consider for their future plans. > > > > Is the expectation that "publicly trusted certificates" should only be > used > > by customers who for servers that are: > > - meant to be accessed with a Mozilla web browser, and > > - publicly accessible on the Internet (meaning the DNS name is publicly > > resolvable to a public IP), and > > - committed to complying with a 24-hour (wall time) response time > > certificate replacement upon demand by Mozilla? > > > > Is the recommendation from Mozilla that customers who want to allow > Mozilla > > browsers to access sites but do not want to meet one or both of the other > > two use the Firefox policies for Certificates ( > > > https://github.com/mozilla/policy-templates/blob/master/README.md#certificates > > ) to add a new CA to the browser? > > > > Also, is the recommendation that customers should not use publicly > trusted certificates for servers that are meant to be accessed by the > general public using a Mozilla web browser unless they are > > > - committed to complying with a 24-hour (wall time) response time > > certificate replacement upon demand by Mozilla? > Could you help me understand how that question is meaningfully different than what Peter originally asked? He described three combined conditions to be met. You've described a situation "What if you meet two, but not three". I believe that was originally captured in his question, so what new information is being asked about here? ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Use cases of publicly-trusted certificates
On Thu, Dec 27, 2018 at 9:30 AM Jakob Bohm via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > Also it isn't the "Web PKI". It is the "Public TLS PKI", which is not > confined to Web Browsers surfing online shops and social networks, and > hasn't > been since at least the day TLS was made an IETF standard. > This reply is filled with a number of unrelated and unproductive non-sequitors, but this one is particularly worth calling out as wrong - historically and factually. TLS has, as with the specifications that preceded it (SSL, PCT), treated PKI as an opaque black box for which inputs go in, and a yes/no come out. TLS has entirely, and intentionally, left unspecified what goes on within that box. The existence of TLS, much like the existence of S/MIME, no more defines the PKI than it defines the color of the sky or what time to set your alarm for the morning. The concept of the PKI has, even in traces of the X.500 DIT, considered itself a loose amalgamation of various different PKIs, interoperating where they are compatible (technology, policies, implementation), but otherwise managed distinct. This can be seen from the first discussions of audits, which were concerned about assessing the interoperability of these distinct PKIs, to the development and foundation of the PKIX WG, which produced a number of documents to smooth the technological differences (e.g. RFC 5280-and-predecessors) and policy differences (3647 and predecessors). Yes, it very much is the "Web PKI", and has been for some time. Considering those sets of CAs bundled in the context for SSL 2.0 and Netscape Navigator were very much intended for the Web, it would be demonstrable ignorance to argue otherwise. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Use cases of publicly-trusted certificates
On 26/12/2018 22:42, Peter Bowen wrote: > In the discussion of how to handle certain certificates that no longer meet > CA/Browser Forum baseline requirements, Wayne asked for the "Reason that > publicly-trusted certificates are in use" by the customers. This seems to > imply that Mozilla has an opinion that the default should not be to use > "publicly-trusted certificates". I've not seen this previously raised, so > I want to better understand the expectations here and what customers should > consider for their future plans. > > Is the expectation that "publicly trusted certificates" should only be used > by customers who for servers that are: > - meant to be accessed with a Mozilla web browser, and > - publicly accessible on the Internet (meaning the DNS name is publicly > resolvable to a public IP), and > - committed to complying with a 24-hour (wall time) response time > certificate replacement upon demand by Mozilla? > > Is the recommendation from Mozilla that customers who want to allow Mozilla > browsers to access sites but do not want to meet one or both of the other > two use the Firefox policies for Certificates ( > https://github.com/mozilla/policy-templates/blob/master/README.md#certificates > ) to add a new CA to the browser? > Also, is the recommendation that customers should not use publicly trusted certificates for servers that are meant to be accessed by the general public using a Mozilla web browser unless they are > - committed to complying with a 24-hour (wall time) response time > certificate replacement upon demand by Mozilla? Which I have repeatedly argued is extremely onerous on a huge subset of all server operators. Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10 This public discussion message is non-binding and may contain errors. WiseMo - Remote Service Management for PCs, Phones and Embedded ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Use cases of publicly-trusted certificates
On 27/12/2018 13:39, Nick Lamb wrote: > As a relying party I read this in the context of the fact that we're > talking about names that are anyway prohibited. > The problem here is that the prohibition lies in a complex legal reading of multiple documents, similar to a situation where a court rules that a set of laws has an (unexpected to many) legal consequence. Such rulings frequently come out from the highest federal courts of the US and the EU, and this is generally referred to as those courts effectively creating new legislation. It would benefit the honesty of this discussion if the side that won in the CAB/F stops pretending that everybody else "should have known" that their victory was the only legally possible outcome and should never have acted otherwise. > Why would you need a publicly trusted certificate that specifies a name > that is publicly prohibited? > Maybe because it is not publicly prohibited in general (the DNS standard only recommends against it, and other public standards require some such names for uses such as publishing certain public keys). The prohibition exists only in the certificate standard (PKIX) and maybe in the registration policies of TLDs (for TLD+1 names only). > I guess the answer is "But it works on Windows". And Windows is welcome > to implement a parallel "Windows PKI" which can have its own rules about > naming and whatever else and so the certificates could be issued in that > PKI but not in the Web PKI. Actually, my only current uses of such names (none with certificates anyway) are all done using a non-Windows OS, and the names seem to work with every DNS library and tool tried. Also it isn't the "Web PKI". It is the "Public TLS PKI", which is not confined to Web Browsers surfing online shops and social networks, and hasn't been since at least the day TLS was made an IETF standard. Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10 This public discussion message is non-binding and may contain errors. WiseMo - Remote Service Management for PCs, Phones and Embedded ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Use cases of publicly-trusted certificates
As a relying party I read this in the context of the fact that we're talking about names that are anyway prohibited.Why would you need a publicly trusted certificate that specifies a name that is publicly prohibited?I guess the answer is "But it works on Windows". And Windows is welcome to implement a parallel "Windows PKI" which can have its own rules about naming and whatever else and so the certificates could be issued in that PKI but not in the Web PKI.___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy