[cabfpub] [cabfman] possible OCSP/CRL inconsistencies in the BR

Thu Mar 13 14:25:53 UTC 2014

No problem at all. In the public list now J

Regarding the question, what I meant is to indicate clearly in the BR. The browsers´ root programs indicate clearly but not the BRs. In annex B is indicated that only OCSP is mandatory but in the root programs is said that both are mandatory, so that´s a contradiction.

Iñigo Barreira
Responsable del Área técnica
i-barreira at izenpe.net

945067705

ERNE! Baliteke mezu honen zatiren bat edo mezu osoa legez babestuta egotea. Mezua badu bere hartzailea. Okerreko helbidera heldu bada (helbidea gaizki idatzi, transmisioak huts egin) eman abisu igorleari, korreo honi erantzuna. KONTUZ!
ATENCION! Este mensaje contiene informacion privilegiada o confidencial a la que solo tiene derecho a acceder el destinatario. Si usted lo recibe por error le agradeceriamos que no hiciera uso de la informacion y que se pusiese en contacto con el remitente.

De: Ryan Sleevi [mailto:sleevi at google.com] 
Enviado el: martes, 11 de marzo de 2014 22:12
Para: Barreira Iglesias, Iñigo
CC: 'management at cabforum.org' (management at cabforum.org)
Asunto: Re: [cabfman] possible OCSP/CRL inconsistencies in the BR

1) Should this be on the public list? Am I missing some context?

2) Shouldn't you reach out to the root program maintainers?

Speaking for Google, we strongly value having CRLs - primarily for intermediates more than EE certs - and as you note, it's REQUIRED by the Mozilla policy. I think a CA that didn't support CRLs would not necessarily have the same security strengths as a CA who did - which you can say the same for OCSP.

On Tue, Mar 11, 2014 at 2:21 AM, <i-barreira at izenpe.net> wrote:

Any news on this?

It´s something to agree because it has to update accordingly in the ETSI docs. ETSI ESI has agreed to have OCSP mandatory and CRL optional, any reaction from the CABF?

Regards

Iñigo Barreira
Responsable del Área técnica
i-barreira at izenpe.net

945067705

ERNE! Baliteke mezu honen zatiren bat edo mezu osoa legez babestuta egotea. Mezua badu bere hartzailea. Okerreko helbidera heldu bada (helbidea gaizki idatzi, transmisioak huts egin) eman abisu igorleari, korreo honi erantzuna. KONTUZ!
ATENCION! Este mensaje contiene informacion privilegiada o confidencial a la que solo tiene derecho a acceder el destinatario. Si usted lo recibe por error le agradeceriamos que no hiciera uso de la informacion y que se pusiese en contacto con el remitente.

De: management-bounces at cabforum.org [mailto:management-bounces at cabforum.org] En nombre de i-barreira at izenpe.net
Enviado el: jueves, 20 de febrero de 2014 23:01
Para: management at cabforum.org
Asunto: [cabfman] possible OCSP/CRL inconsistencies in the BR

Hello,

Reviewing the CABF BR, I think there are some inconsistencies. 

For example:

-          In 13.1.5 12) it talks about OCSP/CRL but does not indicate anything else. You can interpretate that both can be used or shall be used or just one

-          In 13.1.6 8) is similar to the one above but it seems to be dedicated to the issuing CAs, and in the annex B it´s indicated that issuing CAs have to have both, the OCSP and the CRL indicated in the AIA and CDP respectively (not the same for the end user certificates in which the CDP has a MAY)

-          In 13.2.2 is different somehow from the first option indicated above, indicating that IF the CA generates CRL for the subscriber certs, but otherwise “mandate” update the CRL AND OCSP for the issuing CAs as indicated in Annex B

-          In 13.2.3 indicates that the CA shall maintain the OCSP and CRL (which is what said in annex b)

-          In 13.2.4 talks about removing the entrances in CRL or OCSP

-          And finally, in the annex B is clearly stated that for CAs has to maintain OCSP and CRL but for end user certificates, only OCSP is mandatory

So, maybe this is a misinterpretation of clause 13, but perhaps a rewording is needed to clarify it.

OTOH, checking some browser policies found that indicates that CRL is mandatory and OCSP optional, so that can be a conflict here. For example, checking the Mozilla one, this is what I found:

1.	CAs must maintain an online 24x7 repository mechanism whereby application software can automatically check online the current status of all unexpired certificates issued by the CA. For end-entity certificates: 

	*	CRLs must be updated and reissued at least every seven days, and the value of the nextUpdate field shall not be more than ten days beyond the value of the thisUpdate field; or 
	*	if the CA provides revocation information via an Online Certificate Status Protocol (OCSP) service, it must update that service at least every four days. OCSP responses from this service must have a maximum expiration time of ten days. 

And this is because 2 weeks go in the ETSI ESI meeting, it was decided that for qualified certificates, OCSP is mandatory and CRL optional. Any possible conflict with this?

Regards

Iñigo Barreira
Responsable del Área técnica
i-barreira at izenpe.net

945067705

ERNE! Baliteke mezu honen zatiren bat edo mezu osoa legez babestuta egotea. Mezua badu bere hartzailea. Okerreko helbidera heldu bada (helbidea gaizki idatzi, transmisioak huts egin) eman abisu igorleari, korreo honi erantzuna. KONTUZ!
ATENCION! Este mensaje contiene informacion privilegiada o confidencial a la que solo tiene derecho a acceder el destinatario. Si usted lo recibe por error le agradeceriamos que no hiciera uso de la informacion y que se pusiese en contacto con el remitente.

_______________________________________________
Management mailing list
Management at cabforum.org
https://cabforum.org/mailman/listinfo/management

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20140313/303c8713/attachment-0002.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 19121 bytes
Desc: image001.png
URL: <http://lists.cabforum.org/pipermail/public/attachments/20140313/303c8713/attachment-0002.png>