[cabfpub] CT and OCSP Stapling

[Phillip]

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.



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