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

Cowles, Robert D. rdc at slac.stanford.edu
Thu Oct 13 22:47:31 CDT 2005


 

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

I think that if we are successful, all this will be used in ways
we can't now imagine or, in the future, control.  To me, the idea of 
depending on CA's to issue certificates for DNs that are globally
unique is just asking for trouble.  Administrative controls to 
keep the namespaces separate are clearly not good enough. The signing
policy file is a technical control but it still seems pretty weak.
To me, the thing that is unique is (DN + CA) and the function of the
CA is to try it's best to not issue a cert with the same DN to 
different people. I would be happy if they can do just that and I
think it unreasonable to believe that the DN is unique in the 
universe (or even a small section thereof).  The signing policy
files basically allow us to say - given this DN, it should have been
issued by that CA - and as far as I can see, it's because the CA
is't stored in the gridmapfile (and maybe it's not there because
the DN was suppoed to be unique - but that was8-10 years ago, and
we know better now).

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

I think it's not true in "normal operation" and that any moderately 
talented attacker would be able to generate a condition outside
of "normal operations" and get *someone* to issue a certificate
with any DN they chose.

> 
> 3) If a CA is compromised, given currently implementations, 
> this will  

(my comments here were in an earlier email).





More information about the caops-wg mailing list