Dear Christos concerning name constraints in the draft 2009 edition of X.509, a new extension has been added called holder name constraints, rather than changing the existing specification. This is so that existing PKI implementations are not affected. The proposed new extension is copied below. You will notice that the extension as currently defined only applies to X.509 ACs rather than to PKCs as well. This is because the work item on X.509 (2009) is only concerned with enhancements to ACs and not to PKCs. However, in your case, as I understand it, the name constraints are not to be inserted into a certificate, but rather are to be set by the RP as an input parameter to the certificate path processing algorithm. In this case, the ASN.1 contstruct below may satisfy your needs, and the text can be changes appropriately to reflect it is set by the RP as input to cert path processing. I hope this is of help to you. regards David 15.6.2.3 Holder Name Constraints Extension This extension constrains the name forms and name spaces in which a subordinate AA or a remote SOA and its subordinate AAs can issue ACs. This extension, indicates that constraints are being placed on the name forms and name spaces of all name forms in ACs issued by this AA and all subsequent AAs in the AC chain. If this extension is absent from all ACs in an AC chain, then no constraints are placed on any name spaces in the AC chain. If this extension is present in an AC certificate, then constraints are automatically placed on the name spaces of every name form in the AC chain from this point onwards, regardless of whether the name form is explicitly included in the extension or not i.e. the default constraint on each name form is exclude all the name space. NOTE – Because there can be an unbounded set of registeredID name forms then it is not possible for new name forms to be unconstrained once this extension is present, without the name form being explicitly included in this extension via a permitted subtree. This field is defined as follows: holderNameConstraints EXTENSION ::= { SYNTAX HolderNameConstraintsSyntax IDENTIFIED BY id-ce-nameConstraints } HolderNameConstraintsSyntax ::= SEQUENCE { permittedSubtrees [0] GeneralSubtrees, excludedSubtrees [1] GeneralSubtrees OPTIONAL } GeneralSubtrees ::= SEQUENCE SIZE (1..MAX) OF GeneralSubtree GeneralSubtree ::= SEQUENCE { base GeneralName, minimum [0] BaseDistance DEFAULT 0, maximum [1] BaseDistance OPTIONAL } BaseDistance ::= INTEGER (0..MAX) The permittedSubtrees and excludedSubtrees components each specify one or more naming subtrees of one or more name forms. Each subtree is defined by the name of the root of the subtree, i.e. the base component, and, optionally, within that subtree, an area that is bounded by upper and/or lower levels. An empty DN sequence is equivalent to a wildcard and means that all DNs fall within the subtree. The minimum field specifies the upper bound of the area within the subtree. All names whose final name component is above the level specified are not contained within the area. A value of minimum equal to zero (the default) corresponds to the base, i.e. the top node of the subtree. For example, if minimum is set to one, then the naming subtree excludes the base node but includes subordinate nodes. The maximum field specifies the lower bound of the area within the subtree. All names whose last component is below the level specified are not contained within the area. A value of maximum of zero corresponds to the base, i.e. the top of the subtree. An absent maximum component indicates that no lower limit should be imposed on the area within the subtree. For example, if maximum is set to one, then the naming subtree excludes all nodes except the subtree base and its immediate subordinates. The permittedSubtrees component is used to reduce the constraints placed on the name spaces of one or more name forms. Since the entire name space of each form is automatically fully excluded when this extension appears in an AA certificate, the permittedSubtrees component describes the name space(s) that is(are) permitted. If an entire name space of a particular name form is to be permitted, this is achieved by setting the base component to the root of the name space. The optional excludedSubtrees component is used to exclude one or more subordinate subtrees from the permittedSubtrees. For example, if in the X.500 distinguished name space, the subtree C=GB is permitted, but the subtrees C=GB, O=XYZ and C=GB, O=ABC are not permitted, then the permittedSubtrees will be set to C=GB and the excludedSubtrees will be set to C=GB, O=XYZ and C=GB, O=ABC. If the excludedSubtrees is present and its name spaces overlap with the permittedSubtrees, the excludedSubtrees statement takes precedence. All holder names in subsequent ACs in a certification path shall be located in the permitted name spaces for the certificate to be acceptable. When a certificate holder has multiple names of the same name form then all such names shall be located in the permitted name space of that name form for the certificate to be acceptable. When a certificate holder has multiple names in different name forms, each name shall be located in the permitted name space of that name form for the certificate to be acceptable. Of the name forms available through the GeneralName type, only those name forms that have a well-defined hierarchical structure may be used in these fields. The directoryName name form satisfies this requirement; when using this name form a naming subtree corresponds to a DIT subtree. An AC is considered subordinate to the base (and therefore a candidate to be within the subtree) if the SEQUENCE of RDNs, which forms the full DN in base, matches the initial SEQUENCE of the same number of RDNs which forms the first part of the DN of the holder of the certificate. The DN of the holder of the certificate may have additional trailing RDNs in its sequence that do not appear in the DN in base. The distinguishedNameMatch matching rule is used to compare the value of base with the initial sequence of RDNs in the DN of the subject of the certificate. Conformant implementations are not required to recognize all possible name forms. If an AC using implementation does not recognize a name form used in any base component, and - that name form also occurs in the holder field of a subsequent AC in the chain then that AC shall be handled as if an unrecognized critical extension had been encountered; or - that name form does not occur in the holder field of a subsequent AC in the chain then this name form can be ignored. If an AC using implementation does not recognize a name form that occurs in the holder field of a subsequent AC in the chain from that in which this extension appeared, but that name form does not occur in any base component of this extension, then that AC shall be rejected. This extension shall always be critical. An AC using system shall check that the attribute certificate path being processed is within the constraints specified by the value in this extension. Christos Kanellopoulos wrote:
Dear all,
Find below a draft version of the minutes from the CAOPS session on 16.10.2007. Please review them and send any comment to the list. On Wednesday 23.10.2007 I will upload it on GridForge.
-C.
CAOPS Session OGF 21 16.10.2007 -------------------------------------
Note Takers: Licia Florio, Christos Kanellopoulos
-------------------------------------
David Groep: Grid Certificate Profile .....................................
x The document has finished the public comment period as of October 8.
A1: David Groep to send email to the CAOPS mailing list with answers to the comments A2: Christos Kanellopoulos to test IE7 with CA certificate that has been reissued A3: By Nov 6 a new version of the document should be available that will address all the comments. There is going to be one week afterwards for group comments and then it will be pushed to the editor's queue.
Yoshio Tanaka: Audit Document ..............................
x New version of the document was uploaded to GridForge
- Christos Kanellopoulos: The document should provide a generic framework for performing audits on Grid IdPs. We should remove any statements on the preferred answers for each question in the document - Mike Helm: This look very much like the spreadsheet that is being used within TAGPMA for CA accreditation.
A4: Mike Helm to send the spreadsheet template at the CAOPS mailing lists A5: By end of November a new version of the document should be ready. Christos Kanellopoulos to help with the editing.
David Groep: Name Constraints ..............................
x Still waiting for the replies from the people at OGF 20 CAOPS session x The implementation details will be stripped off from the document and it will be focused on the requirements for providing namespace constraints at the policy lave.
- David Chadwick: What we want to achieve with this document can be found in the initial X.509 specs that got completely twisted around '97. This is expected to be changed in the new versions of the X.509 document - David Chadwick: Wild-card matching, as it is expressed in the document, did not exist in the X.500 specs. Subtree matching was part of the specs though - David Groep: We've added wild-card matching exactly to perform subtree matching
A6: David Chadwick to send details at the CAOPS mailing list A7: David Groep to update the document with reference to the documents that David Chadwick will (if and where necessary)
- Rachana Ananthakrishna: Globus will implement Namespace policies within 2008 Q1. Going to use the current policy language - David Groep: suggested that Globus eliminates the 1024 char limitation.
A8: New version of the document by late December
Mike Helm: OCSP Requirements for Grids ......................................
x The document was derailed from its initial scope during its development in the past two years. x We should revisit the document focusing on the Trusted Responder concept. x There is a lot of useful information within the document that could be used in future documents. x There is some work done in IETF that supersedes the document. However it is worth to look at Trusted Responder. Seems like the current trend is to use CRLs or short-lived certificates.
- Mike Helm: Users seem to be happy with the current CRL solution. Even when they face problems, they prefer to (over) engineer around them. - Rachana Ananthakrishna: In order for Globus to start working on an implementation, they need to have specific requirements from the users
A9: Mike Helm: New draft document by early January
------------------------------------------------------------------------
-- caops-wg mailing list caops-wg@ogf.org http://www.ogf.org/mailman/listinfo/caops-wg
-- ***************************************************************** David W. Chadwick, BSc PhD Professor of Information Systems Security The Computing Laboratory, University of Kent, Canterbury, CT2 7NF Skype Name: davidwchadwick 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://www.cs.kent.ac.uk/research/groups/iss/index.html Entrust key validation string: MLJ9-DU5T-HV8J PGP Key ID is 0xBC238DE5 *****************************************************************