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

王文正 wcwang at cht.com.tw
Mon Oct 27 09:11:14 MST 2014


Thomas,

If a CRL with lifetime of several hours or several days is acceptable, I do not see why a 'nocheck' OCSP responder's certificate is not acceptable. Their security level are just equal.

By issuing a short-lived OCSP responder certificate, it does not means you have to regenerate its private key. You can keep use the same key pair until you feel you have to regenerate it or your certificate policies require you to regenerate it.

Wen-Cheng Wang



-------- 原始郵件 --------
自: Thomas Kopp <thomas.kopp at luxtrust.lu>
日期:
至: 王文正 <wcwang at cht.com.tw>,public at cabforum.org,questions at cabforum.org
主旨: 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<mailto:thomas.kopp at luxtrust.lu>

LuxTrust S.A. |  IVY Building | 13-15, Parc d’activités | L-8308 Capellen | www.luxtrust.lu<http://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.
[Email_banner_CSS_like]<https://www.luxtrust.lu/>

From: 王文正 [mailto: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<mailto:thomas.kopp at luxtrust.lu>>
日期:
至: public at cabforum.org,questions at cabforum.org<mailto: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<mailto:thomas.kopp at luxtrust.lu>

LuxTrust S.A. |  IVY Building | 13-15, Parc d’activités | L-8308 Capellen | www.luxtrust.lu<http://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.
[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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://cabforum.org/pipermail/public/attachments/20141027/ec98b998/attachment-0001.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.jpg
Type: image/jpeg
Size: 7510 bytes
Desc: image001.jpg
Url : https://cabforum.org/pipermail/public/attachments/20141027/ec98b998/attachment-0003.jpg 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.jpg
Type: image/jpeg
Size: 7510 bytes
Desc: image001.jpg
Url : https://cabforum.org/pipermail/public/attachments/20141027/ec98b998/attachment-0004.jpg 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.jpg
Type: image/jpeg
Size: 7510 bytes
Desc: image001.jpg
Url : https://cabforum.org/pipermail/public/attachments/20141027/ec98b998/attachment-0005.jpg 


More information about the Public mailing list