GGF9 CA Ops WG Meeting Mon Oct 6 2003 10:00-11:30 Agenda: 1. WG admin: a. Discuss change in co-chair b. Related BOFs/WG/RGs i. Federation BOF ii. Authority Recognition Research Group 2. Review minutes of Last meeting 3. Last call documents update a. PKI Disclosure Statement b. Automated Client Certificates 4. Document review a. Discuss updated Policy Management Authority Doc b. Discuss future of Certificate Profile Doc c. Discuss future of Grid Common Ca Naming practices 5. Working Group future efforts Minutes: Tony reviewed the agenda. Tony found a second note taker. No objections to minutes from last meeting. Darcy Quesnel is new WG co-chair. Randy Butler has retired. Darcy discussed new proposed draft GGF IP agreement. GridForge site has been updated with new features. Please sign-in, make a login. You can register for notifications. Tony has moved documents from es.net web-site to gridforge site. CA Ops mailing list is the same. No plans to migrate mailing list to gridforge. Question: Does gridforge do document management? Yes. Best practices document for GridForge will be released soon. Tony highlighted federation BOF, noon tomorrow in Huron. Paul has a research group on alternative governance. 6pm tonight in Ohio room. Last call documents: PDS and Automated Client Certs PDS document has been submitted. Should be going to final comment period. Work has been done on the Automated Client Certificate document. Discussion about adding an extension to the certificate. Use DN to specify a robot certificate. SubjectAltName specifies responsible person. Question: How does it relate to the AIA field? AIA field is becoming the lynch-pin of bridge PKI. Parsing AltSubjectName is difficult because it's used for many different things. AIA is typically used to find CRLs/OCSP. Comment: X.509 says you're binding SubjectAltName to the keys. Implies the key stands for the owner. Document should explain this, that the DN is an alias for the robot owner. Use the URI version of subjectaltname? A URL to a web page that lists contact info for robot administrator. This document is at last call state within the working group. Document Review: - Policy Management Authority - Grid Common CA Naming Practices - Zero progress in 1 or 2 meetings. - Certificate Profile Tony asks: Do we consider these documents valuable? As a WG, will we make progress on these documents or should we cut them? Need co-authors. Mike Helm reviewed documents. Grid PMA Charter Started out as slides by Peter Geitz. Idea of GGF-run PMA not accepted by GFSG. Tried to make document more generic and submit to last call. Document sent back, still had references to the one true GGF PMA. Bob Cowles, Peter Gietz, and Mike did some editing. Latest version is on the GridForge site. Changes: - More general abstract - Directory references - Extensive changes throughout sections 2-4 - Language, wording, clarifications - Editorial changes: rewrote introduction PMA is in charge of policy document(s). The CP is not static. New issues come up. Need a mechanism for CP change --> PMA. Changes: - Intro: Deleted obsolete, GGF PMA language; now describes problem, justifies work better. - Section 2 Scope: Removed some intro material. Is the balance correct? - Remaining sections: Editorial changes - Suggestions: Decided to delete most of these (for now) - Latitude for PMA to decide on its own (By-Law structure) - Wasn't interest or time to expanding on known PMAs Plans: - Convergence by authors - Discuss how PMA membership changes more thoroughly. Just say that by-laws must cover that in PMA rules of governence. Note that problems do arise, succession is important, PMA should cover it. - Issues raised by US Department of Energy Certificate Policy CP 1.3.1: Naming Authority Might be worth mentioning as material to consider. Converge soon. One final editorial pass. Move to last call fairly soon. Need feedback from working group. Please review it. Could get out for last call before GGF-10. Grid Certificate Extensions Profile document. Thesis: consistent usage of X.509 extensions promotes interop. What is the minimum? CA operators put extensions in their certificates, some of which are now obsolete. Interactions: - Proxy cert draft/support - Cert types/usage - Requirements in XML-based solutions How does it relate to automated client certificate document and proxy certificate documents? Should this be a collection of profile documents? A registry of certificate profiles? Can we register our certificate profiles like we register OIDs? For example: VOMS has its own attributes. LCG has an extended proxy with authorization information. CAS adds a SAML extension. Need standardization for interoperability. Current draft is focused on identity certificates. Focused on minimal set of extensions you must have in identity certificates. Still conflict in PKIX on meaning of certificate extensions. Example: subjectAltName. Is it fatal? EDG works OK with many certificates with different extensions. GSI doesn't look at many extensions. How does it work for EDG? - All X509v3 but different extensions. - 19 issuing authorities. - None of the extensions are marked critical. Why do they include extensions not marked as critical? Some of it is an accident of history. Whatever is default for your CA software. Need to standardize how to include attribute certificates in proxy certificates. Similar to how GSI includes restrictions. Do you include certificate for issuer of attribute certificates? Other authors volunteer to work on this document? What is the intention of this document? - Looking to have a profile document that includes other profiles? - Create a mechanism for publishing profiles? - Current version focuses on minimal set for identity certificates. It should be a standards document, rather than an informational document. Right now we're chained to OpenSSL, with a limited implementation of X.509. New software will bring new issues. How difficult is it to change certificate format? Need to re-issue new certificates under new format. Can be expensive. Will minimal set be the empty set? Perhaps. Does Globus require the netscape extensions? Don't know. Shouldn't require significant changes to how CAs do business. Requirements on the identity certificate will be mapped into proxy certificates. Vote: Is this valuable? Some hands were raised. Who can help? No volunteers. Community practice or standards document? Describe what is being used today and what extensions can cause problems. Does consistent use of an extension give a new capability? Value added? Today, GSI is based on subject name only. OpenSSL and GSI hide the extensions. OpenSSL doesn't force checking of extensions. GSI defines callback function. It's no longer true. GSI defines a call-out for looking at whole certificate in application-level code. Markus uses it for extracting attribute certificates. We should look forward at what capabilities would be possible if we had standardization. Talk to OGSA AuthZ WG. Ask that group to review this document. If interpretation of extensions is standard, then AuthZ services can rely on it. Mike feels AuthZ extensions are out of scope for this document. Don't want to increase scope of the document to the point where it can't be finished. Call for volunteers. Steve Chan, Markus Lorch, Von Welch, and Tony will review the document. Should we have a separate document for proxy certificates? What can the AuthZ depend on from authentication layer? Get requirements from AuthZ community on identity certificates. We include a lot of additional info in the X.509 certificate because TLS doesn't allow us to send additional certificates/credentials. Grid Common Naming document. Consistency about URLs of common CA information would simplify decision making process and operations. Create a best practices recommendation. Complement cert extensions document. Where are we? Version of document on GridForge needs revision. EDG has a site that publishes all CRLs, CPs. Example: es.net/CA. doegrids.org/CA. Experience with EDG is that sites named CA info differently. Would make pan-European CA registry easier to maintain. Is there interest? 3 hands raised showing interest. No volunteers for co-authors. Not a lot of interest in the working group. Tony reviewed status. Grid PMA is available for review. Work on Grid Certificate Extensions Profile will continue. Grid Common Naming will be completed by Mike. Open discussion of areas for future work: Simple Certificate Validation Profile (SCVP) (Mike Helm): Experience with roll-out of new CA highlighted issues. Example: Globus signing-policy file is error-prone. Lesson learned: GSI/OpenSSL doesn't scale. Distance between CA administrator and relying parties is large. If there is any problem with delivery of CA info, the GSI environment fails. (Error messages are poor. Difficult to correct errors.) Client-side must be perfect. Client-side configuration is difficult. Result: Makes it difficult to deploy new CA. Fear of change. KX509? Doesn't resolve this issue. Globus CA certificate expires in January! Globus doesn't get deployed to the clients. - Windows machines. - End users can't install/configure. IETF-PKIX working on SCVP for client to offload certificate handling to a server. See IETF Delegated Path Validation and Delegated Path Discovery Protocol Requirements. DPD - data acquisition DPV - evaluation Can this PKIX effort help us? - Asks the right questions. - Reflects some industry interest in "our" problem - DPV/DPD and SCVP represent a lot of work on solution - SCVP seems capable of more flexibility Negatives: - ASN.1 - Public domain support lacking - Industry support is a question - Conflict with XKMS Ken: Is the problem that we're trying to pass dynamic attributes in certificates? Compare with SAML / Federated model. Can we break out of the X.509 framework? Markus: Attributes are in proxies, short-lived containers. We're not passing them around in EE certs. Even with SAML, still need to worry about trust. X.509 proxy certificates aren't going away. Attribute certificates and SAML have similar issues: validating signature, checking for revocation, trusting the authority. What should the WG do? Not clear that SCVP is the right solution. Is this a specification problem or an engineering problem? Would it be beneficial to have a recommendation in this area? No consensus. Ran out of time.