[cabfpub] CT and OCSP Stapling

Ben Laurie benl at google.com
Wed Oct 24 10:17:12 UTC 2012


On 18 October 2012 14:04, Phillip <philliph at comodo.com> wrote:
> One consequence of this approach is that it would make the OCSP 'must staple' draft a logical part of the proposed CT WG work items.

Not really - the requirement is "must show CT log signature". OCSP
stapling is one way to do so.

BTW, the latest I-D includes how to add a SCT to an OCSP response.

> On Oct 17, 2012, at 10:28 AM, Rob Stradling wrote:
>
>> Thanks Ben.  I think we're back on the same page again.  :-)
>>
>> On 17/10/12 15:22, Ben Laurie wrote:
>>> 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.
>>>
>>
>> --
>> Rob Stradling
>> Senior Research & Development Scientist
>> COMODO - Creating Trust Online
>> Office Tel: +44.(0)1274.730505
>> Office Fax: +44.(0)1274.730909
>> www.comodo.com
>>
>> COMODO CA Limited, Registered in England No. 04058690
>> Registered Office:
>>   3rd Floor, 26 Office Village, Exchange Quay,
>>   Trafford Road, Salford, Manchester M5 3EQ
>>
>> This e-mail and any files transmitted with it are confidential and
>> intended solely for the use of the individual or entity to whom they are
>> addressed.  If you have received this email in error please notify the
>> sender by replying to the e-mail containing this attachment. Replies to
>> this email may be monitored by COMODO for operational or business
>> reasons. Whilst every endeavour is taken to ensure that e-mails are free
>> from viruses, no liability can be accepted and the recipient is
>> requested to use their own virus checking software.
>> _______________________________________________
>> Public mailing list
>> Public at cabforum.org
>> https://cabforum.org/mailman/listinfo/public
>



More information about the Public mailing list