Subject: Matching rules for LDAP

From: David Chadwick <[email-masked]>
Date: Thu, 14 Dec 2000 16:35:19 +0000

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 separate the PKI schema from the PMI schema and create two
separate IDs.

We Need OID allocations from the LDAPEXT group (this is not so much an
issue as "job to be done")

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

A bug was found in X.509 (the attribute certificate syntax and the exact
match syntax are different). Have the X.509 group fixed the ASN.1 for
Geneva? And has new text been added as well. (Maybe Sharon can advise on
this)

Should we allow LDAP attribute names to be used instead of OIDs to
reference attributes in attribute certificate matching

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?

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: [email-masked]
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

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

---

From: "Steven Legg" <[email-masked]>
Date: Thu, 21 Dec 2000 18:17:25 +1100

David,

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

> 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