[cabfpub] Ballot 106 - Extended deadline to prohibit OCSP good response for non-issued certificates

Stephen Davidson S.Davidson at quovadisglobal.com
Thu Jul 25 20:06:08 UTC 2013


A side effect of this conversation has been to highlight the rapidly
changing playing field as to how browsers validate certificates.

These loosely understood changes in validation may affect the Relying Party
Agreements (RPAs) used by every CA.  I encourage the lawyers in the group to
chime in here, but by my understanding the RPAs allow "reasonable reliance"
on a certificate by an end user if they:

.        Verified that the Digital Signature and/or Certificate were valid
at the time of reliance by checking the most reliable and current method of
checking certificate status (current CRL or OCSP); 
.        Complied with User Notices for the Certificate; and relied on the
Certificate to engage in legally permitted conduct under circumstances where
reliance would be considered reasonable yadda yadda.

The question I have is whether these fast changing validation methods and
indicators really allow the user to establish reasonable reliance under the
existing legal structures?  Is the CA absolved of liability if the
validation is done through a third-party CRLset or stapling rather than
their own validation service, or if the client software indicators do not
howl like mad when a revoked cert is encountered?  Does the CA/B Forum or
some other legal entity need to take a new look at a "baseline for RPAs"
based on the new environment?

Best, Stephen



-----Original Message-----
From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On
Behalf Of Rob Stradling
Sent: Thursday, July 25, 2013 4:26 PM
To: Adam Langley
Cc: CABFPub
Subject: Re: [cabfpub] Ballot 106 - Extended deadline to prohibit OCSP good
response for non-issued certificates

Thanks Adam.  So Google are only interested in this issue because of what
you believe it indicates about the competence of each CA.  Fair enough.

On 24/07/13 16:09, Adam Langley wrote:
> On Wed, Jul 24, 2013 at 9:44 AM, Rob Stradling <rob.stradling at comodo.com>
wrote:
>> Ah, so something has changed.  Previously, you'd switched off Online 
>> OCSP lookups in all cases.
>
> I think Chris is using Mac where OCSP checks are done for EV due to 
> platform behaviours on OS X.
>
> On other platforms, a valid, current CRLSet will disable OCSP checks.
> See line 90 of
>
> http://src.chromium.org/viewvc/chrome/trunk/src/net/cert/cert_verify_p
> roc.cc?revision=211347
>
>> So IINM, Chrome today is very unlikely to use OCSP to check any EV 
>> certificate, and yet you want to remove EV indicators based on OCSP 
>> Responder behaviour?  This still puzzles me.
>
> Without hard-fail OCSP, you're quite correct that this measure is not 
> especially important. I don't believe, off hand, that it materially 
> affects Chrome security.
>
> I think you're reading Ryan's response as suggesting that we feel that 
> this measure is deeply important and that EV status is unreasonable 
> for CAs that don't implement it. I don't believe that was the 
> intention.
>
> Rather, with a "no" vote, we're saying that a year (roughly) is a 
> reasonable amount of time to implement this. CAs have to correctly 
> perform a fairly technical task. They should have the technical 
> ability, in-house, to do something like this. Some might want to buy 
> outside software in order to use that ability more efficiently but 
> that doesn't mean that they don't have to meet the Baseline.
>
> Separately, and generally, we're saying that the Baseline is important 
> and that CAs that fall below it risk measures including the removal of 
> EV status. Any actions will be proportionate, but CAs should expect to 
> meet the requirements in the Baseline.
>
>
> Cheers
>
> AGL
>

--
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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5494 bytes
Desc: not available
URL: <http://lists.cabforum.org/pipermail/public/attachments/20130725/cf7c3b90/attachment-0001.p7s>


More information about the Public mailing list