<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">
Bonjour,
<div class=""><br class="">
</div>
<div class="">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 class=""><br class="">
</div>
<div class="">« 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 class="">The meaning of those different results is explained in RFC6960 and RFC5019.</div>
<div class="">Of course, if you’re using CRLs as an authoritative source of certificate status, RFC5280 is to be read also.</div>
<div class=""><br class="">
</div>
<div class="">Reading the algorithm described in RFC5280 section 6.3.3 to perform a CRL validation, you’ll see that:</div>
<div class="">- at step (a)(1)(ii), you don’t get a newer CRL, so you can’t continue the algorithm</div>
<div class="">- 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 class="">- 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 class=""><br class="">
</div>
<div class="">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 class=""><br class="">
<div apple-content-edited="true" class="">
<div class="">Erwann Abalea</div>
<div class=""><a href="mailto:erwann.abalea@docusign.com" class="">erwann.abalea@docusign.com</a></div>
</div>
<br class="">
<div>
<blockquote type="cite" class="">
<div class="">Le 10 déc. 2015 à 20:07, socket <<a href="mailto:danbryan80@gmail.com" class="">danbryan80@gmail.com</a>> a écrit :</div>
<br class="Apple-interchange-newline">
<div class="">
<div dir="ltr" class="">
<div class="">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 class="">
<br class="">
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 class="">
<br class="">
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 class="">
<br class="">
</div>
<div class="">Looking forward to any follow on thoughts...<br class="">
</div>
<div class=""><br class="">
</div>
--Dan<br class="">
<div class="">
<div class=""><br class="">
<div class="gmail_quote">
<div dir="ltr" class="">On Thu, Dec 10, 2015 at 2:32 PM Erwann Abalea-4 [via OpenSSL] <<a href="x-msg://7/user/SendEmail.jtp?type=node&node=61628&i=0" target="_top" rel="nofollow" link="external" class="">[hidden email]</a>> wrote:<br class="">
</div>
<blockquote style="border-left:2px solid #CCCCCC;padding:0 1em" class="gmail_quote">
<div class="">Bonsoir,</div>
<div class=""><br class="">
</div>
<div class="">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 class=""><br class="">
</div>
<div class="">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 class=""><br class="">
</div>
<div class="">
<div class="">Erwann Abalea</div>
<div class=""><a href="http://user/SendEmail.jtp?type=node&node=61627&i=0" rel="nofollow" link="external" target="_blank" class="">[hidden email]</a></div>
</div>
<br class="">
<div class="">
<blockquote style="border-left:2px solid #CCCCCC;padding:0 1em" type="cite" class="">
</blockquote>
</div>
<div class="">
<blockquote style="border-left:2px solid #CCCCCC;padding:0 1em" type="cite" class="">
<div class="">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" class="">[hidden email]</a>> a écrit :</div>
<br class="">
</blockquote>
</div>
<div class="">
<blockquote style="border-left:2px solid #CCCCCC;padding:0 1em" type="cite" class="">
<div class="">
<div dir="ltr" class="">
<div class="">Hi Walter, <br class="">
<br class="">
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 class="">
<br class="">
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 class="">
<br class="">
</div>
--Dan<br class="">
</div>
</div>
</blockquote>
</div>
<div class="">
<blockquote style="border-left:2px solid #CCCCCC;padding:0 1em" type="cite" class="">
<div class="">
<div dir="ltr" class="">
<div class=""><br class="">
<div class="gmail_quote">
<div dir="ltr" class="">On Thu, Dec 10, 2015 at 11:36 AM Walter H. [via OpenSSL] <<a href="<a href="x-msg://5/user/SendEmail.jtp?type=node&amp;node=61622&amp;i=0" class="">x-msg://5/user/SendEmail.jtp?type=node&amp;node=61622&amp;i=0</a>" target="_top" rel="nofollow"
 link="external" class="">[hidden email]> wrote:<br class="">
</div>
<blockquote style="border-left:2px solid #CCCCCC;padding:0 1em" class="gmail_quote">
Hi Dan,<br class="">
<br class="">
On 10.12.2015 16:27, daniel bryan wrote:
<blockquote style="border-left:2px solid #CCCCCC;padding:0 1em" type="cite" class="">
<div class="">
<div class=""><b class="">TEST #2: </b>Next test was using OCSP:<br class="">
<br class="">
[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" class="">
http://ocspresponder:8080</a><br class="">
<br class="">
<i class="">Response verify OK<br class="">
CERTS/0x500c8bd-revoked.pem: <b class="">unknown</b><br class="">
This Update: Dec 9 20:48:26 2015 GMT</i><br class="">
<br class="">
as you can see the client <b class="">was NOT </b>informed the certificate was revoked.<br class="">
</div>
</div>
</blockquote>
and also that it is not good -> unknown, revoked and good are the 3 values ...<br class="">
<blockquote style="border-left:2px solid #CCCCCC;padding:0 1em" type="cite" class="">
<div class="">
<div class=""><br class="">
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 class="">
</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 class="">
<br class="">
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" class="">
<div class="">
<div class=""><br class="">
</div>
</div>
</blockquote>
Walter<br class="">
<br class="">
</blockquote>
</div>
</div>
</div>
</div>
</blockquote>
</div>
<br class="">
_______________________________________________ <br class="">
openssl-users mailing list <br class="">
To unsubscribe: <a href="https://mta.openssl.org/mailman/listinfo/openssl-users" rel="nofollow" link="external" target="_blank" class="">
https://mta.openssl.org/mailman/listinfo/openssl-users</a><br class="">
<br class="">
<br class="">
<div style="color:#444;font:12px tahoma,geneva,helvetica,arial,sans-serif" class="">
<div style="font-weight:bold" class="">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" class="">
<a href="http://openssl.6102.n7.nabble.com/OCSP-service-dependant-on-time-valid-CRLs-tp61600p61627.html" target="_blank" rel="nofollow" link="external" class="">http://openssl.6102.n7.nabble.com/OCSP-service-dependant-on-time-valid-CRLs-tp61600p61627.html</a>
</div>
<div style="color:#666;font:11px tahoma,geneva,helvetica,arial,sans-serif;margin-top:.4em;line-height:1.5em" class="">
To start a new topic under OpenSSL - User, email <a href="x-msg://7/user/SendEmail.jtp?type=node&node=61628&i=1" target="_top" rel="nofollow" link="external" class="">
[hidden email]</a> <br class="">
To unsubscribe from OpenSSL - User, <a href="" target="_blank" rel="nofollow" link="external" class="">
click here</a>.<br class="">
<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" target="_blank" link="external" class="">NAML</a>
</div>
</blockquote>
</div>
</div>
</div>
</div>
<br class="">
<hr align="left" width="300" class="">
View this message in context: <a href="http://openssl.6102.n7.nabble.com/OCSP-service-dependant-on-time-valid-CRLs-tp61600p61628.html" class="">
Re: OCSP service dependant on time valid CRLs</a><br class="">
Sent from the <a href="http://openssl.6102.n7.nabble.com/OpenSSL-User-f3.html" class="">
OpenSSL - User mailing list archive</a> at <a href="http://Nabble.com" class="">Nabble.com</a>.<br class="">
_______________________________________________<br class="">
openssl-users mailing list<br class="">
To unsubscribe: <a href="https://mta.openssl.org/mailman/listinfo/openssl-users" class="">
https://mta.openssl.org/mailman/listinfo/openssl-users</a><br class="">
</div>
</blockquote>
</div>
<br class="">
</div>
</body>
</html>