[cabfpub] Assuring trust in website identities

[Ryan Sleevi]

On Fri, Feb 24, 2017 at 8:40 PM, Peter Bowen via Public <public at cabforum.org
> wrote:
>
> Do others agree that this path makes sense in order to provide high
> assurance of website identity?
>

In past discussions, many CA members have rightly pointed out the the
Baseline Requirements' Effective Date was non-binding, which is why so many
of them failed to incorporate the many useful security improvements for
some time. As best I can tell, based on the excellent public CA
Communications that Kathleen Wilson of Mozilla did (at
https://wiki.mozilla.org/CA:Communications ), the set of currently trusted
CAs did not fully comply with these requirements until mid-2013. Perhaps
2013-07-01T00:00:00Z would make a more suitable date to get the level of
assurance so desired.

That said, I do worry that even with 2013-07-01T00:00:00Z may be too far
back. The CA/Browser Forum recognized, since the first version of the
Baseline Requirements, that 39 months represents the upper limit as to how
long it is safe to rely on such organizational or individual information,
as reflected in Section 4.2.1. Thus, I would suggest that if our goal is to
adequately distinguish whether a certificate is legitimate OV/IV, we should
apply that same standard. I do like the symbolic cleanliness of the five
year anniversary of OV/IV, so might I suggest that we keep that, work
backwards 39 months, my calculations suggest this would be to revoke those
certificates with a notBefore of 2014-04-01.

It seems also prudent that, if our goal is to ensure that the corpus of CA
issued certificates which otherwise are not compliant with OV, we should
also consider revoking any of those certificates issued by CAs that have
received a qualified audit, as the presence of a qualified audit is an
indicator that the process and standards are not at the level expected.
Given that auditors do not provide incident reports, nor do they analyze
the scope of the misisuance in producing qualified audit reports, it would
seem the ecosystem would only truly get that level of assurance if we also
flush those certificates out. I'd be happy to work on a list of such CAs
whose certificates should be revoked due to operational or validation
failures, so that we can truly move the ecosystem forward.

Even with all of these wonderful steps - revoking such certificates with a
notBefore of 2014-04-01, revoking such certificates from any CA who has
received a qualified audit or had validation issues - I believe we might
still have trouble distinguishing whether or not those certificates comply
with the OV/IV portions of the Guidelines, because as presently worded, the
Guidelines only apply to those 'intended' to be used for this purpose, and
some CAs may have issued such certificates under other policies, as they
did not intend for these certificates to be used this way.

Thus, in the effort of promoting a cleaner system, might I suggest we
include in the set of certificates to revoke any certificate that does not
assert either 2.23.140.1.1, 2.23.140.1.2.2, 2.23.140.1.2.3? This would help
ensure only those that were truly intended for this level of assurance will
remain trusted.

To the extent possible, I'm sure there's openness from the Browser
community to help ensure such certificates are adequately revoked, by
ensuring such software rejects certificates that meet any of the criteria.
Of course, for those TLS clients that lack the flexibility to update, and
thus are forced to only support revocation, I think revoking these
certificates also sounds like a good idea.

I am concerned about what impact this might have on CAs' CRL sizes, which
could be a quite unfortunate side-effect. Perhaps this Ballot should be
accompanied with a requirement that if the CA has any such certificates
(that would be revoked), then they MUST ensure all new certificates after
that date utilize a different CRL Distribution Point. This will help ensure
that new certificates do not pay for past mistakes, by ensuring those that
check revocation do not have to encounter CRLs as we see today, easily
multi-megabyte.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/public/attachments/20170224/0521a068/attachment-0001.html>