On 23/05/2017 16:22, Ryan Sleevi wrote:
On Tue, May 23, 2017 at 9:45 AM, Jakob Bohm via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
* TCSCs can, by their existing definition, be programmatically
recognized by certificate validation code e.g. in browsers and other
clients.
In theory, true.
In practice, not even close.
Note as this is about a proposed future policy, this is about validation
code updated if and when such a policy is enacted. Current validation
code has no reason to check a non-existent policy.
What part of "Has DNS/e-mail name constraints to at least second-level
domains or TLDs longer than 3 chars", "Has DN name constraints that
limit at least O and C", "Has EKU limitations that exclude AnyEKU and
anything else problematic", "Has lifetime and other general constraints
within the limits of EE certs" AND "Has a CTS" cannot be detected
programmatically?
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)?
* 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
