Re: ca signing policy file
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 Bronze 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 Silver 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 Groep wrote:
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?
No, this would be unfortunate. The RFC 3280 Name Constraints semantics have perverted the original X.509 semantics so that a superior CA can no longer use name constraints to constrain all name spaces issued by the subordinate CA. We currently have a defect report on this issue being actively discussed in the ITU-T X.509 standards group. To explain more fully, the X.509 name constraints had the original intention of limiting which certificates issued by a subordinate CA could be trusted. Those that fell outside the constrained name space were not to be trusted. RFC3280 perverted this, by adding a sentence that stated, if the subordinate CA issued a cert with a name form that was not in the name constraints extension, then this cert should be trusted. This now blows a hole in the trust assumptions of the superior CA, since a subordinate CA can now legally circumvent the name constraints by issuing certificates using a different name form. The current debate in the X.509 group is whether to revert to the original semantics or keep the perverted 3280 ones. 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,
actually I am being told by the RFC3280 lobby that commercial CAs do support name constraints, and because of this we cannot revert their semantics back from the RFC3280 meaning to that of the X.509 original meaning, because it would break their implementations. Now if you are telling me that most commercial CAs do not support name constraints, that would be a powerful argument to support reverting name constraints back to their original semantics. Can anyone give me evidence of support or non-support of commercial CAs for the name constraints extension? 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.
It is actually meant to be the superior authority that places the constraints on the subordinate CAs. CAs themselves can issue certs with whatever subject names they want to. They can also constrain themselves or not. So if a CA were to constrain itself, it would be through its CPS or CP. The name constraints extension is to constrain subordinate CAs.
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 :-)
What does bronze CA mean in the context of name constraints. Bronze, silver, gold etc do not sound like a naming constraint to me, but rather a CPS or policy issue
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.
I think currently it has to be outside the standard certificate path validation algorithm, due to the bug introduced by 3280, which will let certificates not in the constrained domain slip through the net as being valid, as explained above. regards David ***************************************************************** 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 Chadwick writes:
Can anyone give me evidence of support or non-support of commercial CAs for the name constraints extension?
Well, in the recent past, no commercial client software supported name constraints, so whether commercial CAs supported them or not was a moot point. Well worse than that, since it's a critical extension. Your CA would be useless. openssl doesn't support it, so that makes use of name constraints in the web &c world pretty much impossible. I am not sure whether recent Windows products can; it would make sense that they do, because of cross-signing support, but I don't know.
Hi Mike, I don't know if it works correctly or not, but the openssl change log shows: http://www.openssl.org/news/changelog.html ... Changes between 0.9.7h and 0.9.8 [05 Jul 2005] ... *) Support for nameConstraints certificate extension. [Steve Henson] ... Did anyone test this? -Frank. Mike Helm wrote:
David Chadwick writes:
Can anyone give me evidence of support or non-support of commercial CAs for the name constraints extension?
Well, in the recent past, no commercial client software supported name constraints, so whether commercial CAs supported them or not was a moot point. Well worse than that, since it's a critical extension. Your CA would be useless.
openssl doesn't support it, so that makes use of name constraints in the web &c world pretty much impossible. I am not sure whether recent Windows products can; it would make sense that they do, because of cross-signing support, but I don't know.
-- Frank Siebenlist franks@mcs.anl.gov The Globus Alliance - Argonne National Laboratory
I don't know of any web browsers that use openssl, btw. Happy to be proven wrong as this would give me hopes for a web browser that supported proxy certs. Von On Oct 10, 2005, at 12:03 PM, Frank Siebenlist wrote:
Hi Mike,
I don't know if it works correctly or not, but the openssl change log shows:
http://www.openssl.org/news/changelog.html ... Changes between 0.9.7h and 0.9.8 [05 Jul 2005] ... *) Support for nameConstraints certificate extension. [Steve Henson] ...
Did anyone test this?
-Frank.
Mike Helm wrote:
David Chadwick writes:
Can anyone give me evidence of support or non-support of commercial CAs for the name constraints extension?
Well, in the recent past, no commercial client software supported name constraints, so whether commercial CAs supported them or not was a moot point. Well worse than that, since it's a critical extension. Your CA would be useless.
openssl doesn't support it, so that makes use of name constraints in the web &c world pretty much impossible. I am not sure whether recent Windows products can; it would make sense that they do, because of cross-signing support, but I don't know.
-- Frank Siebenlist franks@mcs.anl.gov The Globus Alliance - Argonne National Laboratory
Von Welch writes:
I don't know of any web browsers that use openssl, btw. Happy to be
I don't know whether any browsers support name constraints. Since Tony and David have reported that the recent MS CA supports it, perhaps MS CAPI does too and at least some Windows platforms support it. I am not sure about Mozilla NSS; it might be able to display it, but I don't see any mention of name constraints in release notes. I'm not familiar enough with nss code to be able to tell if it uses it, but it doesn't look promising. As for openssl 098, v3_ncons.c seems to have a test and tree management routine for names & name constraint rules. I haven't found any other information on it either on the ssl mailing list or in the distribution. The test directory doesn't seem to use it. No example CA certs use it. You could code up your own ASN.1 blobs to insert into a CA, perhaps. Best to ask Steve Henson. Since there's a mod_ssl version of it now, you could probably make an Apache web server and test it. If somebody wants to do this, we can make you a CA instance that will include name constraints.
On Oct 10, 2005, at 12:03 PM, Frank Siebenlist wrote:
I don't know if it works correctly or not, but the openssl change Changes between 0.9.7h and 0.9.8 [05 Jul 2005] *) Support for nameConstraints certificate extension. [Steve Henson] Did anyone test this?
Here is some information on Name Constraint validation for Windows clients: --------------- From Microsoft TechNet ------------------- Name constraint validation A CA certificate can contain name constraints that are applied to all certificate requests made to the CA. Each request is compared to the list of permitted and excluded constraints to determine whether the certificate should be considered permitted, not permitted, excluded, or not defined. Note Name constraint validation can only be performed by Windows XP and Windows Server 2003 clients. Name constraints are not evaluated by Windows 2000 clients. If you require that name constraints be applied, you can indicate that the extensions are critical, which should result in the chain being discarded by an application conforming to RFC 2459. For example, a permitted constraint could allow all DNS names that end in contoso.com. This would include DNS names such as contoso.com and xcontoso.com. If you only wanted DNS names from the contoso.com DNS name space, you could use the permitted constraint .contoso.com. This constraint would permit x.contoso.com but exclude xcontoso.com. When name constraints are present in a CA certificate, the following rules are applied to the subject name and alternate subject name entries. . If the name constraints extension exists in a CA certificate, all name constraints should be present in the extension. Any name constraints that are not included are considered wildcards that will match all possibilities. For example, if the DNS name constraint were absent, the entry would be treated as DNS=. . All name constraints will be considered. There is no precedence applied to the listed name constraints. It is for this reason that name constraints that are not present are treated as wildcards. . An excluded name constraint will take precedence over a permitted name constraint . Name constraints are applied to the subject name extension and any existing subject alternate name extensions. . Name constraints apply to all names contained in an end certificate. Each name in the subject or subject alternate name extensions should match at least one of the name constraints listed for that name type. A subject name or subject alternate name that does not match a listed name type will be rejected. Note that most client name spaces are not included in a CA certificate and generally do not apply. . Name constraints are case-sensitive if the names are stored in ASCII or Unicode format. Name restrictions must be enforced across the following alternative name information entries in the subject name: Other Name (NT Principal Name only); RFC 822 Name; DNS Name; URL; Directory Name, and IP address. When the certificate chain engine validates an end certificate for name constraints, it will arrive at one of the following results: . Permitted The end certificate contains a name that is listed as permitted in an issuer's name constraints extension. . Not permitted The end certificate contains a name that is not listed as permitted in an issuer's name constraints extension. . Excluded The end certificate contains a name that is listed as excluded in an issuer's name constraints extension . Not Defined The issuer certificate does not list a constraint for a specific name type (such as Directory Name or IP Address)
Mozilla's Network Security Services (NSS) (essentially Mozilla's version of openssl) http://www.mozilla.org/projects/security/pki/nss/ ... 8 January 2004: NSS 3.9 Release The new features and enhancements in NSS 3.9 include GeneralizedTime support, RFC 3280 compliant name constraints,... ... ... so maybe the current MS&Mozilla browsers do support x509 name constraints after all... -Frank. Tony J. Genovese wrote:
Here is some information on Name Constraint validation for Windows clients:
--------------- From Microsoft TechNet -------------------
Name constraint validation A CA certificate can contain name constraints that are applied to all certificate requests made to the CA. Each request is compared to the list of permitted and excluded constraints to determine whether the certificate should be considered permitted, not permitted, excluded, or not defined.
Note Name constraint validation can only be performed by Windows XP and Windows Server 2003 clients. Name constraints are not evaluated by Windows 2000 clients. If you require that name constraints be applied, you can indicate that the extensions are critical, which should result in the chain being discarded by an application conforming to RFC 2459.
For example, a permitted constraint could allow all DNS names that end in contoso.com. This would include DNS names such as contoso.com and xcontoso.com. If you only wanted DNS names from the contoso.com DNS name space, you could use the permitted constraint .contoso.com. This constraint would permit x.contoso.com but exclude xcontoso.com.
When name constraints are present in a CA certificate, the following rules are applied to the subject name and alternate subject name entries.
. If the name constraints extension exists in a CA certificate, all name constraints should be present in the extension. Any name constraints that are not included are considered wildcards that will match all possibilities. For example, if the DNS name constraint were absent, the entry would be treated as DNS=.
. All name constraints will be considered. There is no precedence applied to the listed name constraints. It is for this reason that name constraints that are not present are treated as wildcards.
. An excluded name constraint will take precedence over a permitted name constraint
. Name constraints are applied to the subject name extension and any existing subject alternate name extensions.
. Name constraints apply to all names contained in an end certificate. Each name in the subject or subject alternate name extensions should match at least one of the name constraints listed for that name type. A subject name or subject alternate name that does not match a listed name type will be rejected. Note that most client name spaces are not included in a CA certificate and generally do not apply.
. Name constraints are case-sensitive if the names are stored in ASCII or Unicode format.
Name restrictions must be enforced across the following alternative name information entries in the subject name: Other Name (NT Principal Name only); RFC 822 Name; DNS Name; URL; Directory Name, and IP address.
When the certificate chain engine validates an end certificate for name constraints, it will arrive at one of the following results:
. Permitted The end certificate contains a name that is listed as permitted in an issuer's name constraints extension.
. Not permitted The end certificate contains a name that is not listed as permitted in an issuer's name constraints extension.
. Excluded The end certificate contains a name that is listed as excluded in an issuer's name constraints extension
. Not Defined The issuer certificate does not list a constraint for a specific name type (such as Directory Name or IP Address)
-- Frank Siebenlist franks@mcs.anl.gov The Globus Alliance - Argonne National Laboratory
Frank Siebenlist writes:
8 January 2004: NSS 3.9 Release ... so maybe the current MS&Mozilla browsers do support x509 name constraints after all...
So it looks like the ingredients to use name constraints successfully (for instance, commercially) have finally appeared: in later versions of Windows, in NSS, and just now in openssl 98 (hence Apache). The next challenge would be to dump the contents of the delivered CA lists from MS and Mozilla and see if any name constraints can be found. My guess is the number would be "0", since openssl is the key player here thru Apache; if there are any CAs using name constraints, they are subordinates not carried yet in those lists. It doesn't make sense to me that the commercial SSL server cert providers would use name constraints, because of their naming strategies. But they might use them if they operate a subordinate CA for some defined party (like a regional government, or large company). The Thawte WoT - personal cert system had a pretty flat name space the last time I looked at it; would't work well with name constraints. I haven't looked at other personal cert providers in a very long time.
My take is also that it wouldn't be prudent, even with these advances in NameConstraints adoption, to assume they remove the need for RP- specified policies such as this document describes. That would require adoption by CAs in general. Von On Oct 11, 2005, at 1:05 PM, Mike Helm wrote:
Frank Siebenlist writes:
8 January 2004: NSS 3.9 Release ... so maybe the current MS&Mozilla browsers do support x509 name constraints after all...
So it looks like the ingredients to use name constraints successfully (for instance, commercially) have finally appeared: in later versions of Windows, in NSS, and just now in openssl 98 (hence Apache).
The next challenge would be to dump the contents of the delivered CA lists from MS and Mozilla and see if any name constraints can be found. My guess is the number would be "0", since openssl is the key player here thru Apache; if there are any CAs using name constraints, they are subordinates not carried yet in those lists.
It doesn't make sense to me that the commercial SSL server cert providers would use name constraints, because of their naming strategies. But they might use them if they operate a subordinate CA for some defined party (like a regional government, or large company).
The Thawte WoT - personal cert system had a pretty flat name space the last time I looked at it; would't work well with name constraints. I haven't looked at other personal cert providers in a very long time.
My take is also that it wouldn't be prudent, even with these advances in NameConstraints adoption, to assume they remove the need for RP- specified policies such as this document describes. That would require adoption by CAs in general.
The RP specific policies sound like a reasonable feature. I am not clear on the statement about adoption by CAs in General... All the CAs working on Grids are organized and have to modify and change policies over time, so what new policy needs to be defined? The reason to present the paper here is that you want us to change, so are you saying some changes are easier for us or that we will not make the NameConstraint change? Though support for it does not seem to answer all your issues.
Sorry Tony, I was unclear. 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 was mainly stating that support by openssl for name constraints is a step in the right direction, I didn't see it changing this need. Von On Oct 11, 2005, at 6:00 PM, Tony J. Genovese wrote:
My take is also that it wouldn't be prudent, even with these advances in NameConstraints adoption, to assume they remove the need for RP- specified policies such as this document describes. That would require adoption by CAs in general.
The RP specific policies sound like a reasonable feature. I am not clear on the statement about adoption by CAs in General... All the CAs working on Grids are organized and have to modify and change policies over time, so what new policy needs to be defined? The reason to present the paper here is that you want us to change, so are you saying some changes are easier for us or that we will not make the NameConstraint change? Though support for it does not seem to answer all your issues.
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.
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 Chadwick writes:
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
That's pretty much it. In practice, people (=relying party representatives, say) usually want something meaningful in the name at least for "people" certs. Most people recognize now that this is not sufficient to identify a particular person but it humanizes the certs. Perhaps this makes the workflow a little more efficient for everyone.
Von Welch wrote:
My take is also that it wouldn't be prudent, even with these advances in NameConstraints adoption, to assume they remove the need for RP- specified policies such as this document describes. That would require adoption by CAs in general.
Von
Agreed. Also given that the current 3280 semantics are Allow all except, then you cant rely on the name constraints software to remove certs with different name forms to the ones you specify (and fact you can rely on it to accept them) regards David -- ***************************************************************** 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 *****************************************************************
Mike I am informed by MS that they support name constraints, but I dont know which products, OS versions etc. thanks David Mike Helm wrote:
David Chadwick writes:
Can anyone give me evidence of support or non-support of commercial CAs for the name constraints extension?
Well, in the recent past, no commercial client software supported name constraints, so whether commercial CAs supported them or not was a moot point. Well worse than that, since it's a critical extension. Your CA would be useless.
openssl doesn't support it, so that makes use of name constraints in the web &c world pretty much impossible. I am not sure whether recent Windows products can; it would make sense that they do, because of cross-signing support, but I don't know.
-- ***************************************************************** 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 *****************************************************************
Quick search of my 2003 CA... It is supported. Looks like RFC 2459. From the man page: Qualified Subordination [...] All features of qualified subordinate CAs are new to the Windows Server 2003 family and are not available on Windows 2000 Server. To use these new features, you must use a Windows Server 2003 certification authority. Note: The constraints and policy types listed above are defined in RFC 2459. -------+-------- They list a number of names and their associated RFCs that you can use: [....] You can use the following naming and addressing formats to constrain the certificate issuance activities of qualified subordinate CAs: Directory name (for example, an Active Directory distinguished name) DNS domain name E-mail name User principal name (UPN) Universal Resource Identifier (URI) Internet Protocol address Tony... -----Original Message----- From: owner-caops-wg@ggf.org [mailto:owner-caops-wg@ggf.org] On Behalf Of David Chadwick Sent: Monday, October 10, 2005 11:52 AM To: helm@fionn.es.net Cc: CAOPS-WG; Von Welch; Olle Mulmo; Joni Hahkala; Jules Wolfrat; Ron Trompert; Frank Siebenlist Subject: Re: Name Constraints, was Re: [caops-wg] Re: ca signing policy file Mike I am informed by MS that they support name constraints, but I dont know which products, OS versions etc. thanks David Mike Helm wrote:
David Chadwick writes:
Can anyone give me evidence of support or non-support of commercial CAs for the name constraints extension?
Well, in the recent past, no commercial client software supported name constraints, so whether commercial CAs supported them or not was a moot point. Well worse than that, since it's a critical extension. Your CA would be useless.
openssl doesn't support it, so that makes use of name constraints in the web &c world pretty much impossible. I am not sure whether recent Windows products can; it would make sense that they do, because of cross-signing support, but I don't know.
-- ***************************************************************** 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 Chadwick writes:
Now if you are telling me that most commercial CAs do not support name constraints, that would be a powerful argument to support reverting name constraints back to their original semantics.
As interesting as the name constraints tangent is, did it actually address your question? I assumed when you said "commercial CA" you meant something like Verisign or Global sign &c. But you could have meant a PKI environment like Entrust or Windows....
Mike Mike Helm wrote:
David Chadwick writes:
Now if you are telling me that most commercial CAs do not support name constraints, that would be a powerful argument to support reverting name constraints back to their original semantics.
As interesting as the name constraints tangent is, did it actually address your question?
I assumed when you said "commercial CA" you meant something like Verisign or Global sign &c.
But you could have meant a PKI environment like Entrust or Windows....
Actually I was interested in both David
-- ***************************************************************** 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 *****************************************************************
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 > Bronze 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 > Silver 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 **
> 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.
You all might want to look into a sort of movement that seems to exist in some PKIX members. I've picked up some microsoft certs recently that seem to have AIA extensions that jump around missing links in the trust chain (between the end entity cert you have, and the trusted issuer pre-installed in your cert store). Somewhere I have read a justification / method for this but have lost track. But there is at least one example of another variant in a current draft in the IETF PKIX WG: http://www.ietf.org/internet-drafts/draft-ietf-pkix-crlaia-03.txt
Mike Helm 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. >
This is actually in fact what the original X.509 name constraints extension was designed to do, until RFC3280 perverted it.
>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.
Exactly. A superior CA should be able to constrain what a subordinate CA can do. Then if the subordinate CA does something different when issuing certs, then those certs wont be trusted.
You all might want to look into a sort of movement that seems to exist in some PKIX members. I've picked up some microsoft certs recently that seem to have AIA extensions that jump around missing links in the trust chain (between the end entity cert you have, and the trusted issuer pre-installed in your cert store).
Its actually worse than that. Microsoft will actually trust and validate certificates that have names that do not conform to the name constraints extension, due to the fact that RFC 3280 says that all non specified name spaces are trusted (whereas X.509 stated that they were untrusted) Somewhere I have read a justification / method for
this but have lost track.
I am still to find a justification for this :-) regards David But there is at least one example of another variant
in a current draft in the IETF PKIX WG:
http://www.ietf.org/internet-drafts/draft-ietf-pkix-crlaia-03.txt
-- ***************************************************************** 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 Chadwick writes:
AIA extensions that jump around missing links in the trust chain Its actually worse than that. Microsoft will actually trust and validate certificates that have names that do not conform to the name constraints Somewhere I have read a justification / method for this but have lost track.
I am still to find a justification for this :-)
I thought I had read something to the effect of it being used to help set up the path discovery, not suborn name constraints, but I admit I cannot find the reference. Maybe it's it in MSDN somewhere.
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 >> Bronze 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 >> Silver 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, 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? 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
*****************************************************************
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 *****************************************************************
So as far as I know we're not talking about doing name constraints in this specification for anything other than DNs, so by implication if an implementor wants to accept other name forms, they need to make other arrangements with regards to policy. If we're all in agreement, that needs to be stated in the document. Von On Oct 10, 2005, at 11:32 AM, David Chadwick wrote:
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
*****************************************************************
participants (6)
-
David Chadwick -
David Groep -
Frank Siebenlist -
Mike Helm -
Tony J. Genovese -
Von Welch