CAOps now is under community area, not under Security area!! Ollie - OCSP draft Similar to Chicago meeting (GGF 14) Special issues on proxy certificates - wrap up here Suggested approaches: Multi-level delegation - OCSP check will be done at higher level of proxy, so if invalidation occurs at a lower level, it will kill the whole branch Which OCSP responder to trust? When proxy uses AIA extension (=URL added), have to provide intelligence to OCSP objects that identifies the appropriate response and ensures authority of signer is appropriate. Requires special software at OCSP level, or use some portion of AIA URL and make sure that OCSP signing certificate had corresponding name (yuck). Best way is for user to delegate a proxy cert to OCSP responder in such a way that the cert has OCSP signature info. Can have multiple URL's in one cert or proxy. Essentiallly this is a bucket of URL's and info on what will be found at these URLs (note not CRL's!). Clients can try these sequentially; some undefined logic is implied here. Requirements doc just says process them one by one. A management interface is required for the OCSP responder. Next steps: add the above, and try to get final comments from list. Then ready to send to GGF editor and ask for public comment. Milan - One-statement security policies e.g.: "This certificate was issued to a software agent, not a person." Hope for update by next EUGrid PMA meeting. Example template and draft should go to CAOps also. Should this be a GGF document? Policies should be issued / managed by PMAs Namespace policy Triggered when new CA in EUGrid PMA was tried that had a complex hierarchy including signing policies. Switch (Swiss national something) overlapped with a CERN-based namespace. RP's need a means to enforce unique subject names from identity providers and federations. Q. from Ollie: does this include intended use? A. from David: there are some references in the document about this. Current implementation has extended-ACL expressive syntax, but only thing implemented is <=1023 characters and recognized assertion. Contrast with Java world -- need to define format. Document is intended to cover requirements: should be able to assign multiple allowed namespaces for a given CA. Wildcards should be allowed anywhere, not only at end of names. Could support dynamic CA hierarchies. Subordinates should be replaceable. Representation should be compliant with RFC2253. Q. from Darcy: Is this backwards-compatible? A: should have new policy file with new name; distribute 2 formats in parallel. Redundant? No, because older, non-RFC-compliant implementations exist (cf. UID= vs USERID= problem from openSSL versions in recent past). Examples given in David's presentation -- see transparencies. Q. from Darcy: Is this more appropriate for Grid or IETF? Sentiment seems to be to at least identify and propose solution; standards bodies themselves can then decide where to accept it. All agree we are mixing a few topics here. Are we sure that we need to have this at the CA level as authentication? Appears so, as this is really about limiting characteristics of information presented by CA in order to assure uniqueness and completeness. Goal is to limit the namespace to that portion guaranteed to conform to the trust relationship at the specified level. Christos has placed the document on Gridforge -- people should read and comment. David says this is still a very rough draft. Who is going to do the mission work for the middleware providers? Has already been raised with GT and EGEE -- who else? Should be on relying party side, not on identity provider side. Ollie: how about openSSL? (Related Q. from Alan: how about BridgeCA community?) Darcy reiterates that this really might need to go to IETF. Christos, Jim: need to validate/demonstrate that this works first.