[cabfpub] [cabfquest] Question concerning CAB Forum OCSP Requirments

[Ryan Sleevi]

Because, as explained in the prior email, a CA that chose to not use
nocheck, as you advocate, would be creating clear performance issues for
browsers and, in many subtle ways, could create misconfigurations that
would prevent revocation checking from working.

As such, the Forum has chosen to remove the flexibility of allowing CAs to
choose between the options, since nocheck can have equivalent security, and
without the performance and correctness risks.
On Oct 28, 2014 2:41 AM, "Thomas Kopp" <thomas.kopp at luxtrust.lu> wrote:

>  Dear Ryan,
>
>
>
> Thanks for your explanation.
>
>
>
> However, we do understand why does CAB Forum imposes the “nocheck” for an
> authorized responder approach instead of leaving it at the CA’s discretion,
> as to whether they prefer covering OCSP responder certificates by a CRL or
> not?
>
>
>
> Bescht Gréiss, meilleures salutations, mit freundlichen Grüßen, with best
> regards,
>
>
>
> *Thomas KOPP *
>
> Head of Information Technologies
>
> P: +352 26 68 15-574 - M: +352 621 229 316 - F: +352 26 68 15-789 – E:
> thomas.kopp at luxtrust.lu
>
>
> LuxTrust S.A. |  IVY Building | 13-15, Parc d’activités | L-8308 Capellen
> | www.luxtrust.lu
>
>
>
>
>
> The information in this e-mail and any attachment is confidential and for
> use by the addressee only. Access to this e-mail by anyone else is not
> authorized. If you are not the intended recipient, please inform the sender
> and erase all copies of it from your system. Internet communications are by
> default not secure. LuxTrust S.A. cannot guarantee the integrity and origin
> of e-mails unless they have been properly digitally signed. Confidentiality
> of e-mails can only be guaranteed if they are encrypted properly using a
> secure digital certificate.LuxTrust S.A. takes precautions to ensure that
> e-mails are scanned for viruses but cannot accept liability for any damage
> sustained as a result of software viruses.
>
> [image: Email_banner_CSS_like] <https://www.luxtrust.lu/>
>
>
>
> *From:* Ryan Sleevi [mailto:sleevi at google.com]
> *Sent:* Dënschdeg 28 Oktober 2014 10:21
> *To:* Thomas Kopp
> *Cc:* questions at cabforum.org; CABFPub; 王文正; Rick Andrews
> *Subject:* Re: [cabfquest] Question concerning CAB Forum OCSP Requirments
>
>
>
> Thomas,
>
> As has been explained by several CAs, it is not a misinterpretation,
> because there is not an intrinsic security issue. Yes, the pkix-nocheck
> prevents the responder from being revoked, but as has already been
> discussed at length, that is trivially mitigated.
>
> More importantly is the obvious performance AND correctness of a client
> that encounters a responder WITHOUT such an extension. For performance, if
> the responder certificate also has to be checked for revocation, either it
> uses a different delegated responder (needlessly wasteful of data), it uses
> the original issuing CAs cert (defeating the purpose and security benefits
> of a delegated responder), or it requires the client fetch the issuer's
> CRL, which defeats the point of using OCSP to begin with (performance over
> large CRLs).
>
> Now, even if you don't value performance (which the browsers and the Forum
> do and did when crafting these requirements), you could equally argue from
> the point of view of correctness. At both the time of the original
> requirement being written and today, there are still several notable
> libraries that, if encountering misconfigured OCSP - an all too common
> problem with CAs, and for which auditors are either ignoring or not
> examining - then revocation checking can be silently disabled even when
> requested. Systems that don't use nocheck - that is, enterprise systems,
> since BR-compliant CAs MUST use it - all to commonly create cycles in their
> revocation paths that prevents clients from validating the response.
>
> It is a mischaracterization to suggest that nocheck is inherently insecure
> - it merely trades one basis of security (CRLs for responders, which an
> attacker can replay for a prolonged window) or a different, equivalent one
> (certificate validity, offering an equivalent window as a CRL).
>
> Hopefully this restatement of what has been said helps shed light on the
> clear performance and correctness wins from nocheck, as well as helps
> explain why requiring it is not, as suggested, an fundamental security
> issue.
>
> On Oct 28, 2014 2:06 AM, "Thomas Kopp" <thomas.kopp at luxtrust.lu> wrote:
>
> Dear Rick,
>
>
>
> This was not my point. My question was referring to the CAB Forum
> requirements, which stipulate …
>
>
>
> *13.2.5 OCSP Signing*
>
> OCSP responses MUST conform to RFC2560 and/or RFC5019. OCSP responses MUST
> either:
>
> 1. Be signed by the CA that issued the Certificates whose revocation
> status is being checked, or
>
> 2. Be signed by an OCSP Responder whose Certificate is signed by the CA
> that issued the Certificate whose
>
> revocation status is being checked.
>
> In the latter case, the OCSP signing Certificate MUST contain an extension
> of type id-pkix-ocsp-nocheck, as
>
> defined by RFC2560.
>
>
>
> Unfortunately, I’m still waiting for a reasonable clarification and a
> valuable motivation to justify the security issue resulting from the above
> requirement that obviously over- and miss-interprets the respective RFC.
>
>
>
> I highlight that status checking of our PKI infrastructure perfectly works
> for ALL certificates in a chain up to the self-signed root and in
> particular for the OCSP responder certificate. Furthermore, we do not need
> the id-pkix-ocsp-nocheck extension, although we use an authorized
> responder. As a consequence, we do not understand why CAB Forum imposes to
> use approaches which are technically not necessary and which additionally
> lower security.
>
>
>
> Bescht Gréiss, meilleures salutations, mit freundlichen Grüßen, with best
> regards,
>
>
>
> *Thomas KOPP *
>
> Head of Information Technologies
>
> P: +352 26 68 15-574 - M: +352 621 229 316 - F: +352 26 68 15-789 – E:
> thomas.kopp at luxtrust.lu
>
>
> LuxTrust S.A. |  IVY Building | 13-15, Parc d’activités | L-8308 Capellen
> | www.luxtrust.lu
>
>
>
>
>
> The information in this e-mail and any attachment is confidential and for
> use by the addressee only. Access to this e-mail by anyone else is not
> authorized. If you are not the intended recipient, please inform the sender
> and erase all copies of it from your system. Internet communications are by
> default not secure. LuxTrust S.A. cannot guarantee the integrity and origin
> of e-mails unless they have been properly digitally signed. Confidentiality
> of e-mails can only be guaranteed if they are encrypted properly using a
> secure digital certificate.LuxTrust S.A. takes precautions to ensure that
> e-mails are scanned for viruses but cannot accept liability for any damage
> sustained as a result of software viruses.
>
> [image: Email_banner_CSS_like] <https://www.luxtrust.lu/>
>
>
>
> *From:* Rick Andrews [mailto:Rick_Andrews at symantec.com]
> *Sent:* Méindeg 27 Oktober 2014 21:51
> *To:* Thomas Kopp; 王文正; public at cabforum.org; questions at cabforum.org
> *Subject:* RE: [cabfquest] Question concerning CAB Forum OCSP Requirments
>
>
>
> Thomas,
>
>
>
> The paragraph you quoted:
>
>
>
> A CA may specify that an OCSP client can trust a responder for the
>
>      lifetime of the responder's certificate.  The CA does so by
>
>      including the extension id-pkix-ocsp-nocheck.  This SHOULD be a
>
>      non-critical extension.  The value of the extension SHALL be NULL.
>
>      CAs issuing such a certificate should realize that a compromise of
>
>      the responder's key is as serious as the compromise of a CA key
>
>      used to sign CRLs, at least for the validity period of this
>
>      certificate….
>
>
>
> does not **require** the CA to use id-pkix-ocsp-nocheck. It starts with
> “A CA **may** specify…” You don’t have to use it.
>
>
>
> -Rick
>
>
>
> *From:* questions-bounces at cabforum.org [
> mailto:questions-bounces at cabforum.org <questions-bounces at cabforum.org>] *On
> Behalf Of *Thomas Kopp
> *Sent:* Monday, October 27, 2014 8:12 AM
> *To:* 王文正; public at cabforum.org; questions at cabforum.org
> *Subject:* Re: [cabfquest] Question concerning CAB Forum OCSP Requirments
>
>
>
> Dear Wen-Cheng,
>
>
>
> We have well understood the wording of the RFC. However, our goal is to
> completely avoid issuing responder certificates containing the
> id-pkix-ocsp-nocheck extension because even with a short life time of a
> responder certificate we consider such an approach as an unnecessary
> lowering of security.
>
>
>
> In addition, I’m not sure whether you are aware what issuance of an OCSP
> responder certificates within hours means in practice. Such a rule seems a
> bit far away from reality because it requires key ceremonies charging a
> couple responsible people for several hours.
>
>
>
> Finally, our question concerning the motivation behind the requirement has
> not been answered yet.
>
>
>
> Bescht Gréiss, meilleures salutations, mit freundlichen Grüßen, with best
> regards,
>
>
>
> *Thomas KOPP *
>
> Head of Information Technologies
>
> P: +352 26 68 15-574 - M: +352 621 229 316 - F: +352 26 68 15-789 – E:
> thomas.kopp at luxtrust.lu
>
>
> LuxTrust S.A. |  IVY Building | 13-15, Parc d’activités | L-8308 Capellen
> | www.luxtrust.lu
>
>
>
>
>
> The information in this e-mail and any attachment is confidential and for
> use by the addressee only. Access to this e-mail by anyone else is not
> authorized. If you are not the intended recipient, please inform the sender
> and erase all copies of it from your system. Internet communications are by
> default not secure. LuxTrust S.A. cannot guarantee the integrity and origin
> of e-mails unless they have been properly digitally signed. Confidentiality
> of e-mails can only be guaranteed if they are encrypted properly using a
> secure digital certificate.LuxTrust S.A. takes precautions to ensure that
> e-mails are scanned for viruses but cannot accept liability for any damage
> sustained as a result of software viruses.
>
> [image: Email_banner_CSS_like] <https://www.luxtrust.lu/>
>
>
>
> *From:* 王文正 [mailto:wcwang at cht.com.tw <wcwang at cht.com.tw>]
> *Sent:* Méindeg 27 Oktober 2014 15:49
> *To:* Thomas Kopp; public at cabforum.org; questions at cabforum.org
> *Subject:* Re: [cabfquest] Question concerning CAB Forum OCSP Requirments
>
>
>
> Thomas,
>
>
>
> The CAB forum does not impose any high risk on trust service providers or
> relying parties. You misquote the text, please read the full paragraph in
> the RFC.
>
>
>
> The intention of the text you highlighted in yellow color is to  remind
> CAs that it is dangrous if the lifetime of a 'nocheck' OCSP responder's
> certificate is too long. That is why the subsequent  text says "CAs may
> choose to issue this type of certificate with a very short lifetime and
> renew it frequently."
>
>
>
> The RFC is intent to tell CAs that it will be safe if they keep the
> lifetime of a 'nocheck' OCSP responder's certificate very short. In a
> typical implemention, the lifetime might range from several hours to
> several days.
>
>
>
> Wen-Cheng Wang
>
>
>
>
> -------- 原始郵件 --------
> 自： Thomas Kopp <thomas.kopp at luxtrust.lu>
> 日期：
> 至： public at cabforum.org,questions at cabforum.org
> 主旨： [cabfquest] Question concerning CAB Forum OCSP Requirments
>
> Dear all,
>
>
>
> Can you please clarify the subsequent point?
>
>
>
> In the CAB baseline requirements
> https://cabforum.org/wp-content/uploads/Baseline_Requirements_V1_1_9.pdf
> section 13.2.5 imposes the id-pkix-ocsp-nocheck extension in the case of an
> authorized responder scenario.
>
>
>
> By contrast, RFC 2560 and the successor RFC 6960 stipulate (cf. section
> 4.2.2.2.1):
>
> A CA may specify that an OCSP client can trust a responder for the
>
>      lifetime of the responder's certificate.  The CA does so by
>
>      including the extension id-pkix-ocsp-nocheck.  This SHOULD be a
>
>      non-critical extension.  The value of the extension SHALL be NULL.
>
>      CAs issuing such a certificate should realize that a compromise of
>
>      the responder's key is as serious as the compromise of a CA key
>
>      used to sign CRLs, at least for the validity period of this
>
>      certificate….
>
>
>
> How can CAB Forum impose such a requirement, which imposes to trust
> service providers such a high security risk?
>
>
>
> Please provide us a reasonable explanation for this particular
> requirement. Please note that we would not want to hear any technical
> reasoning like possible “self-looping” during OCSP responder certificate
> status checking, because such issues can perfectly be addressed without
> having to lower security.
>
>
>
> Bescht Gréiss, meilleures salutations, mit freundlichen Grüßen, with best
> regards,
>
>
>
> *Thomas KOPP *
>
> Head of Information Technologies
>
> P: +352 26 68 15-574 - M: +352 621 229 316 - F: +352 26 68 15-789 – E:
> thomas.kopp at luxtrust.lu
>
>
> LuxTrust S.A. |  IVY Building | 13-15, Parc d’activités | L-8308 Capellen
> | www.luxtrust.lu
>
>
>
>
>
> The information in this e-mail and any attachment is confidential and for
> use by the addressee only. Access to this e-mail by anyone else is not
> authorized. If you are not the intended recipient, please inform the sender
> and erase all copies of it from your system. Internet communications are by
> default not secure. LuxTrust S.A. cannot guarantee the integrity and origin
> of e-mails unless they have been properly digitally signed. Confidentiality
> of e-mails can only be guaranteed if they are encrypted properly using a
> secure digital certificate.LuxTrust S.A. takes precautions to ensure that
> e-mails are scanned for viruses but cannot accept liability for any damage
> sustained as a result of software viruses.
>
> [image: Email_banner_CSS_like] <https://www.luxtrust.lu/>
>
>
>
>
>
> *本信件可能包含中華電信股份有限公司機密資訊**,**非指定之收件者**,**請勿蒐集、處理或利用本信件**內容**,**並請銷毀此信件**. *
> *如為指定收件者**,**應確實保護郵件中本公司之營業機密及個人資料**,**不得任意傳佈或揭露**,**並應自行確認本郵件之附檔與超連結之安全性*
> *,**以共同善盡資訊安全與個資保護責任*
> *. Please be advised that this email message (including any attachments)
> contains confidential information and may be legally privileged. If you are
> not the intended recipient, please destroy this message and all attachments
> from your system and do not further collect, process, or use them. Chunghwa
> Telecom and all its subsidiaries and associated companies shall not be
> liable for the improper or incomplete transmission of the information
> contained in this email nor for any delay in its receipt or damage to your
> system. If you are the intended recipient, please protect the confidential
> and/or personal information contained in this email with due care. Any
> unauthorized use, disclosure or distribution of this message in whole or in
> part is strictly prohibited. Also, please self-inspect attachments and
> hyperlinks contained in this email to ensure the information security and
> to protect personal information.*
>
>
> _______________________________________________
> Questions mailing list
> Questions at cabforum.org
> https://cabforum.org/mailman/listinfo/questions
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://cabforum.org/pipermail/public/attachments/20141028/deb134ab/attachment-0001.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.jpg
Type: image/jpeg
Size: 7510 bytes
Desc: not available
Url : https://cabforum.org/pipermail/public/attachments/20141028/deb134ab/attachment-0001.jpg