[openssl-users] OCSP service dependant on time valid CRLs

Sun Dec 13 19:55:34 UTC 2015

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>