On Mon, Mar 30, 2015 at 11:34:40AM -0400, Richard Barnes wrote:
> The underlying issue here is that CNNIC, apparently deliberately, violated
> the BRs, Mozilla policy, and its own CPS by issuing an intermediate without
> proper vetting. For me, the most troubling aspect of this is that CNNIC
> violated their own CPS -- the covenant they make with the community for how
> they will behave, and the basis for all the decisions that we make about
> whether to trust them.
I agree with you wholeheartedly on this point. However, given that CNNIC
felt it appropriate to violate their CPS with regards to an intermediate CA
certificate, I don't see that there's any greater reason to trust their
adherence to their CPS in any other aspect. Thus, I'm not not keen on
allowing them to issue *any* further trusted certificates.
> Option (E) is technically infeasible, for the reasons that Ryan noted.
There were two sub-parts to option (E) -- (1) keep the root, but disallow
further issuance, or (2) obtain a list of issued end-entity certs from CNNIC
and whitelist those. Ryan described how E1 is infeasible, but did state
that E2 was possible (assuming CNNIC cooperation). I assume it would be
some amount of work to implement E2, however. Absent considerations of the cost
of implementation, E2 is the best option I've seen (or thought of) so far.
> As a compromise, however, I would be willing to add the CNNIC intermediates
> to the Mozilla root list (F). (Ideally, with an additional path length
> constraint, set to zero.) This would enable CNNIC to continue issuing
> end-entity certificates, without the possibility of adding intermediates.
> Since CNNIC's policy regarding intermediates is the immediate issue here,
> this seems like a reasonable compromise. However, these intermediate
> certificates should not be admitted indefinitely. Rather, we should plan
> to remove them after a fixed time (say 6 months) or after CNNIC's
> re-application is resolved, whichever comes first.
Time-limited intermediate inclusion could be a workable compromise. It
would give CNNIC an opportunity to communicate with all of the customers who
have been issued certificates derived from their root to advise them that
they will need to seek a new certificate provider in order to maintain a
trusted status after date (X). Whether CNNIC cares enough about its
customers to do that is another matter. Third parties, using CT and/or
SSL census data, could also attempt to raise the issue with those who would
be impacted, however I'm dubious whether that would have any meaningful
effect.
(As a side-note, and taking a leaf from CT's book: TLS should, if it doesn't
already, support the presentation of multiple certificates, and browsers
could start requiring the presentation of multiple certificates to get, to
start with, EV treatment. That would allow browsers to untrust a
misbehaving CA without the massive impact that happens now. Just a
thought.)
- Matt
--
"[Perl] combines all the worst aspects of C and Lisp: a billion different
sublanguages in one monolithic executable. It combines the power of C with
the readability of PostScript."
-- Jamie Zawinski
_______________________________________________
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy
