Thanks Erwann, 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? --Dan On Fri, Dec 11, 2015 at 9:15 AM Erwann Abalea <Erwann.Abalea at docusign.com> wrote: > Bonjour, > > 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. > > ? 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). > The meaning of those different results is explained in RFC6960 and RFC5019. > Of course, if you?re using CRLs as an authoritative source of certificate > status, RFC5280 is to be read also. > > Reading the algorithm described in RFC5280 section 6.3.3 to perform a CRL > validation, you?ll see that: > - at step (a)(1)(ii), you don?t get a newer CRL, so you can?t continue the > algorithm > - 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 > - 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. > > 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. > > Erwann Abalea > erwann.abalea at docusign.com > > Le 10 d?c. 2015 ? 20:07, socket <danbryan80 at gmail.com> a ?crit : > > 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). > > 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. > > 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. > > Looking forward to any follow on thoughts... > > --Dan > > On Thu, Dec 10, 2015 at 2:32 PM Erwann Abalea-4 [via OpenSSL] <[hidden > email]> wrote: > > Bonsoir, >> >> 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. >> >> 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. >> >> Erwann Abalea >> [hidden email] <http://user/SendEmail.jtp?type=node&node=61627&i=0> >> >> Le 10 d?c. 2015 ? 18:29, socket <[hidden email] >> <http://user/SendEmail.jtp?type=node&node=61627&i=1>> a ?crit : >> >> Hi Walter, >> >> 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. >> >> 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). >> >> --Dan >> >> >> On Thu, Dec 10, 2015 at 11:36 AM Walter H. [via OpenSSL] <<a href=" >> x-msg://5/user/SendEmail.jtp?type=node&node=61622&i=0" >> target="_top" rel="nofollow" link="external" class="">[hidden email]> wrote: >> >>> Hi Dan, >>> >>> On 10.12.2015 16:27, daniel bryan wrote: >>> >>> *TEST #2: *Next test was using OCSP: >>> >>> [dan at 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 http://ocspresponder:8080 >>> >>> >>> >>> *Response verify OK CERTS/0x500c8bd-revoked.pem: unknown This Update: >>> Dec 9 20:48:26 2015 GMT* >>> >>> as you can see the client *was NOT *informed the certificate was >>> revoked. >>> >>> and also that it is not good -> unknown, revoked and good are the 3 >>> values ... >>> >>> >>> 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. >>> >>> 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? >>> >>> 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)? >>> >>> >>> Walter >>> >>> >> _______________________________________________ >> openssl-users mailing list >> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users >> >> >> If you reply to this email, your message will be added to the discussion >> below: >> >> http://openssl.6102.n7.nabble.com/OCSP-service-dependant-on-time-valid-CRLs-tp61600p61627.html >> > To start a new topic under OpenSSL - User, email [hidden email] >> > To unsubscribe from OpenSSL - User, click here. >> NAML >> <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> >> > ------------------------------ > View this message in context: Re: OCSP service dependant on time valid > CRLs > <http://openssl.6102.n7.nabble.com/OCSP-service-dependant-on-time-valid-CRLs-tp61600p61628.html> > Sent from the OpenSSL - User mailing list archive > <http://openssl.6102.n7.nabble.com/OpenSSL-User-f3.html> at Nabble.com. > > _______________________________________________ > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > > _______________________________________________ > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20151213/e5ff45be/attachment-0001.html>
