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

[daniel bryan]

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 
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.aba...@docusign.com
>
> Le 10 déc. 2015 à 20:07, socket  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] 
>>
>> Le 10 déc. 2015 à 18:29, socket <[hidden email]
>> > a écrit :
>>
>> Hi Walter,
>>
>> I agree with your addition regarding 

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

[Erwann Abalea]

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

Le 10 déc. 2015 à 20:07, socket 
> 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]

Le 10 déc. 2015 à 18:29, socket <[hidden 
email]> 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] <[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 

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

[Erwann Abalea]

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
erwann.aba...@docusign.com

Le 10 déc. 2015 à 18:29, socket 
> 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] <[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

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

[socket]

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] 
>
> Le 10 déc. 2015 à 18:29, socket <[hidden email]
> > 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] < href="x-msg://5/user/SendEmail.jtp?type=nodenode=61622i=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
> 
> .
> NAML
> 

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

[socket]

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] <
ml-node+s6102n61605...@n7.nabble.com> 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
>
> *smime.p7s* (5K) Download Attachment
> 
>
>
> --
> 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-tp61600p61605.html
> To start a new topic under OpenSSL - User, email
> ml-node+s6102n3...@n7.nabble.com
> To unsubscribe from OpenSSL - User, click here
> 
> .
> NAML
> 
>




--
View this message in context: 
http://openssl.6102.n7.nabble.com/OCSP-service-dependant-on-time-valid-CRLs-tp61600p61622.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

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

[daniel bryan]

Hello,

I was researching how expired CRLs affect revocation checking via openssl.

* TEST #1: *The first test was to find out what status is returned when i
verify a certificate against the CRL:

[dan@canttouchthis PKI]$ openssl verify -CAfile CAS/cabundle.pem -CRLfile
CRLS/ABC-expired.crl -crl_check CERTS/0x500c8bd-revoked.pem




*CERTS/0x500c8bd-revoked.pem: C = us, O = ORG, OU = LAB, OU = ABC, OU =
D002, CN = test error 12 at 0 depth lookup:CRL has expiredC = us, O = ORG,
OU = LAB, OU = ABC, OU = D002, CN = test error 23 at 0 depth
lookup:certificate revoked*

as you can see the client *WAS* informed the certificate was *revoked*,
even though the CRL was expired.


*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.

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.

I have read RFC 2560 & 6960 many times, and have not been able to find
explicit guidance on this scenario. I am interested in the community
opinion on this issue, and any pertinent mandatory guidance.

My end goal is either to convince our vendor to provide a revoked status
regardless of the CRLs expiration OR justify why an OCSP service should
ignore issuers with expired CRLs. I'm looking forward to any feedback
provided.

--Dan
___
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

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

[Walter H.]

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


smime.p7s
Description: S/MIME Cryptographic Signature
___
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users