[cabfpub] CT and OCSP Stapling

[Ben Laurie]

On 17 October 2012 13:52, Ben Laurie <benl at google.com> wrote:
> On 17 October 2012 12:57, Ben Laurie <benl at google.com> wrote:
>> On 17 October 2012 12:35, Rob Stradling <rob.stradling at comodo.com> wrote:
>>> Adam, at the New York F2F recently, you mentioned that you and Ben didn't
>>> like the idea of embedding CT proofs in CA-provided OCSP Responses.  Your
>>> view was that this would "weaken CT".  If you did explain what you meant by
>>> this, I'm afraid I've forgotten what you said.  So...
>>>
>>> Please would you or Ben explain exactly why you think it would "weaken CT"?
>>>
>>> (IMHO, CT will only work if clients hard-fail on absence of a CT proof, so
>>> it makes no difference what distribution channel is used to get a CT proof
>>> to a client.  I don't see how using the OCSP Stapling TLS extension would be
>>> any "weaker" than using the RFC5878 TLS extension).
>>
>> This is exactly it - there may have been some confusion here. We're
>> perfectly happy to use OCSP Stapling with CT.
>>
>> I think Adam thought you were talking about using standard OCSP, which
>> as you know won't work because of unreliability, which means it can't
>> be hard-fail, which defeats the purpose of CT.
>
> BTW, as far as I can see all we would need to do to add a CT response
> to OCSP is to allocate an OID and make the body the SCT.
>
> I can add that to the I-D now :-)

One thing I'd note is that OCSP requires the response is signed, but
since the SCT is already signed, this signature is not needed. If we
also said that the OCSP response could be signed by anyone for this
particular response, then OCSP stapling could be used even with CAs
that don't support it.