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

Agendas for GGF
by Darcy Quesnel 20 Jun '05

20 Jun '05

I've asked for three slots at the next GGF. The first session will deal with regular CAOPS business: - discussion of the latest OCSP draft (thanks Olle!) and maybe: - an auditing check list for CA's by Yoshio? and Olle has suggested: - XKMS, who will explain this to us? - some discussion is needed of site-integrated credential stores (KCA, etc.) and their operational concerns Is there anything else anyone would like to add to this? There are also two other sessions, one for discussion of International Grid Federation issues, and one for discussion The Americas Grid PMA issues. Any ideas for the agenda of these are also welcome. Darcy

2 1

OCSP section 4
by Olle Mulmo 14 Jun '05

14 Jun '05

> 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?

4 10

OCSP - proxy certs
by Olle Mulmo 10 Jun '05

10 Jun '05

> > *Section 5.5 talks about support for proxy certs. I obviously don't > think it is out of scope - we MUST talk about it - but it is > indisputable we don't know how to deal with them. But punting > completely is leaving a lot of the potential value added of Grid OCSP > out. You are right. Your suggested text (cut) will be added. > We might also want to tell developers and OCSP client configurers > OCSP queries on proxy certs are NOT RECOMMENDED and should > be avoided, except by prior agreement and consultation with > specially configured OCSP responders that can deal with them. Yep. > *Section 5.3 > The sources must be properly protected against malice use.... > Suggest [maybe it's overload] The text below sounds fine to me -- with a reservation for replacing some of the wording with MUSTs. > The OCSP responder database must be protected properly. In most cases > the database will be updated automatically, and adequate change > control and logging must be used to ensure data is obtained and loaded > from a trusted source in a timely fashion. Signatures on CRLs must be > checked and CRLs must be refreshed in a timely fashion. OCSP > responders must ensure that proper change control and access controls > are in place to prevent unauthorized addition or removal of > certificate status information from the database. This is > particularly important to any OCSP service providing experimental > support for proxy certificate verification (see section 5.5). ... > Customer expressed interest in dealing with proxy certs. > The situation seems to be that in practice a chain of certs is > available, from the EE to the last proxy cert. Our experimental > responder didn't deal with that well, apparentlhy peeling off the > first one and skipping any others (first one being the last proxy > cert). > > The standard reads (to me) as ambiguous about this, which surprised > me, because I expected the above behavior: > (RFC 2560 page 2) > > The response for each of the certificates in a request consists of > > -- target certificate identifier > -- certificate status value > -- response validity interval > -- optional extensions > > Is this a bug in the spec, or the implementation? What is the > OCSP server "art" on this since this spec came out? There is a > remark about this somewhere in section 3 - it seems to be > sort of out of place. I don't follow. There's definitely not a bug in the spec: a response has issuer producedAt timestamp array of certificate status responses nonce if provided, and other extensions signature where the array of certificate status responses contain the things you list above, for each certificate that status was queried for: identifier of the cert (hash of issuer name + serial#), it's status (good/revoked/unkown), how long this status is valid for (e.g., the thisUpdate/nextUpdate fields of the CRL), and possible extensions (e.g. revocation reason codes, the location of the CRL that was consulted, ...). I would say that your responder got confused up by the proxy certs. Possbily also that that it is one of the responders that cannot handle multi-certificate requests (array count > 1). /Olle

3 5

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

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

OCSP document - proxies and delta CRLs
by Olle Mulmo 31 May '05

31 May '05

> * Page 7, section 5.5: the paragraph suggesting the use of Delta CRLs > to obtain Proxy Certificate´s status has been deleted ("Another option > refers to using OCSP in a Push Operation Mode as mentioned in section > 6.3, where relying parties SHOULD obtain revocation information > through its OCSP service provider as soon as it is updated by the > corresponding CA through Delta-CRLs"). Only as a way to let the reader > know about this possibility, don't you think that it is worth to keep? For an EE to "register" a proxy certificate with an OCSP responder, we will require a protocol, and/or extensions to an existing protocol. Why cannot the "disabling" of a previously registered proxy cert use the same channel? The two operations are about making changes to the responder's revocation database, so for me it makes sense to have them tightly coupled. I don't rule out the use of Delta CRLs, but a Delta must be built relative to a full CRL, which must be referenced. What is the full CRL of an EE? In addition, support would have to be added in the responder validation routines to allow EE (or proxies thereof?) certs to sign CRLs. Overall, this smells too much of a hack to me. /Olle

1 0

OCSP section 5.1 - key protection
by Olle Mulmo 31 May '05

31 May '05

> *5.1 > While we do not require the use of hardware protection, > we RECOMMEND that the security of the OCSP responder key > be in parity with the CA issuing key. > > [This is a meaningless recommendation, because we have no single > standard for CA issuing keys. Also, there are differences in the > way OCSP and CA issuers are handled - you can change the OCSP > key pair every hour if you want. Disagree about HSM. Reading the text again, I realize that I had Authorized responders in mind. What the text says is that there should some correlation between how securely you operate your CA, and how securely you provide current status of those certificates. This comment should be expanded and moved elsewhere. I have no problems adding your suggested text: > Access to OCSP responder keys must be carefully controlled. > In all cases system level access to OCSP responder systems must > be limited and logged. Access to key backup media must also > be limited and logged. For OCSP responders using software crypto > stores, we recommend that this key NOT be backed up. We also > recommend the key be changed more frequently than end user signing > keys. > These steps can reduce but not eliminate the demand for hardware > crypto stores; hardware security modules should be used for high > visibilty OCSP responders (see also prev paragraph?). > Service providers should also consider transponder configurations > to reduce the number of highly secured OCSP responder keys needed.

1 0