June 2005 - caops-wg - lists.ogf.org

OCSP - fault tolerance
by Olle Mulmo 04 Jun '05

04 Jun '05

> *Fault tolerance &al is mentioned but I don't think it is discussed > (maybe indirectly in config rec on p 9) > In part, we can deal with this in the client by making them more > robust as discussed above. Perhaps at the end of #5 a section about > fault tolerance or high availability: Fault tolerance is currently covered by a footnote in section 7... a bit minimalistic. A new section 5.x sounds like a good plan, although I think the text below is not intended for all kinds of responders but rather that of root CAs and transponders/global redirectors? > OCSP responders should be configured on a server with high > availability capability: redundant, failure-correcting/responding > hardware components. The OCSP responder system should be configured to > automatically recover and continue from a single failure of disks > supporting the current OCSP database, hardware security module, or > other critical system component. This might be particularly important > for OCSP responders that operate in whole or in part in transponder > mode. > In order to deal with site failures or network partitioning, OCSP > service providers should provision multiple, topologically and > geographcally dispersed OCSP responders with mirrored OCSP databases > and configuration. If possible, WAN high availability capability > should be employed.

3 3

Re: [caops-wg] OCSP requirements - final(?) version uploaded
by Mike Helm 04 Jun '05

04 Jun '05

Forgot 2 things: p4 While OCSP supports querying of multiple certificates in a single request, it is rarely used in practice or even supported in common off-the-shelf implementations suggest We recommend that developers of OCSP responder software for Grids support multiple certificate queries in their products. We enourage? recommend OCSP service providers provide this support also. [This is another complication that needs to be added to the discussion in 4.7; don't think I hit it] 4.7 - discussion about delta CRL's. 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? There is a need for a CRL req doc to pick up the more detailed argument.

3 5

RE: [caops-wg] OCSP section 4
by Cowles, Robert D. 04 Jun '05

04 Jun '05

> 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. The hits on the local CRL are a function of USE of a revoked certificate, not he EXISTANCE of a revoked certificate. I would expect the use to be ver much lower than the existence number. Bob Cowles

1 0

OCSP section 7
by Olle Mulmo 03 Jun '05

03 Jun '05

> --In the last paragraph on page 9 we propose to clarify the text > "...incoming OCSP request in turn copied by the OCSP client from the > subscriber certificate that is currently being validated." changing it > with the following "...incoming OCSP request specified by the client > according to the AIA extension in the certificate that is currently > being validated". > --In the second paragraph on page 10 the text "...may join efforts and > set up a shared Trusted responder that serves requests on behalf on > all of the CAs", from our point of view if a set of CAs will trust in > a Responder then it becomes an Authorized Responder. What I'm saying is that the CAs may set up a responder that works in Trusted mode -- not that they themselves trust the responder! Here, I was thinking of e.g. the ESNet OCSP service responding to queries for many (all?) of the GridPMA CAs, or a root-level responder answering to all queries in a PKI hierarchy: in both cases, for the responder to be called Authorized, each and every CA in the PMA/PKI would need to issued an OCSP signing certificate! In regards to hierarchies, this is IMO a shortcoming in the RFC, and some OCSP profiles (such as Identrus from the banking world) augments the RFC on this point, to allow for an OCSP responder that is issued an OCSP signing certificate from the root CA to be regarded as Authorized for any certificate in the whole hierarchy. Text should be added in this regard. > * We have been analyzing the new diagram in figure 1 and we find that > we would need to clarify the trust relationships among the different > components that are presented. Good point. > -- At then end of definition 7.1: "The CA trusts in the Authorized > Responder as a source of status information for the certificates of > its own hierarchy . On the other hand, if the Client does not trust > such hierarchy then it will not trust in such Authorized Responder". Equivalent text has been added, although the part about hierarchies in the first sentence is not true: see comment above. The last sentence seems like a rather superfluous comment: if you don't trust the CA, you don't trust the responder that is has designated as authoritative. > -- At the end of denifition 7.2: "The User trusts in the Trusted > Responder as a source of status information for the CAs hierarchies > which it has configured. However these CAs will not implicetly trust > in such Trusted Responder". Equivalent text has been added, although the part about hierarchies in the first sentence is not true: see comment above.

2 1

OCSP section 2
by Olle Mulmo 03 Jun '05

03 Jun '05

> * In section 2 (former section 3) the following text was removed: > "Grid’s Virtual Organizations may contain more than one CA, so > establishment of OCSP Authorized Responders between them is essential > to provide an interoperable service." When we proposed such change we > were thinking in the importance of highlighting the co-existence of > multiples CAs into the same VO as a practical challenge for Grid OCSP. > What do you think? I don't understand what this text is aiming at. Is it only to establish the fact that we operate in an environment with multiple trust anchors and that these need to be federated through e.g. a PMA, or is there something else between the lines? "Authorized responders between them"... are you thinking of some cross-certification / bridge scenario? /Olle

2 1

OCSP - use of nonce
by Olle Mulmo 02 Jun '05

02 Jun '05

> There are a couple of remarks about nonces that I think the > sophisticated security worker - especially some of the ones I was > hoping to interest in this service - would not agree to. I have no > problem with the language in 4.5 but the client recommendation > somewhere in section 7 just says flat out don't do it -- seems > contradictory. There are circumstances where real time is needed. We > need a nuanced nonce instead. The intended spirit of Section 7 was to say don't do it -- by default. Your suggested modifications below will be incorporated. > > In 7.3, say > OCSP clients are not recommended to include nonces except ... - or - > OCSP clients should only include nonces ... in requests to local > Trusted responders or other OCSP responders by prior agreement and > consultation. (See section 4.5.) > > In 4.5 say > Some services may not support nonce requests, and in other cases it > may produce intolerable burden on the OCSP responder and delay for the > client application. Nonces should only be used in situations where > the most up to date information is required, particularly to meet > security requirements. > > [Drop the "overkill" sentence - not useful.]

2 1