[caops-wg] Name Constraints - attempt at framing issues

[Alan Sill]

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