4.2 talks about CRL's, as does 7.3, but most of the rest of the doc seems to assume only OCSP will exist. For example, 4.7 suggests that In case the resulting status after an exhausted search is still an error or status Unknown, the client SHOULD interpret that as Revoked with revocationReason certificateHold (that is, a non-definite revocation state), unless otherwise configured.
This is a bit evil, yes. The recommended interpretation above should be that of the client, after consulting ALL revocation sources, including CRLs. All other parties should simply reply "unknown" when they run out of options.
Experience with Grid / openssl use of CRLs and Netscape's OCSP client suggest to me that network failure and OCSP responder timeout should be considered as "unknown - tryLayer" (we can agree to that - similar to 4.7).
Note that "tryLater" is an error code, whereas "unknown" is a certificate status encoded in an otherwise perfectly fine and digitally signed OCSP response. Two completely different things, in other words.
4.7 - discussion about delta CRL's.
4.7. is about error handling and the unknown status code. Do you mean section 5.3 or 6.3?
This seems to be a discussion about 2 recommendations: 1) CA's - publish your CRL's directly to the (some) OCSP responder(s) 2) use delta CRL's to reduce size
Can we slim down those 2 paras to essentially say just that?
Olle Mulmo writes:
4.7 - discussion about delta CRL's. 4.7. is about error handling and the unknown status code. Do you mean section 5.3 or 6.3?
This seems to be a discussion about 2 recommendations: 1) CA's - publish your CRL's directly to the (some) OCSP responder(s) 2) use delta CRL's to reduce size
Can we slim down those 2 paras to essentially say just that?
You're rite - it's 6.3, don't know why I wrote the wrong section.
4.2 talks about CRL's, as does 7.3, but most of the rest of the doc seems to assume only OCSP will exist. For example, 4.7 suggests that In case the resulting status after an exhausted search is still an error or status Unknown, the client SHOULD interpret that as Revoked with revocationReason certificateHold (that is, a non-definite revocation state), unless otherwise configured.
This is a bit evil, yes. The recommended interpretation above should be that of the client, after consulting ALL revocation sources, including CRLs. All other parties should simply reply "unknown" when they run out of options.
In this sense, we find that the suggestion provided by Mike specifying an order to deal with the validation sources is very appropriate. Maybe one thing to point out would be the ending condition. We suggest to present it as: Search revocation information in preference order clients should validate local Trusted OCSP responders first, Authorized OCSP responders next and then CRLs First final answer ends the search. (understanding by final answer a valid or invalid one).
In 95%+ of the cases, I would agree with you. However, there is a discussion about this already in Section 4.2, which concludes that we cannot make this kind of general judgement (local Trusted responder, Authorized responder, CRLs) for all deployment scenarios. I suggest to change the text in 4.7, along the lines of: In case the Unknown state is returned, it is left to local policy and application-level logic to determine a suitable action. As a default, we recommend that applications behave as if they would had they received a Revoked state with revocationReason certificateHold (that is, a temporal revocation state). OK? /Olle On Jun 2, 2005, at 18:05, Oscar Manso wrote:
Search revocation information in preference order clients should validate local Trusted OCSP responders first, Authorized OCSP responders next and then CRLs First final answer ends the search. (understanding by final answer a valid or invalid one).
Olle Mulmo writes:
we recommend that applications behave as if they would had they received a Revoked state with revocationReason certificateHold (that is, a temporal revocation state).
This seems so close to the very poor behavior we have had with CRLs and non-updated or missing CRL's that I just don't think it is the rite thing to do. I realize the security profs want this. I just think it leads to annoying problems, particularly when the OCSP service isn't available (like, for instance, the local net becomes scrambled, just at the moment your batch job enters the queue.) Reading Netscape mail in offline mode on an airplane, with OCSP enabled, was quite annoying! I think Netscape/Mozilla logged some bugs on this but don't know numbers or resolution, if any. I interpret this recommendation as trying to fail safe, but think it will result in more practical harm than good.
Search revocation information in preference order clients should validate local Trusted OCSP responders first, Authorized OCSP responders next and then CRLs First final answer ends the search. (understanding by final answer a valid or invalid one).
I think it is hard to make one rite answer & don't have a strong opinion on this, but why _wouldn't_ the static info (local CRL) be the usual first test? Isn't it always the cheapest test? Since it should _never_ be better than the the OCSP check, checking it last seems useless unless (and only unless) all the OCSP responses are timeouts or unknown. So just do it first and then forget it (see above).
On Jun 3, 2005, at 01:30, Mike Helm wrote:
I think it is hard to make one rite answer & don't have a strong opinion on this, but why _wouldn't_ the static info (local CRL) be the usual first test? Isn't it always the cheapest test? Since it should _never_ be better than the the OCSP check, checking it last seems useless unless (and only unless) all the OCSP responses are timeouts or unknown. So just do it first and then forget it (see above).
I'm not sure the gain outweighs the additional complexity. How many percent of the issued certificates are typically revoked? That's the maximum reduction of OCSP queries that you would get as a result. Plus, you have to watch out when encoding the logic: if you process the CRL first, the cert not being in the CRL should equal "unknown" and you should continue looking at other places; if you process the CRL last and the cert is not in the CRL, it should evaluate to "good". IMO, it's only when you run a well-managed central service that you would really gain by query CRLs first, and assume that a non-entry means "good", as that requires proper conduct in regards to keeping the local CRL updated. The text in 4.2 should be enhanced to reflect this consideration. We all know what disaster it is to have CRLs on client machines where we couldn't control such a conduct -- we shouldn't even try that again. Also, one has to weigh in risk into the equation. For instance, a service may trust the locally cached CRL for HTTPS handshakes, but make an extra OCSP query before processing a transaction worth > €10,000. This is of course under the assumption that the OCSP query would return a state that is fresher (more fresh?) than what's available in the local CRL. /Olle
Because this topic is somewhat related with the one we wrote you yesterday about Proxy Certificates you'll find some comments in the original text below. Regards,
On Jun 3, 2005, at 01:30, Mike Helm wrote:
I think it is hard to make one rite answer & don't have a strong opinion on this, but why _wouldn't_ the static info (local CRL) be the usual first test? Isn't it always the cheapest test? Since it should _never_ be better than the the OCSP check, checking it last seems useless unless (and only unless) all the OCSP responses are timeouts or unknown. So just do it first and then forget it (see above).
I'm not sure the gain outweighs the additional complexity. How many percent of the issued certificates are typically revoked? That's the maximum reduction of OCSP queries that you would get as a result. Plus, you have to watch out when encoding the logic: if you process the CRL first, the cert not being in the CRL should equal "unknown" and you should continue looking at other places; if you process the CRL last and the cert is not in the CRL, it should evaluate to "good".
For the proposed Proxy Revocation method using CertiVeR an "unknown" status for the Proxy Certificate will always be obtained from a CRL (as their revocation info is registered not in the CRL but into a Database for such purpose), so from this point of view there is an overhead if you first check with such CRL. Also if there are several CAs involved then you should check every correspondent CRL as there is not a concept like OCSP's Trusted Responder which serves several CAs. On top of that, if a CRL has a considerable size then its search/download process may become cumbersome. Remember that this is only a suggestion for the user/developer and finally OCSP options able to change such behaviour should be configured into the multicited policy (section 9).
IMO, it's only when you run a well-managed central service that you would really gain by query CRLs first, and assume that a non-entry means "good", as that requires proper conduct in regards to keeping the local CRL updated. The text in 4.2 should be enhanced to reflect this consideration.
However as you mentioned in the last part of your email, even this central service would have problems keeping fresher certificates status (when compared against OCSP).
We all know what disaster it is to have CRLs on client machines where we couldn't control such a conduct -- we shouldn't even try that again.
Also, one has to weigh in risk into the equation. For instance, a service may trust the locally cached CRL for HTTPS handshakes, but make an extra OCSP query before processing a transaction worth > €10,000. This is of course under the assumption that the OCSP query would return a state that is fresher (more fresh?) than what's available in the local CRL.
Which is mostly true when you combine OCSP with a mechanism like Delta-CRL. Now again the user should be able to change this default behaviour by customizing the OCSP Policy according to his needs.
/Olle
Regards, -- ____________________ Jesus Luna Garcia PhD Student. Polytechnic University of Catalonia Barcelona, Spain jluna@ac.upc.edu
Olle Mulmo writes:
On Jun 3, 2005, at 01:30, Mike Helm wrote:
but why _wouldn't_ the static info (local CRL) be the usual first test? Isn't it
I'm not sure the gain outweighs the additional complexity. How many percent of the issued certificates are typically revoked? That's the
In DOEGrids, about 1%.
maximum reduction of OCSP queries that you would get as a result. Plus, you have to watch out when encoding the logic: if you process the CRL first, the cert not being in the CRL should equal "unknown" and you should continue looking at other places; if you process the CRL last and the cert is not in the CRL, it should evaluate to "good".
I don't get what the problem is here. If the cert is revoked, it's revoked, and having successfuly made this test with the static information in a file, and matched, you are finished. Otherwise, proceed to OCSP, if available for this certificate. What's complicated about that? Otherwise, why even bother with the CRL's? The only useful case that emerges is the same one I cite above (a hit on revocation).
IMO, it's only when you run a well-managed central service that you would really gain by query CRLs first, and assume that a non-entry means "good", as that requires proper conduct in regards to keeping the local CRL updated. The text in 4.2 should be enhanced to reflect this
No, this "conduct" argument doesn't seem to be very relevant to me. So what if the CRL is 6 months stale? If the cert is revoked and so listed, you are done, and you have saved yourself the bother of a network query. In fact, you can test the CRL; you might like to have a test for nextUpdate (I mite reply to another message on this topic later time permitting) and skip CRLs under some circumstances. A complication, sure. I don't propose this behavior for standardization.
Also, one has to weigh in risk into the equation. For instance, a service may trust the locally cached CRL for HTTPS handshakes, but make an extra OCSP query before processing a transaction worth > 10,000. This is of course under the assumption that the OCSP query would return a state that is fresher (more fresh?) than what's available in the local CRL.
I don't follow this. Don't particularly care one way or the other, but I am prodding this argument to see if there's anything to it. Also, the "suspend" or "hold" feature muddies this area.
Olle Mulmo writes:
maximum reduction of OCSP queries that you would get as a result. Plus, you have to watch out when encoding the logic: if you process the CRL first, the cert not being in the CRL should equal "unknown" and you should continue looking at other places; if you process the CRL last and the cert is not in the CRL, it should evaluate to "good".
I don't get what the problem is here. If the cert is revoked, it's revoked, and having successfuly made this test with the static information in a > file, and matched, you are finished. Otherwise, proceed to OCSP, if available for this certificate.
What's complicated about that?
Otherwise, why even bother with the CRL's? The only useful case that emerges is the same one I cite above (a hit on revocation).
RFC2459 states the following: 5.3.1 Reason Code The reasonCode is a non-critical CRL entry extension that identifies the reason for the certificate revocation. CRL issuers are strongly encouraged to include meaningful reason codes in CRL entries; however, the reason code CRL entry extension SHOULD be absent instead of using the unspecified (0) reasonCode value. id-ce-cRLReason OBJECT IDENTIFIER ::= { id-ce 21 } -- reasonCode ::= { CRLReason } CRLReason ::= ENUMERATED { unspecified (0), keyCompromise (1), cACompromise (2), affiliationChanged (3), superseded (4), cessationOfOperation (5), certificateHold (6), removeFromCRL (8), privilegeWithdrawn (9), aACompromise (10) } Note that a CRL may (or may not) contain a CRLReason field which informs whether the certificates are revoked or suspended (onHold) certificates. A client can cache the information coming from a CRL safely only when ensuring that such information corresponds to revoked certificates. If CRLReason is provided in the CRL then it is safe to check a CRL out of date. The same happens with an OCSPResponse. Such response may also include the CRLReason field or not. It is only safe for the client to cache a revoked OCSPResponse when such information is present. Taking into account our previous premises, from the point of view of client's safety, it is the same to cache locally revoked OCSP Responses than CRLs. But from the point of view of client's efficiency, it will be faster to retrieve information from an OCSP local cache than from a full CRL (because a CRL may contain a large number of entries). Therefore, we suggest two options: Option 1: + Check client's OCSP local cache first. + Check local CRL. + Check remote OCSP Service. Option 2: + Check client's OCSP local cache first. + Check remote OCSP Service. + Check local CRL. Option2 may be more efficient than Option1 when CRLs are so large that it takes longer to check the CRL than querying the remote OCSP Service. Otherwise Option1 will be more efficient. Both options are fault-tolerant. Regards, Oscar & Jesus
"Oscar Manso" writes:
mwh> What's complicated about that?
mwh> Otherwise, why even bother with the CRL's? The only useful case that mwh> emerges is the same one I cite above (a hit on revocation).
RFC2459 states the following:
A client can cache the information coming from a CRL safely only when ensuring that such information corresponds to revoked certificates. If
point: most crl's issued rite now in grid CA's are v1. * We need a CRL requirements draft*
client's safety, it is the same to cache locally revoked OCSP Responses than CRLs. But from the point of view of client's efficiency, it will be faster to
(1) This argument was about _complexity_; I 'm going to take it that the complexity issue is dead (see options below) and the question remaining is when testing the CRL is safe and efficient.
Therefore, we suggest two options:
Option 1: + Check client's OCSP local cache first. + Check local CRL. + Check remote OCSP Service.
Option 2: + Check client's OCSP local cache first. + Check remote OCSP Service. + Check local CRL.
Option2 may be more efficient than Option1 when CRLs are so large that it takes longer to check the CRL than querying the remote OCSP Service. Otherwise Option1 will be more efficient. Both options are fault-tolerant.
(2) These are not fault-tolerant from the point of view of the client! Clients are off the net all the time, for a large number of reasons. The relying party decisions are often time critical -- need to be made now, not 2 hrs from now when the router is fixed and the remote OCSP responder is visible again. We have to agree on particular ways of dealing with unknown / unavailable OCSP responders (by "we" I mean the Grid community, relying parties and security folks) -- see other messages. (3) I'll accept your argument about which is faster, checking a CRL list or checking an OCSP responder service (reluctantly: in our environment, it's hard to imagine a scenario where it would make much difference). But I still don't see why, in option 2, there is even a check for CRL's. If the OCSP responder is always >= client up-to-date-ness, the only case where it would be checked, it's already worthless. The only case it would be checked is if the remote OCSP service doesn't provide an answer. (See (2) - requires a different strategy.) Suppose it's another case - the OCSP responder doesn't know about this issuer, so the replying party client has a separate CRL list. Then the client search algorithm wasn't optimal, and dealing with OCSP "unknown" response needs a different strategy too. Are there other cases I am not thinking of? * It seems to me we need to deal with the "Fail-safe" and status:unknown or non-responsive OCSP service some more.... (4) About CRLReason types As you mentioned here are the various revocation reasons in X.509/RFC 3280: CRLReason ::= ENUMERATED { unspecified (0), keyCompromise (1), cACompromise (2), affiliationChanged (3), superseded (4), cessationOfOperation (5), certificateHold (6), removeFromCRL (8), privilegeWithdrawn (9), aACompromise (10) } I don't understand all of these, and some of them may not have agreed upon meanings in fact :^), but the only one that can provide ambiguity in a CRL is the "certificateHold" or suspend - true or false? Will have to look at X.509 for clues about some of the others.
Clients are off the net all the time, for a large number of reasons. The relying party decisions are often time critical -- need to be made now, not 2 hrs from now when the router is fixed and the remote OCSP responder is visible again.
If a client is off the net, it is not going to be easy to validate a certificate on-line because only if the certificate is on the localCRL/OCSPcache the client will be sure of its status. Hopefully, most certificates being used should be valid. Therefore, they won't be present in the localCRL. The older the localCRL we are consulting the less reliable it becomes. There will be applications that will be able to manage perfectly with a delay of one day but others will need to validate the status of the certificate on real time. In order to do so, those application will be forced to connect to the net to do their OCSPrequest or read the lastCRL issued (which may have a long cautionaryPeriod).
We have to agree on particular ways of dealing with unknown / unavailable OCSP responders (by "we" I mean the Grid community, relying parties and security folks) -- see other messages.
Given the fact that client's requirements may differ, maybe instead of defining a general behaviour, we should encourage clients to specify their validation requirements in the form of a policy. (what validation services to contact, in what order, what QoS to request...) Such policy should also include what to do when the client can not contact with the outside world. Consequently, we believe that the document should present the user the advantages/disadvantages of using OCSP/CRL. In other words, to define a set of use cases and let the user decide what suits him best.
Therefore, we suggest two options:
Option 1: + Check client's OCSP local cache first. + Check local CRL. + Check remote OCSP Service.
Option 2: + Check client's OCSP local cache first. + Check remote OCSP Service. + Check local CRL.
Option2 may be more efficient than Option1 when CRLs are so large that it takes longer to check the CRL than querying the remote OCSP Service. Otherwise Option1 will be more efficient. Both options are fault-tolerant.
(2) These are not fault-tolerant from the point of view of the client!
Excuse me Mike, maybe I didn't pick the right word. What we meant is that the mechanism is fault-tolerant in the sense that if one validation source fails, the client can try to use the others. It is true that there will be cases when all the checks may fail but, as we mentioned earlier, the action to take will depend on the client's security policy. If you agree, we can develop a little bit more both options presenting the advantages and disadvantages of each in the form of an annex to the document. (4) About CRLReason types
As you mentioned here are the various revocation reasons in X.509/RFC 3280:
CRLReason ::= ENUMERATED { unspecified (0), keyCompromise (1), cACompromise (2), affiliationChanged (3), superseded (4), cessationOfOperation (5), certificateHold (6), removeFromCRL (8), privilegeWithdrawn (9), aACompromise (10) }
I don't understand all of these, and some of them may not have agreed upon meanings in fact :^), but the only one that can provide ambiguity in a CRL is the "certificateHold" or suspend - true or false?
We consider that in general this should be the only case unless the CA policy specifies other ones. This would involve modifying the OCSP policy.
participants (4)
-
Jesus Luna -
Mike Helm -
Olle Mulmo -
Oscar Manso