Re: [therightkey] [cabfpub] Updated Certificate Transparency + Extended Validation plan

[Ryan Sleevi <[e-mail]>]

On Tue, Feb 4, 2014 at 12:50 PM, Adam Langley <[e-mail]> wrote:

> On Tue, Feb 4, 2014 at 3:37 PM, Jeremy Rowley
> <[e-mail]> wrote:
> > Doesn't that simply require the cert user to either start using OCSP
> with an
> > embedded certificate or getting a new certificate from the user?
>
> If the certificate was used with OCSP stapling, the CA had a
> reasonably short OCSP validity window and the CA could update the SCT
> in the OCSP response quickly then that would solve the problem.
>
> However, for the purposes of this spec I don't think we said anything
> about that because of the complexity. Having multiple SCTs is clearly
> ok and that kept things simple.
>
> > Plus, under the current plan, the site doesn't go dark. Instead, their
> EV cert isn't recognized as an EV certificate.
>
> For EV certificates the problem is greatly reduced. But EV
> certificates are just a trial for doing it universally and we have the
> end state in mind.


Also, EV has the added benefit of recommending/requiring (depending on
which doc) fresh revocation checks. As such, CAs that feel that multiple
logs are too onerous can benefit from the OCSP delivery method. Failing to
obtain fresh revocation information can already cause a loss of EV UI, so
including an SCT should be a much less onerous cross to bear.

It also allows for issuance patterns other than pre-certs.

Of course, it means that any sites purchasing certificates from such a CA
support OCSP stapling.