[cabfpub] CT and OCSP Stapling

[Ben Laurie]

On 17 October 2012 15:16, Rob Stradling <rob.stradling at comodo.com> wrote:
> On 17/10/12 13:55, Ben Laurie wrote:
> <snip>
>
>>> 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.
>
>
> Huh?  The body of the OCSP response?!?
>
> Wouldn't it be far, far simpler to allocate an OID for a new X.509v3
> Extension, which will contain a CT proof?  Then CT proofs can be embedded
> into Certificates and OCSP Responses in exactly the same way.

That's what I meant, I expressed myself poorly :-)

>>> 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.
>
>
> I think by "this signature" you're referring to the signature on the OCSP
> Response.  As you say, this signature isn't required for verifying the CT
> proof.  However, this signature is required for verifying the OCSP Response!
>
> Please don't break OCSP (any more than it is already broken)!  CT will only
> be effective if revocation is also effective.

Yes, I realise now that I've read the RFC a bit more carefully that I
am unlikely to be able to avoid this signature :-)

>> If we also said that the OCSP response could be signed by anyone for this
>> particular response,
>
>
> ...then clients would reject the OCSP Response (unless they happen to have
> "anyone" configured as an RFC2560 Trusted Responder, which is very
> unlikely).  The whole idea of adding CT proofs to OCSP Responses is to make
> it work with legacy stuff that supports OCSP Stapling but does not support
> RFC5878.
>
>
>> then OCSP stapling could be used even with CAs that don't support it.
>
>
> CAs cannot produce unstapleable OCSP Responses, so I'm not sure what you
> mean here.

I meant "don't support OCSP" ... but never mind, I will drop that line
of thinking.