Name Constraints, was Re: [caops-wg] Re: ca signing policy file
David Chadwick
d.w.chadwick at kent.ac.uk
Wed Oct 12 12:57:26 CDT 2005
Mike
this is a very interesting viewpoint. What you are saying, if I put it
another way, is that everyone can have a completely random name, its
irrelevant what it actually is, as long as the user can authenticate to
that name (via signing something whose signature validates with the
certificate containing that name) and then as long as the authorisation
infrastructure can reliably get the set of attributes that are bound to
the same name, then correct authorisation can be performed, regardless
of the name of the user. In which case name constraints are irrelevant.
I would agree with that
regards
David
Mike Helm wrote:
> Von Welch writes:
>
>>I meant to say that unless NameConstraints are adopted by CAs in
>>general (which probably means both "Grid CAs" as well as all the
>>various software packages our communities use to generate
>>certificates), we still need something like current ca signing
>>policies (i.e. relying party-specified name constraints).
>
>
> I don't think name constraints, in general, no matter who does them,
> are worth the slitest amount of our attention. They don't solve
> any problem that anyone actually has. (I think this is one reason
> rfc 2459 name constraints took so long to get any support.)
>
> This is particularly true in grid environments where the authentication
> and authorization has been separated.
>
> What we do need, just like in any other pki, is some way of stating
> whether or not a CA is trusted, and for what purposes (cert types).
> If "purposes" includes naming, fine, but I don't think that
> should be its primary or only method. One purpose might
> be "any" or "none": A scheme like that would
> be very useful to the middleware: you can distribute a large
> number of CA signing certs and make it easy for the
> relying party to configure the CA trust list. (Most of our
> current CAs are grid-only.)
>
> The current signing policy file is useful, in that it puts a brake
> on what is going to be trusted, but the only decision it allows
> is based on naming, which I contend is useless, and forces people
> to deal with an inherently clumsy syntax that has been dis-optimized.
>
> A side effect is that it places a huge emphasis on naming in Grids,
> which is a waste of everyone's time. We should be free to use
> whatever naming is appropriate and not jam ourselves into narrow
> naming rules so that we don't disturb the delicate naming policy
> rule distributed everywhere. Since names in grids have no inherent
> meaning and we have authorization schemes to enroll and control
> privileges on successful authentication, the name constraint in Grids
> doesn't add anything. I also think this is functioning as a
> market inhibitor, in that CAs that don't fit this pattern such
> as commercial CAs or other schemes are kept out of the business.
>
>
--
*****************************************************************
David W. Chadwick, BSc PhD
Professor of Information Systems Security
The Computing Laboratory, University of Kent, Canterbury, CT2 7NF
Tel: +44 1227 82 3221
Fax +44 1227 762 811
Mobile: +44 77 96 44 7184
Email: D.W.Chadwick at kent.ac.uk
Home Page: http://www.cs.kent.ac.uk/people/staff/dwc8/index.html
Research Web site: http://sec.cs.kent.ac.uk
Entrust key validation string: MLJ9-DU5T-HV8J
PGP Key ID is 0xBC238DE5
*****************************************************************
More information about the caops-wg
mailing list