[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Matching rules for LDAP
David,
> At the PKIX meeting yesterday there was insufficient time to go through
> all the proposed agenda items. One topic that fell off the bottom was
> new LDAP schema for PKIs and PMIs. I had prepared a presentation listing
> a number of topics that need to be resolved, so I reproduce these here
> below, so that we can get some discussion of them on the list.
> Should we allow LDAP attribute names to be used instead of OIDs to
> reference attributes in attribute certificate matching
My preference would be no, however we could wait to see what happens
in LDAPbis to address non-uniqueness of attribute names in DNs,
and then use the same resolution.
> Do we need the full richness of the X.500 matching rules or can we use a
> subset of them
> e.g. can we use name constraints based on whole subtrees rather than on
> chopped subtrees
>
> Do we need to add matching rules for cross certificates and/or S/MIME
> certificates
> X.509 has used different matching methods for PKIs and PMIs. PKI has one
> complex flexible matching rule holding most standard extensions. PMI has
> a separate matching rules for each extension. Do we want to use the
> X.509 method or alternatively use the same method for both PKIs and
> PMIs. Personnally I think X.509 got it wrong here, and should have
> devised separate matching rules for each extension for both PKIs and
> PMIs. Then when new extensions are defined, new LDAP matching rules can
> be defined to go with them.
>
> How many extension matching rules should we define for PMIs.
> none, the most popular ones (which are they), or all?
The component matching rules concept, with some tweaks, makes these
questions go away. Knowing the ASN.1 type of a value (or component
part, like an extension) is sufficient to implicitly and completely
define a wide range of useful matching capabilities. There is no need
to define new extension-specific matching rules or assign new LDAP
syntax OIDs for the matching rule assertion syntaxes. Section 8 of
the component matching rules draft also defines what the LDAP string
encoding would be.
The Certificate and AttributeCertificate extensions present a
special problem in that the value of the extension is carried
as a DER encoding in an OCTET STRING component. The component
matching rules as currently defined can only do an octetStringMatch
of the entire extension value, but I can see a couple of ways
around this to define a matching capability that is a superset of
the current extension matching rules, with a fraction of the
descriptive text.
The first solution is to add a BOOLEAN field (I'll call it useContained)
to the ComponentAssertion syntax to allow the user to specify that
the content of a BIT STRING or OCTET STRING component is to be
treated as an open type. Under the existing component matching rule
framework this will allow the component parts of the DER encoded
extension value to be referenced and matched.
By way of example, I'll show how the component matching rules can be
used to perform matching just like the basicAttConstraintsMatch from
X.509:2000.
The basicAttConstraints extension has an OID of { 2 5 29 41 } and
a value syntax of:
BasicAttConstraintsSyntax ::= SEQUENCE {
authority BOOLEAN DEFAULT FALSE,
pathLenConstraint INTEGER (0..MAX) OPTIONAL
}
An LDAP filter to search for basicAttContraints extensions with
authority TRUE and a path length constraint of three looks like this:
(attributeCertificateAttribute:componentFilterMatch:=and:{
item:{ component "toBeSigned.extensions.*.extnId",
rule objectIdentifierMatch, value 2.5.29.41 } },
item:{ component "toBeSigned.extensions.*.extnValue",
useContained TRUE,
value { rule componentFilterMatch,
value and:{
item:{ component "authority", rule booleanMatch, value
TRUE },
item:{ component "pathLenConstraint",
rule integerMatch, value 3 } } } } } )
Breaking it down, this bit:
item:{ component "toBeSigned.extensions.*.extnId",
rule objectIdentifierMatch, value 2.5.29.41 } },
matches the relevant extension OID, this bit:
item:{ component "toBeSigned.extensions.*.extnValue",
useContained TRUE,
exposes the contents of the extnValue OCTET STRING as a value
of BasicAttConstraintsSyntax ASN.1 type, and this bit:
value { rule componentFilterMatch,
value and:{
item:{ component "authority", rule booleanMatch, value
TRUE },
item:{ component "pathLenConstraint",
rule integerMatch, value 3 } } }
tests whether the extension value has the authority and path length
constraint I'm looking for.
The second solution is to use a special-purpose matching rule to do
the job of exposing the extension value.
containingMatch MATCHING-RULE ::= {
-- can only be applied to OCTET STRING or BIT STRING attribute
values,
-- or components, containing an encoded value of some ASN.1 type
SYNTAX ContainingAssertion
ID { ... } }
ContainingAssertion ::= SEQUENCE {
rule MATCHING-RULE.&id,
-- the matching rule to apply to the decoded contents
-- of the OCTET STRING or BIT STRING
value MATCHING-RULE.&AssertionType
-- an assertion value for the matching rule -- }
The LDAP filter would then look like this instead:
(attributeCertificateAttribute:componentFilterMatch:=and:{
item:{ component "toBeSigned.extensions.*.extnId",
rule objectIdentifierMatch, value 2.5.29.41 } },
item:{ component "toBeSigned.extensions.*.extnValue",
rule containingMatch,
value { rule componentFilterMatch,
value and:{
item:{ component "authority", rule booleanMatch, value
TRUE },
item:{ component "pathLenConstraint",
rule integerMatch, value 3 } } } } })
I'd prefer this second solution because it allows special-case and weird
matching semantics to be kept out of the basic component matching rule
definitions.
The extension matching rules in X.509 seem to follow a general pattern
of "the matching rule returns TRUE if the stored value contains the foobar
extension and if components that are present in the assertion value
match the corresponding components of the stored value". This suggests
a convenience matching rule to make things simpler for PKI. The
directoryComponentsMatch matching rule tests if components that are
present in the assertion value match components of the stored
value, but also tests that components not present in the assertion
value are also absent in the stored value. I could define a
directoryComponentSubsetMatch that only tests if components that are
present in the assertion value match components of the stored
value. Using such a rule, the last example filter reduces to:
(attributeCertificateAttribute:componentFilterMatch:=and:{
item:{ component "toBeSigned.extensions.*.extnId",
rule objectIdentifierMatch, value 2.5.29.41 } },
item:{ component "toBeSigned.extensions.*.extnValue",
rule containingMatch,
value { rule directoryComponentSubsetMatch,
value { authority TRUE, pathLenConstraint 3 } } } } )
I picked on an extension with a simple structure as my example.
The usefulness of directoryComponentSubsetMatch would be more evident
on some of the more complex extension syntaxes.
By the way, by comparison to the component matching rules I find the
descriptions of the semantics of some of the extension matching rules
seriously underspecified. There would appear to be plenty of
opportunities for different interpretations by different implementors.
Regards,
Steven
> This should give folks enough to think about whilst I take the plane
> home later today
>
> David
>
>
> --
> *****************************************************************
>
> David Chadwick, BSc PhD
> Post: IS Institute, University of Salford, Salford M5 4WT
> Tel: +44 161 295 5351 Fax +44 161 745 8169
> Mobile: +44 790 167 0359
> Email: D.W.Chadwick@salford.ac.uk
> Home Page: http://www.salford.ac.uk/its024/chadwick.htm
> Research Projects: http://sec.isi.salford.ac.uk
> Understanding X.500: http://www.salford.ac.uk/its024/X500.htm
> X.500/LDAP Seminars: http://www.salford.ac.uk/its024/seminars.htm
> Entrust key validation string: MLJ9-DU5T-HV8J
>
> *****************************************************************