Von Welch wrote:
David,
I think I see what you're getting at, but before we could add
something like this we need to get our own story straight re
subjectAltName.
I think we're all assuming a subjectName and DN. What should the
right behavior of software be that is responsible for enforcing
name constraints when it encounters something else?
Von
name constraints are meant to constrain names. i.e. if your certs
are not within this permitted domain, then they are untrustworthy.
Thus if you encounter a cert with an alternative name and no name
in the trusted domain, then it should be rejected out of hand. It
does not fall within the scope of your constrained names
regards
David
I'm not sure if it
should ignore or error out off hand.
Von
On Oct 10, 2005, at 4:55 AM, David Chadwick wrote:
Von
thats a nice summary of why you have put name constraints
outside of the certificates. I might add another reason for
keeping it this way, and that is that RFC 3280 allows the CA in
the trusted domain, to blow the trust bestowed in it and issue
certificates with a different name form and then the certificate
will be trusted (e.g. give an email address to someone using the
subjectAltName extension, instead of a DN, because their DN is
outside the name constraints).
regards
David
Von Welch wrote:
Here's a first attempt at explaining the relationship to Name
Constraints - Von
Comparison to RFC 3280 Name Constraints
To understand our motivation for the creation of this
specification instead of using Name Constraints as defined in
RFC 3280 (section 4.2.1.11), one needs to understand the
differences in models between what PKIX envisions and what is
in use in the Grid.
The PKI model envisioned in RFC 3820 is that each relying party
will be part of a domain which has a CA associated with it.
Any decision by that domain to trust another domain, and its
associated CA, is instantiated by the CA of the trusting
domain to cross sign the CA of the trusted domain, creating a
new certificate for the trusted CA which will be used in the
trusting domain. Trust can then be limited by using the Name
Constraints extension in this new certificate, limiting trust
by relying parties in the trusting domain and allowing the
trusting domain to manage its view of the global namespace and
ensure uniqueness of names.
In the Grid model, relying parties make trust decisions
directly by installing the self-issued certificates from CAs
in their system configurations. There is often not a domain CA
which can sign the trusted CA and there are issues with
current open source path validation software which also make
this approach problematic [1].
The result of this is the need for mechanism for a relying
party to specify their own policy on constraining what names
they will allow a trusted CA to issue, which in turn allows
them to manage their view of the global namespace in order to
ensure names are unique. This specification is aimed at such a
mechanism.
[1] J. Jokl, J. Basney, and M. Humphrey. Experiences using
Bridge CAs for Grids. Proceedings of the UK Workshop on Grid
Security Experiences. Oxford 8th and 9th July 2004.
http://www.cs.virginia.edu/~humphrey/papers/
BridgeCAGridSecWorkshop2004.pdf
On Oct 7, 2005, at 8:08 AM, David Groep wrote:
Hi Von, *,
Von Welch wrote:
First a meta question - shall we move conversation to the
caops email list?
Yes, done, and set the reply-to address there as well.
Onto the document:
I find the language in the document is really odd in that it
talks about "Authentication Identifiers" and "Issuers".
Particularly if this document is going to end up in CAOPS,
shall we not just bite the X509 bullet and say "X509
certificates" and "CAs", etc. I think it would make the
document much more clear.
I actually agree (it's just the habit that crept in here). I also
think that the "namespace constraints policy collection
(file)" should
just be "namespace constraints file" or something similar.
I think one question the document should address is why not
use RFC 3280 Name Constraints? I think this mainly boils
down to the fact that while they look suitable, they are
intended for bridging situations and we'll never get
commercial CAs to adopt them, hence always limiting
ourselves to "Grid CAs". If everyone agrees with that
statement, I'll plan on contributing some prose.
I've a few other reasons to add to this as well:
For nameConstraints in the certificate itself is that it's the
"wrong"
authority makiong the assertion. For these namespace policies,
it's not the
CA itself but rather the distributor or federation that makes
the claim.
The example again is SwissSign. In the federation, their
(top-level) CA is limited to signing only the "Bronze" CA. This
constraint is coded in the namespace constraints file. But of
course,
they'll never but in a nameConstraints assertion in their top-
level
limiting it to Bronze only :-)
Also, only a subset of the certificates issued by a CA may be
part of the federation, and limiting the namespace is a relatively
straightforward way of doing that (instead of having to introduce
a subordinate CA for that).
In all cases, the namespace constraints should be outside of the
certificate chain of the constraint CA.
With regards to the example policy, I think the question
needs to be asked - why not use XACML or some other
standard policy language? I suspect its an attempt to
address requirement #5 - human readability. Seems like one
could write a tool to display XACML in a context like this
nicely, so I think we need to ask ourselves if we really
want to define a new language.
The other problem will be on the implementation side. As soon as
you start using XACML, you will use external parsing libraries and
thus introduce dependencies on yet more software. A
structured plain-text
format that translated almost one-to-one to a evaluation structure
is easy to process in any language, so I was hoping that more
software would actually implement it (and maybe even that it
ultimately could find it's way down in core OpenSSL, some time
down
the road).
The example language translated 1-to-1 into a list of
structures that
can be parsed top-down without need for any further libraries.
And a tool would again mean coding and maintenance (and a
distribution
problem for the tools), whereas human readable text is self-
contained.
But maybe I'm too pessimistic. Can you think of an XACML policy
whose text representation is still somewhat readable. Can we write
XACML "assuming we know the context", do away with all the
embedded schema namespaces, but still make sure that a standard
XACML parser can read it -- and a human as well?
Cheers,
DavidG.
Von
On Sep 15, 2005, at 7:57 AM, David Groep wrote:
Hi,
As Olle pointed out to me over coffee, it might be good to
write down at least the requirements in a real document
for GGF. I've had a go at collecting the information from
the email thread and formatting it as
a GWD. It needs *definitely* work and more text before it
could go public,
but at least we can start hacking at it...
DavidG.
Olle Mulmo wrote:
... did the discussion stop at this point?
There will be an opportunity to talk face-to-face at
GGF15. Should we try to nail down and enumerate the
requirements of what functionality we want until then?
/Olle
On Sep 2, 2005, at 08:28, David Groep wrote:
Hi Von,
Von Welch wrote:
Do I understand correctly that you are suggesting that
a CA's namespace file can include rules for all of
its subordinates? (These seems to be what your
example implies.) I actually think I like this idea,
see next comment.
That's indeed what I meant. It would enable new
subordinates to
"glide in" without intervention from the admin, as long as
they
stay within the namespace assigned for subordinates.
I think that need not even be the same namespace as the root,
and for this the wildcards should likely work in the
issuerName as well.
> If a subordinate file exists, it overrides any policy
that would be
> otherwise inherited.
Since you will have to traverse up the tree anyway for
validity checks,
finding the specialised signing policies should not be
much of a problem,
but I can't find the use case for it either (at least not
yet) :-)
Requiring it for root CAs seems like a good thing.
DavidG.
* the action to take if no signing policy file is found
(should you
allow or deny by default) I think should in general
be configurable.
Maybe require them for all root CAs and make them
optional for subordinates? Given the root CA namespace
config would cover the subordinates, I can't think of
any situation we would want one for a subordinate.
If a subordinate file exists, it overrides any policy
that would be otherwise inherited.
Von
On Aug 31, 2005, at 11:08 AM, David Groep wrote:
Hi all,
What I got till now:
* subordinated should be supported without the need to
install
any data in the trusted directory (this will work once
we have
OCSP support or better, and the new policy format). I
just completely
agree here.
The signing policy file should thus be applicable to
"self" and to any
subordinates that don't have their own singing policy
file.
(I'd propose semantics that make a specialised
signing_policy
take precedence over any higher-level policy file, so
that once
you find one in the CA tree, you don't have to
traverse further up
to inspect the policies of the parent CAs. The admin
supposedly
is in control of what goes in the trusted directory)
* naming should comply with RFC2235
* format should be easily parseable, and be "logical"
for both C/ OpenSSL
and Java implementations.
This likely precludes the use of c_hash-style CA
indexes in the
singing policy file.
* pattern matching:
Shell-style globs are fine with me as well (I could
not think of
any real-life case where a regex could not be replaced
by a set of
PERMIT statements and shell globs), but the shell
globs should expand
in any position in the DN.
* the action to take if no signing policy file is found
(should you
allow or deny by default) I think should in general
be configurable.
Let's try the SWITCH CA example. They have a fairly
complex structure
with a hierarchy 5-levels deep:
SwissSign Root (7b2d086c)
+- SwissSign Bronze (e36e7a72)
+- SwissSign Silver (e9d08b40)
+- SWITCH CA (c4435d12)
+- ... end-entities
This would lead to a singing policy for the top-level
SwissSign Root CA, that contains all subordinate CAs
down to the SWITCH EE- issuing CA.
To get the signing policy, the algorithm would start at
the end- entity
cert, and traverse up the chain until it finds a CA with
a signing
policy file. In this case, we could do with a singing
policy file for
the root only ("7b2d086c.namespace") that contains the
limitations
for all subordinates, like:
#
# @(#)7b2d086c.namespace
#
TO "CN=SwissSign CA (RSA IK May 6 1999
18:00:58),O=SwissSign,C=CH" \
PERMIT \
"C=CH,O=SwissSign,Email=bronze@swisssign.com,CN=SwissSign
B ronze CA"
TO
"C=CH,O=SwissSign,Email=bronze@swisssign.com,CN=SwissSign
Bronze CA" \
PERMIT \
"C=CH,O=SwissSign,Email=silver@swisssign.com,CN=SwissSign
S ilver CA"
TO
"C=CH,O=SwissSign,Email=silver@swisssign.com,CN=SwissSign
Silver CA" \
PERMIT \
"C=CH,O=Switch - Teleinformatikdienste,CN=SWITCH CA"
TO "C=CH,O=Switch - Teleinformatikdienste,CN=SWITCH CA" \
DENY \
"*,O=CERN,C=CH"
TO "C=CH,O=Switch - Teleinformatikdienste,CN=SWITCH CA" \
DENY \
"*,O=SwissSign,C=CH"
TO "C=CH,O=Switch - Teleinformatikdienste,CN=SWITCH CA" \
PERMIT \
"*,O=*,C=CH"
(but now of course "*" and "?" should be escaped when the're
part of the actual RDN).
In the Java world it seems slightly more complex. In
the CertPath API,
the TrustAnchor class takes a nameConstraints byte
array, but the byte
array must contain an ASN.1 DER encoding of a
NameConstrains extension
(as per RFC3280). There is AFAIK no way to express
wildcards in a
GeneralName, so I think it will just not be possible to use
TrustAnchor.nameConstrains to encode this formation.
Moreover, it
has no support for subordinated either. Like for C, in
Java we will
have to implement it ourselves...
What concerns the matching algorithm: the only
advantage that formal
regex's would bring is to combine the two DENY
statements into one
DENY "*,O=(CERN|SwissSign),C=CH", and that is no great loss.
DavidG.
Von Welch wrote:
And one more point that just occurred to me,
hierarchical CAs. A definite downside to our
current signing policy scheme is that subordinate
CAs are required to have a signing policy file,
which means that they can't just show up
unannounced (which is what people want to have
happen, when a subordinate is replaced, just swap it
out and go on with life).
Von
On Aug 31, 2005, at 5:46 AM, Olle Mulmo wrote:
Hi David,
Revamping this is definitely worth pursuing -- but we
have to think hard to get the design right. Von
had some excellent comments as well:
This needs better specification, btw, how is
whitespace handled? I'm not sure I like the use
of the formal regex as opposed to the unix glob
style ('.*' vs '*'). Do we want to continue using
the forward slash style vs the more standard
comma- separated?
If we are doing something like this, I would suggest
that we try to move towards RFC2253-style DN
encoding: It's the format that almost everything
else but openssl spits out by default nowadays, and
it is UTF-8(!!!).
/Olle
On Aug 26, 2005, at 23:13, David Groep wrote:
Hi all,
After a discussion on the CA mailing list, it is
quite clear
that the current way of expressing the namespace
constraints for
CAs is quite tedious: the EACLs have a far too
complicated syntax
for their simple use in the ca_signing_policy.conf
file, their
full syntax does not work, and they are used nowhere
else.
Also, at this time only a few parts of the system
actually use
the signing_policy file (only the C-based stuff that
still
calls the "oldgaa" callback), and a lot of
implementation in
other languages and systems is still to be done.
This is true for the Java part of GT, for the EGEE
Java stuff,
and also I'm quite sure that Unicore does not do
anything in this
area (Jules, Ron?)
What about changing to a new format for the
signing_policy before
we start all that work, a format like a simple set
of ordered lines
with an action and a regular expression. Like:
# namespace constraint file
#
PERMIT /DC=org/DC=mydomain/.*
PERMIT /DC=org/DC=alsomine/.*
DENY /DC=org/DC=friend/OU=hisdept/.*
PERMIT /DC=org/DC=friend/.* # my friend
delegated rest to me
#
which would be almost trivial to parse in any
language. I suggest
adding the "DENY" because that would solve by problem
with the
SWITCH CA (they own all of "/C=CH/*", except for "/
C=CH/ O=CERN/*",
so a ordered list with DENY prevents enumeration of
all the
possible "O="'s there).
But if you don't like the deny we can even go to just
a plain
list of regex's.
Of cource, we should distributed the "EACL" style
policy files
still for a long time, but eventually they would go away.
For the standard CA distribution I can easily add the new
format.
Would this be useful and possible to do in a
reasonable time?
Is it possible to put this as a feature request on
the current GT?
Cheers,
DavidG.
--
David Groep
** National Institute for Nuclear and High Energy Physics, PDP/
Grid group **
** Room: H1.56 Phone: +31 20 5922179, PObox 41882, NL-1009DB
Amsterdam NL **
--
*****************************************************************
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
*****************************************************************