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] <
ml-node+s6102n61627...@n7.nabble.com> 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
>>
>>
>>
>> *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
> ml-node+s6102n3...@n7.nabble.com
> To unsubscribe from OpenSSL - User, click here
> <http://openssl.6102.n7.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code&node=3&code=ZGFuYnJ5YW44MEBnbWFpbC5jb218M3wxNTY2MDE3NjQ2>
> .
> 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:
http://openssl.6102.n7.nabble.com/OCSP-service-dependant-on-time-valid-CRLs-tp61600p61628.html
Sent from the OpenSSL - User mailing list archive at Nabble.com.
_______________________________________________
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
