Clarification related to the scope of Mozilla Root Store Policy

[Mohamed Abdelshahid]

Dear Mozilla team,

I have a clarification that I need to discuss with you please.

We have a 2-level CA hierarchy where the Root CA sits at the top level while Issuing CAs comes at the second level.

As part of the regular issuing CA re-key, we are going to add technical constraints to all issuing CAs in order to have separate Issuer CAs for Server Authentication, Code Signing, and Time Stamping uses. That will be reflected to the Issuing CAs’ certificates as follows:

Issuing CA	EKU
Devices Certification Authority	serverAuth clientAuth
Corporate Certification Authority	clientAuth Microsoft Document Signing (1.3.6.1.4.1.311.10.3.12)
Code Signing Certification Authority	codeSigning
Timestamping Certification Authority	timeStamping

 

According to our reading of Mozilla policy section 1.1, and given the above constraints; we assume that the Corporate Certification Authority and its underlying certificates (EE certificates) don’t fall under Mozilla’s scope. Could you please confirm?

Kindly note that the rationale behind our question is that there cases where we will not be able to have an EKU in EE certificates issued by the Corporate Certification Authority when the purpose/use of certificate is not matching with any of the standard EKUs.

 

Thank you in advance.

Kind Regards,

Mohamed Abdelshahid محمد عبدالشهيد Principal PKI Consultant

T: +97144150400 P.O. Box 36996 M: +971566824278 Dubai, UAE E: mohamed.a...@desc.gov.ae www.desc.gov.ae

Disclaimer: This email and any files transmitted with it may be confidential and contain privileged or copyright information. If you are not the intended recipient you must not copy, distribute or use this email or the information contained in it for any purpose other than to notify us of the receipt thereof, if you have received this message in error, please notify the sender immediately, and delete this email from your system. Please note that e-mails are susceptible to change, the sender shall not be liable for the improper or incomplete transmission of the information contained in this communication, nor for any delay in its receipt or damage to your system. The sender does not guarantee that this material is free from viruses or any other defects although due care has been taken to minimize the risk. Please consider your environmental responsibility before printing this e-mail. إخلاء المسؤولية: إن المعلومات الواردة في هذا البريد الإلكتروني وأي ملفات مرفقة به هي معلومات خاصة بالمرسل إليه أو المتعامل، وقد تحتوي على معلومات سرية أو مواد محمية. إن لم تكن أحد المعنيين باستلام هذا البريد الإكتروني، فيمنع منعاً باتاً نسخ أو توزيع أو اتخاذ إجراء بالاعتماد على المعلومات الواردة فيه، وإن كان قد وصلك عن طريق الخطأ، فالرجاء المبادرة فوراً بإشعار المرسل بذلك، وحذف البريد من جهازك. يرجى العلم بأن البريد الإلكتروني هو عنصر قابل للتغيير؛ ولذا لن يكون المُرسل خاضعاً للمساءلة حال انتقال المعلومات في هذا البريد بصورة غير ملائمة أو منتقصة، ولا تجاه أي تأخير في وصوله، أو تجاه أي عطل في جهازك. إن مركز دبي للأمن الإلكتروني لا يتحمل مسؤولية أي أضرار ناتجة عن أي فيروس أو برنامج قد يرسل بواسطة هذا البريد الإلكتروني.   من فضلك خذ بعين الاعتبار مسؤوليتك تجاه البيئة قبل طباعة هذا البريد الإلكتروني.

[Ben Wilson]

Dear Mohamed,

You have asked about whether an intermediate CA certificate with an EKU constraint of clientAuth and document signing (and no EKU for email security or serverAuth), would pull it out of scope for Mozilla, even if the end entity certificates do not have a standard EKU. I think it would be out of scope as far as Mozilla is concerned about the websites trust bit and the email trust bit. I think we would still want to see the intermediate CA certificate disclosed in the CCADB, and the sha2 hash would need to be included in the Webtrust v 2.2.1 standard audit. Also, I think it would be highly preferable to include some EKU in the end entity certificates (rather than having no EKU).

Does anyone see problems with this approach?

Thanks,

Ben

--
You received this message because you are subscribed to the Google Groups "dev-secur...@mozilla.org" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dev-security-po...@mozilla.org.
To view this discussion on the web visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/55dfa2e791e54c0995ddd7b13f14f610%40desc.gov.ae.

[Chema Lopez]

Hi Ben.

I'm align with your point of view and Mohamed, I strongly recommend the proper use of EKU in the EE certificate since CA constraints is an approach made from the web browsers manufacturers point-of-view but you should not assume that the rest of relying parties will interpret the CA constraints accordingly with the web browsers definition.

BR,

Chema López

Director Área Innovación, Cumplimiento y Tecnología

+34 666 429 224

                                                  

Barcelona  Av. Torre Blanca 57, Edif. Esadecreapolis, Local 3B6 - 08173 Sant Cugat del Vallès | +34 934 774 245

Madrid  C/ Velázquez 59, 1º Ctro-Izda. - 28001 Madrid | +34 915 762 181

www.firmaprofesional.com

El contenido de este correo electrónico y de sus anexos es confidencial. Si usted recibe este mensaje por error, debe saber que está prohibido hacer uso, divulgación y/o copia del mismo. En tal caso le agradeceríamos que advierta de inmediato a su remitente y que proceda a destruir el mensaje.

 

Le informamos que, cumpliendo la normativa en materia de protección de datos, FIRMAPROFESIONAL tratará sus datos con la finalidad de garantizar las relaciones con la empresa, entidad u organización a la que usted representa o en la que trabaja y por el período que dure dicha relación. Podrá ejercer sus derechos de acceso, rectificación, supresión, limitación, portabilidad y oposición al tratamiento ante el Responsable: FIRMAPROFESIONAL, S.A., Av. Torre Blanca, 57, local 3B6 (Edificio Esadecreapolis), 08173 Sant Cugat del Vallès (Barcelona), o bien mediante correo electrónico a: rg...@firmaprofesional.com, en cualquier caso adjuntando una copia de su D.N.I. o documento equivalente. Asimismo, podrá formular reclamaciones ante la Agencia Española de Protección de Datos. Para más información puede consultar nuestra política de privacidad.

To view this discussion on the web visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/CA%2B1gtaajNVxFxo-pfT--Gs1ydspDMvFoT9FSrrMTQhtH2JwkBw%40mail.gmail.com.

[Mohamed Abdelshahid]

Thank you Ben and Chema, I definitely agree with your view on having proper EKUs in all leaf certificates. 

However, I would appreciate your advice on situations where a certificate is meant to be used for document signing or transaction signing (e.g. signature verification response signing), in which case what would be the right EKU? even the Document Signing EKU=1.3.6.1.4.1.311.10.3.12 is actually used for signing documents within MS Office and it is not required for other document signing uses. That was the main reason behind my clarification really. 

Kind Regards,

---

From: Chema Lopez <clo...@firmaprofesional.com>
Sent: Tuesday, February 8, 2022 12:14 PM
To: Ben Wilson
Cc: Mohamed Abdelshahid; dev-secur...@mozilla.org
Subject: Re: Clarification related to the scope of Mozilla Root Store Policy

 

Hi Ben.

I'm align with your point of view and Mohamed, I strongly recommend the proper use of EKU in the EE certificate since CA constraints is an approach made from the web browsers manufacturers point-of-view but you should not assume that the rest of relying parties will interpret the CA constraints accordingly with the web browsers definition.

BR,

Chema López

Director Área Innovación, Cumplimiento y Tecnología

+34 666 429 224

                                                  

Barcelona  Av. Torre Blanca 57, Edif. Esadecreapolis, Local 3B6 - 08173 Sant Cugat del Vallès | +34 934 774 245

Madrid  C/ Velázquez 59, 1º Ctro-Izda. - 28001 Madrid | +34 915 762 181

www.firmaprofesional.com

Home - Firmaprofesional www.firmaprofesional.com Desde Firmaprofesional ayudamos a las organizaciones a alcanzar su máximo potencial a través de los más altos estándares de protección digital.

[Ben Wilson]

Dear Mohamed,

If the certificates will be for document signing, then you would need to put your document-signing EKUs in the intermediate CA certificate and in the certificates for end entities. Those EKUs would need to be arranged with other software providers who process the digital signatures on signed documents, such as Microsoft, Adobe, etc.

Ben