Re: [TLS] OCSP must staple

[Brian Smith <[e-mail]>]

On Thu, Jun 5, 2014 at 12:51 PM, Michael StJohns <[e-mail]>
wrote:

> On 6/5/2014 3:12 PM, Brian Smith wrote:
>
>> Is it really significantly easier for CAs to add new certificate policies
>> compared to adding new certificate extensions? I could see how that could
>> be the case, but I think it would be good to hear from CAs about this.
>>
>
> Mostly the "put a policy object in the ca certificate" reduces to
> "configure the text string of the OIDs you want to include".
> https://www.openssl.org/docs/apps/x509v3_config.html#Certificate_Policies_
> for example.
>
> The certificate policy extension is pretty well formed, which means that
> its pretty easy to specify in configuration language (e.g. xml,
> label=value) what you want to be included rather than having to go back and
> add new ASN1 encode/decode/translate to and from string logic.  Things like
> Dogtag and EJBCA support it via a gui


I have researched some of the pros and cons of Michael's policy-based
approach. I also implemented it in a private copy of mozilla::pkix and
Firefox. In particular, I made it so:

* When the extension is present in the end-entity certificate, that a valid
"Good" OCSP response must be provided in the TLS handshake,
* There will never be any fallback to OCSP fetching or CRLs or cache
lookups when the end-entity certificate has the must-staple policy.
However, additional certificate trust information (blacklists/CRLSet) are
still consulted.
* The modified mozilla::pkix will never build a path from an end-entity
certificate or sub-CA to a higher-level CA certificate where the
higher-level CA certificate has the Must-Staple policy but the end-entity
or lower-level sub-CA certificate doesn't have the Must-staple policy.
* My modified mozilla::pkix enforces a maximum OCSP response lifetime of 2
days + slop (1 day) = 3 days if Must-Staple is present, instead of 10 days.

The good news:
* In mozilla::pkix and Firefox, it is just as easy to implement Machael's
policy-based approach as it would be to implement the approach outlined in
the draft.
* As Michael said, most if not all CA software already supports custom
certificate policies, so there is *no* new code required on the CA side for
Machael's approach. This is a significant advantage, especially because
there are a lot of companies that have purchased sub-CA certificates that
chain to publicly-trusted CAs, which use closed-source software (e.g.
Microsoft's). Basically, with Michael's approach, everybody would be able
to use Must-Staple straight away, if they want to, without writing code.

The bad news:
* TLS intercepting proxies cause trouble. In particular, some (if not all)
versions of Microsoft Threat Management Gateway forge their fake
certificates by copying the certificate policies from the original
certificate that they are trying to impersonate. Yet, Microsoft TMG does
not support OCSP stapling or in fact any kind of OCSP. Consequently, it
will copy the Must-Staple policy into the forged certificate but it won't
staple a response. I imagine other TLS intercepting proxies will do the
same.
* It is unclear what TLS intercepting proxies do with certificate
extensions that they don't understand. I would guess that some copy those
extensions into their forged certificates and others do not.

The OK news:
* From what I've found, Microsoft TMG forges certificates that are very
short lived (24hrs). Thus, if we make an exception that short-lived
certificates (<= 48 hours) with the Must-Staple feature do not need to have
a stapled OCSP response even with Must-Staple, we can probably avoid a lot
of the issues with TLS intercepting proxies, regardless of how the
Must-Staple feature is encoded in the certificate.

Thus, for ease-of-deployment reasons, I prefer Michael's policy-based
approach + the short-lived certificate exception over the approach in the
draft that uses a new extension. Regardless of which of those two
approaches is taken, we'll need to do a lot of interop testing with various
kinds of TLS intercepting proxies.

Cheers,
Brian