Re: CRL validation must be skipped for certs with no CRLDPs
Jeff Saremi writes: [...] > According to the RFC, is it an error for a certificate and its chain not > to have any CRLs and CRL distribtuion points? No, but you're perhaps confusing things by joining the two together. On CRL DPs, "this profile RECOMMENDS support for this extension by CAs and applications". On CRLs, the end of section 5 says "Conforming CAs are not required to issue CRLs if other revocation or certificate status mechanisms are provided." [...] > If the answer is no, then the body of code that is operating today on > the Internet and is using SSL (think of it as browsers) should operate > with no errors. In this sense, OpenSSL would be an exception because > its default and natural implementation causes an error. Application writers have to consider what to do about revocation. One option is for an application to ignore the possibility of revocation, and OpenSSL can easily be used to do that. Otherwise the application must have some functionality to request OCSP, provide CRLs, etc. And (again) this is not specific to OpenSSL. Other certificate verifiers will (when asked to check revocation status) also reject certification paths where revocation status is unavailable. Any that don't do that are surely broken? __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: CRL validation must be skipped for certs with no CRLDPs
If I just try to describe the problem in a different way it would be: According to the RFC, is it an error for a certificate and its chain not to have any CRLs and CRL distribtuion points? If the answer to the above is yes, then what OpenSSL does is OK because the programmer would have to explicitly by way of writing callbacks or by way of disabling CRLs altogether handle the situation. If the answer is no, then the body of code that is operating today on the Internet and is using SSL (think of it as browsers) should operate with no errors. In this sense, OpenSSL would be an exception because its default and natural implementation causes an error. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: CRL validation must be skipped for certs with no CRLDPs
Jeff Saremi writes:
[...]
> Here's the code:
>
> cert.status = NOT_REVOKED;
> for (i = 0; i < cert.crldp.size; ++i)
> {
> /* some processing loops */
> if(cert.status == UNDETERMINED)
> {
> /* do what Bruce Stephens suggested */
> }
> }
No, I think RFC5280 is saying that you may have CRLs which were not
indicated by CRLDP. Even if there is no CRLDP at all, you may have
(through some other means) CRLs issued by some appropriate entity
(either the CA or a indirect CRL issuer).
If you don't have any of those (and you don't have any other mechanism
for verifying revocation status, such as OCSP) then that surely
shouldn't mean that the certificate is not revoked---it surely ought to
mean you don't know?
When designing your own applications you might reasonably choose to
regard such certificates as valid, or (alternatively) to reject them on
the grounds that revocation status can't be checked. Both seem
reasonable choices, depending on the circumstances.
I'm not sure what you should do if you're issuing certificates and want
people to always regard them as unrevoked. I suspect it depends how
much control you have over the software that other people are using. At
worst you might need to produce CRLs (which would always be empty) or
run an OCSP server.
[...]
> Now as a result of OpenSSL's imlementation, none of my clients who use
> OpenSSL will be able to deal with me online.
I don't think it has anything to do with OpenSSL. Other verifiers will
behave similarly (I happen to be familiar with CML and that'll behave
the same as OpenSSL, if revocation checking is enabled).
> Because my certificates do not have a CRL and CRLDP period. Should I
> stop doing business altogether? Should I contact my business partners
> and tell them that they should be applying a patch to their code,
> overriding verification failure in their certVerifyCallbacks? Let's
> just think that through a little.
If you want to support software that performs revocation checking then
you'll need to provide some way for that software to check revocation
status. That might be simple (provide an empty CRL with a nextUpdate
way off in the future).
But maybe that's not necessary: for software that only really addresses
you certs, maybe you can persuade the software not to perform revocation
checking.
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager majord...@openssl.org
Re: CRL validation must be skipped for certs with no CRLDPs
I'm not sure how you read this. I read it like a programmer.
In programming primitives, the spec would be coded like this:
Here's the spec:
"This algorithm begins by assuming that the certificate is not revoked
For each distribution point (DP) in the certificate's CRL distribution
points extension, for each corresponding CRL "
And here's the C code:
cert.status = UNREVOKED;
for (i = 0; i < cert.crldp.size; ++i)
{
/* more processing loops */
}
Right there, the main loop should not even execute because
cert.crldp.size is zero.
But let's play along and say that for some unknown reason we get to the
section of the spec you're referring to:
Here's the spec:
> I think you should read on. Specifically, the last paragraph seems to
> me to indicate different behaviour is intended:
>
>If the revocation status has not been determined, repeat the process
>above with any available CRLs not specified in a distribution point
>but issued by the certificate issuer.
Here's the code:
cert.status = NOT_REVOKED;
for (i = 0; i < cert.crldp.size; ++i)
{
/* some processing loops */
if(cert.status == UNDETERMINED)
{
/* do what Bruce Stephens suggested */
}
}
As you can see again there's another stop and that stop is that our
certificate's status is not "UNDETERMINED" but rather "UNREVOKED".
But lets view this whole thing from another perspective:
I have a limited certificate authority in my organization. have a root
cert which does not get revoked. I distribute that to the ones who want
to deal with me. I also generate a multitude of endpoint certificates. I
do not intend for any of these to become revoked, ever. Hence, I do not
bother with the process of certificate revocation and CRL issuance. Now
as a result of OpenSSL's imlementation, none of my clients who use
OpenSSL will be able to deal with me online. Because my certificates do
not have a CRL and CRLDP period. Should I stop doing business
altogether? Should I contact my business partners and tell them that
they should be applying a patch to their code, overriding verification
failure in their certVerifyCallbacks? Let's just think that through a
little.
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager majord...@openssl.org
Re: CRL validation must be skipped for certs with no CRLDPs
Jeff Saremi writes: [...] > Section 6.3.3. of RFC 5280 - CRL Processing > "This algorithm begins by assuming that the certificate is not revoked > For each distribution point (DP) in the certificate's CRL distribution > points extension, for each corresponding CRL " > > So my expectation is that after I instruct OpenSSL to perform CRL > checking -- whether I set or not set any CRLs -- no checking must be > done on any certificates which don't have CRLDP in them. I think you should read on. Specifically, the last paragraph seems to me to indicate different behaviour is intended: If the revocation status has not been determined, repeat the process above with any available CRLs not specified in a distribution point but issued by the certificate issuer. For the processing of such a CRL, assume a DP with both the reasons and the cRLIssuer fields omitted and a distribution point name of the certificate issuer. That is, the sequence of names in fullName is generated from the certificate issuer field as well as the certificate issuerAltName extension. After processing such CRLs, if the revocation status has still not been determined, then return the cert_status UNDETERMINED. That seems to me more natural: if there's no CRLDP then check any relevant CRL. If (after all this) you fail to find any relevant CRLs, then the revocation status is undetermined. [...] __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
CRL validation must be skipped for certs with no CRLDPs
This was mentioned briefly in another thread by myself. I thought it deserved its own discussion. The copies of how it went on are pasted below. Section 6.3.3. of RFC 5280 - CRL Processing "This algorithm begins by assuming that the certificate is not revoked For each distribution point (DP) in the certificate's CRL distribution points extension, for each corresponding CRL " So my expectation is that after I instruct OpenSSL to perform CRL checking -- whether I set or not set any CRLs -- no checking must be done on any certificates which don't have CRLDP in them. The spec ofcourse mentions that implementations are not required to follow this algorithm, however, it also mentions that the end result must be the same as when they did. Now as an average user of OpenSSL API, I expect not to have to write any piece of code (such as over-ruling the validation failure in validation callback) for the normal process of certificate/CRL validation to take its course. Is this a reasonable expectation? thanks Jeff * Original Problem Statement Re: Need Help with Programmatic Downloading+Checking of CRLs ... > So as per previous posts, I implemented lookup_crl(). > Now one of the major problems is what do I return from this method, if > the certificate has no CRL distribution points! > Returning an empty stack causes get_crl_delta() to fail. > Is there a flag that I can setup to let this cert be excluded from CRL > checking? > Is that something I should be doing in lookup_crl? Or should the > framework be smart enough not to even ask me for a CRL in this case? > > thanks > jeff > There are other "out of band" mechanisms where a CRL might be available but > not mentioned in a CRLDP. OpenSSL has no way of telling what those might be > and if the absence is really an error or not. > > The best you can do is trap the issuer error in the verify callback and ignore > it if appropriate. > > Steve. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
