On Tuesday, May 23, 2017 at 10:53:03 AM UTC-5, Jakob Bohm wrote: > > Or could this be solved by require such "TCSC light" SubCA certs to > carry a specific CAB/F policy OID with CT-based community enforcement > that all SubCA certs with this policy OID comply with the more stringent > non-computable requirements likely to be in such a policy (if passed)? >
I wish to clarify a couple points of what I proposed. With respect to the topic of this thread -- the certificate policy & disclosure scope at Mozilla, I have proposed that particular categories of intermediate certificate (name constrained subCAs with particular features) might be reasonably subjected to a lower burden, requiring no formal disclosure to Mozilla beyond that their existence and issuance be CT logged. Also, I proposed that further subCAs and EEs issued descending from those constrained subCAs be regarded as entirely beyond the scope of the Mozilla Policy and disclosure. I maintain that I've not seen presented a compelling technical reason that would suggest that such change to Mozilla policy would reduce security in the Web PKI if adopted. If this is the case, reducing requirement for disclosure to CCADB and attendant audit statements, etc, for these TCSCs would seem to reduce work burden on Mozilla as well as the public CAs. Quite separately, I would personally like to see some BR changes similarly in line with the above, but I am not positioned to make such a request, as I am not a CA. Further, I acknowledge that this thread is probably not the appropriate forum for that particular case to be pleaded. Having said all of that, I wish to make clear that I have not proposed that the technological burdens of certificate issuance by an entity utilizing a technically constrained subCA should be lightened in actual issuance practice: Specifically, I am a supporter of Certificate Transparency. I see no reason, for example, why an EE certificate issued subordinate to a TCSC should be exempted from Chrome's CT Policy, etc. An enterprise PKI utilizing a TCSC could certainly submit the certificates they issue to CT logging. Those same certificates do, in fact, chain to trusted roots. I can think of no reason that a CT log would reject those submissions. I wish to clarify that my position is that EE certificates issued subordinate to a name constrained CA need be of no concern to Mozilla and the other programs from a monitoring perspective relies upon the quite limited scope of effect the EE certificate can have after accounting for the regulations in the TCSC. In short, I believe that the need to enforce audits, etc, over what an enterprise who have been issued a proper TCSC actually does with that TCSC is unnecessary, because anything they could do would be limited in scope to their own operations. This includes issuing certificates which don't comply with CT logging, etc. I fully believe the same standards of technical constraint applied to certificates of a public CA would also apply to trust in certificates issued subordinate to a TCSC. I just think there's no need to concern themselves if someone quite clever (whatever that means) decides to ASN.1 encode a Trollface GIF and roll that into an EE cert subordinate to their corporate TCSC. No need to report that as a BR violation. No need for the sponsoring public CA to be concerned if they discover that upon audit, because I think there's no need for said audit. Because anything that audit could have found could have been discovered by browser validation code, with the judgement rendered instantly and with proportionate consequence: (i.e. this is garbage, not a certificate, I'm going with the untrusted interstitial error). > >> * If TCSCs are limited, by requirements on BR-complient unconstrained > >> SubCAs, to lifetimes that are the BR maximum of N years + a few months > >> (e.g. 2 years + a few months for the latest CAB/F requirements), then > >> any new CAB/F requirements on the algorithms etc. in SubCAs will be > >> phased in as quickly as for EE certs. > >> > > > > I'm not sure what you're trying to say here, but the limits of lifetime to > > EE certs are different than that of unconstrained subCAs (substantially) > > I am trying to limit the scope of this to the kind of TCSC (Technically > Constrained SubCA) that Matthew was advocating for. Thus none of this > applies to long lived or public SubCAs. > > If an organization wants ongoing TCSC availability, they may subscribe > to getting a fresh TCSC halfway through the lifetime of the previous > one, to provide a constantly overlapping chain of SubCAs. > > > > > > >> * If TCSCs cannot be renewed with the same public key, then TCSC issued > >> EEs are also subject to the same phase in deadlines as regular EEs. > >> > > > > Renewing with the same public key is a problematic practice that should be > > stopped. > > > > Some other people seem to disagree, however in this case I am > constraining the discussion to a specific case where this would be > forbidden (And enforced via CT logging of the TCSC certs). Thus no > debate on that particular issue. > > > > >> * When issuing new/replacement TCSCs, CA operators should (by policy) be > >> required to inform the prospective TCSC holders which options in EE > >> certs (such as key strengths) will not be accepted by relying parties > >> after certain phase-out dates during the TCSC lifetime. It would then > >> be foolish (and of little consequence to the WebPKI as a whole) if any > >> TCSC holders ignore those restrictions. > >> > > > > This seems to be operating on an ideal world theory, not a real world > > incentives theory. > > > > First, there's the obvious problem that "required to inform" is > > fundamentally problematic, and has been pointed out to you by Gerv in the > > past. CAs were required to inform for a variety of things - but that > > doesn't change market incentives. For that matter, "required to inform" can > > be met by white text on a white background, or a box that clicks through, > > or a default-checked "opt-in to future communications" requirement. The > > history of human-computer interaction (and the gamification of regulatory > > action) shows this is a toothless and not meaningful action. > > > > I understand your intent is to be like "Surgeon General's Warning" on > > cigarettes (in the US), or more substantive warnings in other countries, > > and while that is well-intentioned as a deterrent - and works for some > > cases - is to otherwise ignore the public health risk or to try to sweep it > > under the rug under the auspices of "doing something". > > > > It would more be like disclaimer telling their customers that if they > issue a SHA-1 cert after 2016-01-01 from their SHA-256 TCSC, it probably > won't work in a lot of browsers, please for your own protection, issue > only SHA-256 or stronger certs. So the incentive for the issuing CA is > to minimize tech support calls and angry customers. > > If the CA fails to inform their customers, the customer will get angry, > but the WebPKI will be unaffected. > > > Similarly, the market incentives are such that the warning will ultimately > > be ineffective for some segment of the population. Chrome's own warnings > > with SHA-1 - warnings that CAs felt were unquestionably 'too much' - still > > showed how many sites were ill-prepared for the SHA-1 breakage (read: many). > > > > Warnings feel good, but they don't do (enough) good. So the calculus comes > > down to those making the decision - Gerv and Kathleen on behalf of Mozilla, > > or folks like Andrew and I on behalf of Google - of whether or not to > > 'break' sites that worked yesterday, and which won't work tomorrow. When > > that breakage is low, it can fit within the acceptable tolerances - > > https://www.chromium.org/blink/removing-features and > > https://www.chromium.org/blink try to spell out how we do this in the Web > > Platform - but too large, and it becomes a game of chicken. > > > > So even though you say "it would be foolish," every bit of history suggests > > it will be done. And since we know this, we also have to consider what the > > impact will be afterwards. Breaking a ton of sites is something no browser > > manufacturer - or its employees, more specifically - wake up each morning > > and say "Gee, I wonder what I can break today!", and so we shouldn't > > trivialize the significant risk it would impose. > > > > One could also add a requirement that certain occasional messages, > prewritten by the CAB/F shall be forwarded verbatim to all TCSC holders. > For example a notice about the SHA-1 deprecation (historic example). > > > > >> * With respect to initiatives such as CT-logging, properly written > >> certificate validation code should simply not impose this below TCSCs. > >> > > > > "properly written"? What makes it properly written? It just means what you > > want as the new policy. > > > > "Properly written" = "Written to take into account the new relaxed > policy proposed by Matthew (not me), if and when adopted", I have argued > above why I think this should be technically doable. > > Matthew (not I) have argued why such a policy might be good. I have > merely provided technical input as to how to handle certain > implementation issues. > > > > >> With the above and similar measures (mostly) already in place, I see no > >> good reason to subject TCSCs to any of the administrative burdens > >> imposed on public SubCAs. > > > > > > While I hope I've laid them out for you in a way that can convince you, I > > also suspect that the substance will be disregarded because of the source. > > That said, the risk of breaking something is not done lightly, and while > > you may feel it's the site operators fault - and perhaps even rightfully so > > - the cost is not born by the site operator (even when users can't get to > > their site!) or the CA (who didn't warn "hard enough"), but by the user. > > And systems that externalize cost onto the end user are not good systems. > > > > Believe me, I have read the substance of your messages, and have tried > to respond with intelligent arguments, and/or acceptance where > applicable. > > > > 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
