<div dir="ltr"><div><div>Thanks Erwann,<br><br></div>I appreciate your point regarding the cost of a signing operation. I plan to take action on this. Pointing out RFC 5280 in regards to what status it will return when it fails to download a fresh CRL helped a lot. I now see that revoked is not "a" correct response according to the logic defined in the RFC. I do feel that since a certificate can not be unrevoked (with the exception of "on hold") that if an OCSP service learns that serial #X was once revoked with a reason code of (anything bit on hold), therefor it must still be revoked. Am I wrong in thinking this? Is it more safe to completely disregard an expired CRLs?<br><br></div>--Dan<br></div><br><div class="gmail_quote"><div dir="ltr">On Fri, Dec 11, 2015 at 9:15 AM Erwann Abalea <<a href="mailto:Erwann.Abalea@docusign.com">Erwann.Abalea@docusign.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word">
Bonjour,
<div><br>
</div>
<div>The problem with signing with a default certificate is that the response certainly won’t be accepted by the client (see RFC6960 section 4.2.2.2, this responder certificate doesn’t follow criteria 1 and 2, and certainly not criteria 3), so you’re
performing a signature knowing it will be rejected by a compliant client. It is also unwise from your side, because anybody can send a request for free, and as a result you’ll perform a signature: non negligible CPU cost and the response is larger than the
request. An unsigned error message may be better.</div>
<div><br>
</div>
<div>« Unknown » is *a* correct answer in that specific case, not the only correct one. « tryLater » and « internalError » are equivalently correct answers. « Good », « malformedRequest », and « sigRequired » are NOT correct answers. « unauthorized »
may also be considered a correct answer, but others may disagree. « Revoked » may seem a correct answer also, but not quite (see below).</div>
<div>The meaning of those different results is explained in RFC6960 and RFC5019.</div>
<div>Of course, if you’re using CRLs as an authoritative source of certificate status, RFC5280 is to be read also.</div>
<div><br>
</div>
<div>Reading the algorithm described in RFC5280 section 6.3.3 to perform a CRL validation, you’ll see that:</div>
<div>- at step (a)(1)(ii), you don’t get a newer CRL, so you can’t continue the algorithm</div>
<div>- after the algorithm, reasons_masks is still the empty set, and cert_status still has the value UNREVOKED, so the revocation status has NOT been determined</div>
<div>- last paragraph of 6.3.3 tells you that in the end, if the revocation status has not been determined, return a cert_status UNDETERMINED.</div>
<div><br>
</div>
<div>An OCSP service based on a CRL, given an expired CRL, running this normative algorithm, will get a cert_status « UNDETERMINED », and not a value stating that it’s revoked. Such an OCSP service, responding « Revoked », wouldn’t be strictly compliant.</div>
</div><div style="word-wrap:break-word"><div><br>
<div>
<div>Erwann Abalea</div>
<div><a href="mailto:erwann.abalea@docusign.com" target="_blank">erwann.abalea@docusign.com</a></div>
</div>
<br>
<div>
<blockquote type="cite"></blockquote></div></div></div><div style="word-wrap:break-word"><div><div><blockquote type="cite">
<div>Le 10 déc. 2015 à 20:07, socket <<a href="mailto:danbryan80@gmail.com" target="_blank">danbryan80@gmail.com</a>> a écrit :</div>
<br>
</blockquote></div></div></div><div style="word-wrap:break-word"><div><div><blockquote type="cite"><div><div dir="ltr">
<div>Thanks for chiming in Erwann. This OCSP service is CRL based. The software I am using has a "default signing certificate". I also have #X CA specific signing certificates for each CA in our lab PKI. It chooses to use the default signing certificate
for all unknown issuers (like if someone explicitly queries the service for a microsoft timestamp certificate).
<br>
<br>
I appreciate your definitive response regarding that the correct answer in this situation is to return unknown. I recognize your name as an authority in pkix, but is this documented anywhere? I would like to be able to justify to my customer that this is indeed
the correct response. <br>
<br>
Also, it seems weird to me that validating this certificate against the expired CRL returns a status of revoked, but when validating this same certificate against the OCSP service it says unknown. I guess i just have to get over that they are different and
that a certificate can have a different status depending on who you ask.<br>
<br>
</div>
<div>Looking forward to any follow on thoughts...<br>
</div>
<div><br>
</div>
--Dan<br>
</div></div></blockquote></div></div></div><div style="word-wrap:break-word"><div><div><blockquote type="cite"><div><div dir="ltr"><div><div><div class="gmail_quote">
<div dir="ltr">On Thu, Dec 10, 2015 at 2:32 PM Erwann Abalea-4 [via OpenSSL] <<a rel="nofollow" link="external">[hidden email]</a>> wrote:<br>
</div>
</div></div></div></div></div></blockquote></div></div></div><div style="word-wrap:break-word"><div><div><blockquote type="cite"><div><div dir="ltr"><div><div><div class="gmail_quote"><blockquote style="border-left:2px solid #cccccc;padding:0 1em" class="gmail_quote">
<div>Bonsoir,</div>
<div><br>
</div>
<div>The OCSP responder can respond « unknown » if it doesn’t know the status of the requested certificate. « Unknown » can generally not be used when the issuer is not known, because such a response is signed, and if the responder doesn’t know about
the issuer, it can’t choose its own certificate to use to sign the response.</div>
<div><br>
</div>
<div>If your OCSP responder is CRL based, and the CRL is not valid (badly encoded, wrong signature, incomplete in scope, expired, whatever…), « unknown » is a correct answer. « revoked » is also a correct answer if an expired CRL is found declaring
the requested certificate as revoked. « tryLater » is also a correct answer, even « internalError » if we consider the CRL as part of the internal state of the responder.</div>
<div><br>
</div>
<div>
<div>Erwann Abalea</div>
<div><a href="http://user/SendEmail.jtp?type=node&node=61627&i=0" rel="nofollow" link="external" target="_blank">[hidden email]</a></div>
</div>
<br>
<div>
<blockquote style="border-left:2px solid #cccccc;padding:0 1em" type="cite">
</blockquote>
</div>
<div>
<blockquote style="border-left:2px solid #cccccc;padding:0 1em" type="cite">
<div>Le 10 déc. 2015 à 18:29, socket <<a href="http://user/SendEmail.jtp?type=node&node=61627&i=1" rel="nofollow" link="external" target="_blank">[hidden email]</a>> a écrit :</div>
<br>
</blockquote>
</div>
<div>
<blockquote style="border-left:2px solid #cccccc;padding:0 1em" type="cite">
<div>
<div dir="ltr">
<div>Hi Walter, <br>
<br>
I agree with your addition regarding the fact that it is not saying the cert is good, it's saying unknown. However, my understanding of the RFC is that unknown should be returned when the OCSP service does not know about the certificate issuer. I'm not sure
that's the case. <br>
<br>
Regarding the response verification, we are used the CA Designated Responder (Authorized Responder). meaning that the issuer of serial 0x500c8bd was the same issuer of the OCSP Signing response (ABC CA3 DEV). However, my testing shows that this only affects
the "response verification (OK/FAILED)" not the certificate status returned (good/revoked/unknown).<br>
<br>
</div>
--Dan<br>
</div>
</div>
</blockquote>
</div>
<div>
<blockquote style="border-left:2px solid #cccccc;padding:0 1em" type="cite">
<div>
<div dir="ltr">
<div><br>
<div class="gmail_quote">
<div dir="ltr">On Thu, Dec 10, 2015 at 11:36 AM Walter H. [via OpenSSL] <<a href="<a>x-msg://5/user/SendEmail.jtp?type=node&node=61622&i=0</a>" target="_top" rel="nofollow"
link="external" class="">[hidden email]> wrote:<br>
</div>
<blockquote style="border-left:2px solid #cccccc;padding:0 1em" class="gmail_quote">
Hi Dan,<br>
<br>
On 10.12.2015 16:27, daniel bryan wrote:
<blockquote style="border-left:2px solid #cccccc;padding:0 1em" type="cite">
<div>
<div><b>TEST #2: </b>Next test was using OCSP:<br>
<br>
[dan@canttouchthis PKI]$ openssl ocsp -CAfile CAS/cabundle.pem -VAfile VAS/def_ocsp.pem -issuer CAS/IC\ ABC\ CA3\ DEV.cer -cert CERTS/0x500c8bd-revoked.pem -url
<a href="http://ocspresponder:8080/" rel="nofollow" link="external" target="_blank">
http://ocspresponder:8080</a><br>
<br>
<i>Response verify OK<br>
CERTS/0x500c8bd-revoked.pem: <b>unknown</b><br>
This Update: Dec 9 20:48:26 2015 GMT</i><br>
<br>
as you can see the client <b>was NOT </b>informed the certificate was revoked.<br>
</div>
</div>
</blockquote>
and also that it is not good -> unknown, revoked and good are the 3 values ...<br>
<blockquote style="border-left:2px solid #cccccc;padding:0 1em" type="cite">
<div>
<div><br>
We are using a 3rd party vendors OCSP service, and I am of the opinion that an OCSP service should provide a revoked response regardless of the time validity of the CRL.
<br>
</div>
</div>
</blockquote>
does the OCSP responder cert be the signing cert itself or was it signed by the same signing cert that signed the cert you want to validate?<br>
<br>
or specific to your sample: did CAS/IC\ ABC\ CA3\ DEV.cer sign both CERTS/0x500c8bd-revoked.pem and the OCSP responder cert (VAS/def_ocsp.pem)?
<blockquote style="border-left:2px solid #cccccc;padding:0 1em" type="cite">
<div>
<div><br>
</div>
</div>
</blockquote>
Walter<br>
<br>
</blockquote>
</div>
</div>
</div>
</div>
</blockquote>
</div>
<br>
_______________________________________________ <br>
openssl-users mailing list <br>
To unsubscribe: <a href="https://mta.openssl.org/mailman/listinfo/openssl-users" rel="nofollow" link="external" target="_blank">
https://mta.openssl.org/mailman/listinfo/openssl-users</a><br>
<br>
<br>
<div style="color:#444;font:12px tahoma,geneva,helvetica,arial,sans-serif">
<div style="font-weight:bold">If you reply to this email, your message will be added to the discussion below:</div>
</div>
<div style="color:#444;font:12px tahoma,geneva,helvetica,arial,sans-serif">
<a href="http://openssl.6102.n7.nabble.com/OCSP-service-dependant-on-time-valid-CRLs-tp61600p61627.html" rel="nofollow" link="external" target="_blank">http://openssl.6102.n7.nabble.com/OCSP-service-dependant-on-time-valid-CRLs-tp61600p61627.html</a>
</div>
</blockquote></div></div></div></div></div></blockquote></div></div></div><div style="word-wrap:break-word"><div><div><blockquote type="cite"><div><div dir="ltr"><div><div><div class="gmail_quote"><blockquote style="border-left:2px solid #cccccc;padding:0 1em" class="gmail_quote"><div style="color:#666;font:11px tahoma,geneva,helvetica,arial,sans-serif;margin-top:.4em;line-height:1.5em">
To start a new topic under OpenSSL - User, email <a rel="nofollow" link="external">
[hidden email]</a> <br></div></blockquote></div></div></div></div></div></blockquote></div></div></div><div style="word-wrap:break-word"><div><div><blockquote type="cite"><div><div dir="ltr"><div><div><div class="gmail_quote"><blockquote style="border-left:2px solid #cccccc;padding:0 1em" class="gmail_quote"><div style="color:#666;font:11px tahoma,geneva,helvetica,arial,sans-serif;margin-top:.4em;line-height:1.5em">
To unsubscribe from OpenSSL - User, <a rel="nofollow" link="external">
click here</a>.<br>
<a href="http://openssl.6102.n7.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml" rel="nofollow" style="font:9px serif" link="external" target="_blank">NAML</a>
</div></blockquote></div></div></div></div></div></blockquote></div></div></div><div style="word-wrap:break-word"><div><div><blockquote type="cite"><div>
<hr align="left" width="300">
View this message in context: <a href="http://openssl.6102.n7.nabble.com/OCSP-service-dependant-on-time-valid-CRLs-tp61600p61628.html" target="_blank">
Re: OCSP service dependant on time valid CRLs</a><br>
Sent from the <a href="http://openssl.6102.n7.nabble.com/OpenSSL-User-f3.html" target="_blank">
OpenSSL - User mailing list archive</a> at <a href="http://Nabble.com" target="_blank">Nabble.com</a>.<br></div></blockquote></div></div></div><div style="word-wrap:break-word"><div><div><blockquote type="cite"><div>
_______________________________________________<br>
openssl-users mailing list<br>
To unsubscribe: <a href="https://mta.openssl.org/mailman/listinfo/openssl-users" target="_blank">
https://mta.openssl.org/mailman/listinfo/openssl-users</a><br>
</div></blockquote></div></div></div>
_______________________________________________<br>
openssl-users mailing list<br>
To unsubscribe: <a href="https://mta.openssl.org/mailman/listinfo/openssl-users" rel="noreferrer" target="_blank">https://mta.openssl.org/mailman/listinfo/openssl-users</a><br>
</blockquote></div>