Hi, I think I understand all 3 sets of questions, so let me give it a go: On Oct 13, 2005, at 9:16 PM, Von Welch wrote:

After reading through this long, interesting conversation, I would like to suggest the following questions to frame this discussion. Von

1) What CAs do we wish to consider as potential issuers for our community? Is it just "Grid CAs" (by that I mean CA we can reasonably except to adhere to best practices as specified by GGF WGs) or do we want to also consider CAs that we have no reasonable expectation of being able to impact their policies or procedures (e.g. commercial CAs) as potential issuers for our community as well?

We have explicitly drawn up an agreement among the major grid CA providers and relying parties (that's to say, suppliers and consumers of grid certificates to the largest grid projects, not saying anything about the size of the CAs) that covers the trust relationships between these parties in terms of policies on identification and CA issuance when used in these projects. This is encapsulated in the form of the IGTF and its member regional PMAs, and authentication profiles that cover the policies of these organizations. When you say "our community" and if we take it to mean the larger community of current and potential grid users, I think to the extent that this means other conditions for how these certificates are issued and used, that this calls for another authentication profile. Part B of this answer might be "we think the policies of the present CA issuers encompassed in the IGTF at the moment, although they are constantly being improved, but recognize that further authentication profiles for other uses might require different policies and possibly another subcategory of membership and use." (This is my opinion, obviously, and not an attempt to state policy on behalf of the IGTF or any of its members; just to continue the discussion.) Note that ALL of the points you raise in the above 2 questions have to do with authentication.

2) Do we believe that during normal operation the CAs indicated in the response to the first question have policy that will result in their issuing globally unique names and will reliably follow that policy?

See above. Attempts have definitely been made in this direction.

3) If a CA is compromised, given currently implementations, this will result in the compromise of all certificates issued by that CA. An additional threat that a CA compromise would result in, is the compromise of privileges bound to certificates issued by other CAs, at relying parties that trust the compromised CA. Is this threat of concern to us?

I parse this as follows, and give the answers: (a) of course, and that is the basis of all of the planning up to now -- to be able to drop a CA without impact on the other CAs, or just a certificate if only one or a small number have been violated, in terms of _authentication_. For the second part, (b) Privileges bound to certificates are clearly in the authorization framework, which is still being written and has multiple implementations, so your answer is clearly implementation-dependent. In terms of VOMS and GUMS, for example, if a user presents a certificate to either server from a CA that it knows to be bad, all processing stops. In other implementations I am not enough of an expert to know (i.e., I don't know at all) what the answer might be. In most cases, simply not receiving a CRL update in the required time would be enough to invalidate a CA and all certificate processing based on it that is part of the privilege project / OSG architecture. The timescale of enforcement and the response of each VO and relying party are topics for another discussion, some of which has already been held. I could go on to suggest that another set of questions could be framed as follows: 4) Given that some interest exists in extending the present CAOps model to cover or encourage discussion along lines that would include authorization, would it be appropriate to be discussing an authentication profile that would be based on policies that extend some of the desired protection against potential CA compromise into authorization space, as possible extensions to the existing classic PKI and short-term CA profiles currently adopted or being considered, or as a new profile that might be proposed with this in mind? And 5) What is the approach that would encourage careful thinking in this area best? Just my NSH opinion, Alan