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,


Mohamed Abdelshahid

محمد عبدالشهيد


Principal PKI Consultant

T:      +97144150400    P.O. Box 36996
M:      +971566824278   Dubai, UAE
E:      [email protected] 
www.desc.gov.ae<https://www.desc.gov.ae/>

[DXB-GOV-LOGO]  [DESC-LOGO]  <https://www.desc.gov.ae/>


[YOUTUBE_LOGO] <https://www.youtube.com/channel/UCJSh32jri440gAkpcoaGcSg>       
[LINKEDIN_LOGO]  <https://www.linkedin.com/company/descofficial/>       
[TWITTER_LOGO]  <https://twitter.com/DESCOfficial/>     [FB_LOGO]  
<https://www.facebook.com/DESCOfficial/>     [INSTA_LOGO]  
<https://www.instagram.com/DESCOfficial/>







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.


إخلاء المسؤولية:
إن المعلومات الواردة في هذا البريد الإلكتروني وأي ملفات مرفقة به هي معلومات 
خاصة بالمرسل إليه أو المتعامل، وقد تحتوي على معلومات سرية أو مواد محمية. إن لم 
تكن أحد المعنيين باستلام هذا البريد الإكتروني، فيمنع منعاً باتاً نسخ أو توزيع 
أو اتخاذ إجراء بالاعتماد على المعلومات الواردة فيه، وإن كان قد وصلك عن طريق 
الخطأ، فالرجاء المبادرة فوراً بإشعار المرسل بذلك، وحذف البريد من جهازك. يرجى 
العلم بأن البريد الإلكتروني هو عنصر قابل للتغيير؛ ولذا لن يكون المُرسل خاضعاً 
للمساءلة حال انتقال المعلومات في هذا البريد بصورة غير ملائمة أو منتقصة، ولا 
تجاه أي تأخير في وصوله، أو تجاه أي عطل في جهازك. إن مركز دبي للأمن الإلكتروني 
لا يتحمل مسؤولية أي أضرار ناتجة عن أي فيروس أو برنامج قد يرسل بواسطة هذا البريد 
الإلكتروني.



من فضلك خذ بعين الاعتبار مسؤوليتك تجاه البيئة قبل طباعة هذا البريد الإلكتروني.




________________________________
From: Chema Lopez <[email protected]>
Sent: Tuesday, February 8, 2022 12:14 PM
To: Ben Wilson
Cc: Mohamed Abdelshahid; [email protected]
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


[https://www.firmaprofesional.com/wp-content/uploads/2019/07/Firmaprofesional_Digital_Color_Pequeno.png]

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<http://www.firmaprofesional.com/>
[https://www.firmaprofesional.com/wp-content/uploads/2022/02/Firmasign-blanco-300x63.png]<http://www.firmaprofesional.com/>

Home - Firmaprofesional<http://www.firmaprofesional.com/>
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.



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: 
[email protected]<mailto:[email protected]>, 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<https://www.firmaprofesional.com/esp/aviso-legal>.

On Mon, 7 Feb 2022 at 21:44, Ben Wilson 
<[email protected]<mailto:[email protected]>> wrote:
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




On Tue, Feb 1, 2022 at 9:33 AM Mohamed Abdelshahid 
<[email protected]<mailto:[email protected]>> wrote:
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:      [email protected]<mailto:[email protected]> 
www.desc.gov.ae<https://www.desc.gov.ae/>

[DXB-GOV-LOGO]  [DESC-LOGO]  <https://www.desc.gov.ae/>




[YOUTUBE_LOGO] <https://www.youtube.com/channel/UCJSh32jri440gAkpcoaGcSg>       
[LINKEDIN_LOGO]  <https://www.linkedin.com/company/descofficial/>       
[TWITTER_LOGO]  <https://twitter.com/DESCOfficial/>     [FB_LOGO]  
<https://www.facebook.com/DESCOfficial/>     [INSTA_LOGO]  
<https://www.instagram.com/DESCOfficial/>








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.


إخلاء المسؤولية:
إن المعلومات الواردة في هذا البريد الإلكتروني وأي ملفات مرفقة به هي معلومات 
خاصة بالمرسل إليه أو المتعامل، وقد تحتوي على معلومات سرية أو مواد محمية. إن لم 
تكن أحد المعنيين باستلام هذا البريد الإكتروني، فيمنع منعاً باتاً نسخ أو توزيع 
أو اتخاذ إجراء بالاعتماد على المعلومات الواردة فيه، وإن كان قد وصلك عن طريق 
الخطأ، فالرجاء المبادرة فوراً بإشعار المرسل بذلك، وحذف البريد من جهازك. يرجى 
العلم بأن البريد الإلكتروني هو عنصر قابل للتغيير؛ ولذا لن يكون المُرسل خاضعاً 
للمساءلة حال انتقال المعلومات في هذا البريد بصورة غير ملائمة أو منتقصة، ولا 
تجاه أي تأخير في وصوله، أو تجاه أي عطل في جهازك. إن مركز دبي للأمن الإلكتروني 
لا يتحمل مسؤولية أي أضرار ناتجة عن أي فيروس أو برنامج قد يرسل بواسطة هذا البريد 
الإلكتروني.



من فضلك خذ بعين الاعتبار مسؤوليتك تجاه البيئة قبل طباعة هذا البريد الإلكتروني.





--
You received this message because you are subscribed to the Google Groups 
"[email protected]<mailto:[email protected]>" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to 
[email protected]<mailto:[email protected]>.
To view this discussion on the web visit 
https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/55dfa2e791e54c0995ddd7b13f14f610%40desc.gov.ae<https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/55dfa2e791e54c0995ddd7b13f14f610%40desc.gov.ae?utm_medium=email&utm_source=footer>.

--
You received this message because you are subscribed to the Google Groups 
"[email protected]<mailto:[email protected]>" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to 
[email protected]<mailto:[email protected]>.
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<https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/CA%2B1gtaajNVxFxo-pfT--Gs1ydspDMvFoT9FSrrMTQhtH2JwkBw%40mail.gmail.com?utm_medium=email&utm_source=footer>.

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

Reply via email to