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.aba...@docusign.com<mailto:erwann.aba...@docusign.com> Le 10 déc. 2015 à 20:07, socket <danbrya...@gmail.com<mailto:danbrya...@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]<x-msg://7/user/SendEmail.jtp?type=node&node=61628&i=0>> 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@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<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]<x-msg://7/user/SendEmail.jtp?type=node&node=61628&i=1> 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<http://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
