[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Name Constraints, was Re: [caops-wg] Re: ca signing policy file

Frank

random is different from unique. If the random name is also unique (or has a statistically rare possibility of collisions) then the CA name is irrelevant isnt it? Since every CA can then have the full name space to allocate within and there is no way of partitioning it.

regards

David

Frank Siebenlist wrote:
When you say "name collisions", you must be referring to either compromised CAs or errors as name collisions should not occur...

By using both the Subject's DN as well as the CA in the authorization policy, you're essentially negating the ability of the PKI to define global names: if you believe in the pkix/x509 religion then after the path validation, the CA falls out of the equation.

Now Mike's idea of using some random names for subjects is good but doesn't solve the problem as it would still allow any "trusted" CA to bind a different key to the same random-name.

Maybe random names for subjects should be used together with name constraints.

In other words, the Subject's DN should start with an identifier that essentially identifies the administrative domain in which the names are issued, e.g. \DOMAIN=ESNET.NET, followed by a \CN=abbf16d0-3b5f-11da-8cd6-0800200c9a66
In that way, a CA could be restraint to issue random names within a certain domain.

-Frank.


Cowles, Robert D. wrote:

The name constraints are important because the gridmapfile doesn't
contain the CA that issued the DN, only the DN. Therefore, name
collisions can occur and cannot be detected. If we make sure that the middleware includes a check of the CA when it compares
on DN, then what you say is correct.


-----Original Message-----
From: owner-caops-wg@ggf.org [mailto:owner-caops-wg@ggf.org] On Behalf Of David Chadwick
Sent: Wednesday, October 12, 2005 10:57 AM
To: helm@fionn.es.net
Cc: Von Welch; Tony J. Genovese; 'Frank Siebenlist'; 'CAOPS-WG'; 'Olle Mulmo'; 'Joni Hahkala'; 'Jules Wolfrat'; 'Ron Trompert'
Subject: Re: Name Constraints, was Re: [caops-wg] Re: ca signing policy file

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

*****************************************************************





--

*****************************************************************
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@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

*****************************************************************