Subject: Re: WG Last Call: Certificate Schema

From: "Jong-Hyuk" <[email-masked]>
Date: Thu, 2 Dec 2004 00:28:45 -0500

> Since that time (Spring 2003) suppliers have not moved that far (if at
> all) towards supporting component matching. Only Steven Legg's Australian
> company, which had supported component matching prior to publication of
> the RFCs, and OpenLDAP which I believe can now support it, have done
> anything in this direction. Attribute extraction on the other hand has
> double that amount of supporting implementations, plus all clients can
> naturally support it without any code change.

Clients can be considered to naturally support Component Matching if they
accept search filters in a text form and they support extensibleMatch. It is
observed that many clients fall into this category. For those clients who
have search filters hard-coded and / or do not support extensibleMatch, the
OpenLDAP implementation of Component Matching further supports attribute and
matching rule aliases. In attribute aliasing, an alias attribute in the
search filter is converted by the server into the predefined aliased
component reference and the assertion value is used as the corresponding
component assertion value. The matching rule alias is used in a similar way.
The aliasing mechanism can also be considered as an optimization which
eliminates the extra processing steps for ComponentFilter parsing. We will
provide performance evaluation results of Component Matching to show that it
can be implemented in LDAP servers without performance degradation and
increase in complexity.
- Jong-Hyuk

------------------------
Jong Hyuk Choi
IBM Thomas J. Watson Research Center - Enterprise Linux Group
P.O. Box 218, Yorktown Heights, NY 10598
[email-masked]

---

From: David Chadwick <[email-masked]>
Date: Thu, 02 Dec 2004 15:48:39 +0000

Jong-Hyuk wrote:
> component assertion value. 

Jong,

This is a neat idea. Are you using the schema we have defined for this
attribute aliasing, or have you defined your own? If you are using the
schema we have defined in the 3 PKIX IDs, then this would be another
good reason for publishing the IDs as Informational. If you have defined
your own schema, then it will need to be published widely so that
clients that dont support extensible matching (the majority of them)
will know which attribute types to use. But I dont think it would be
helpful to define a different set of attributes to refer to the same set
of X.509 attribute components.

regards

David

>The matching rule alias is used in a similar way.

-- 

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

David W. Chadwick, BSc PhD
Professor of Information Systems Security
IS Institute, University of Salford, Salford M5 4WT
Tel: +44 161 295 5351  Fax +44 1484 532930
Mobile: +44 77 96 44 7184
Email: [email-masked]
Home Page:  http://www.salford.ac.uk/its024/chadwick.htm
Research Web site: http://sec.isi.salford.ac.uk
Entrust key validation string: MLJ9-DU5T-HV8J
PGP Key ID is 0xBC238DE5

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

---

From: "Jong-Hyuk" <[email-masked]>
Date: Mon, 6 Dec 2004 16:10:53 -0500

> of X.509 attribute components.

The aliasing feature of OpenLDAP is provided as a mechanism which can work
out the compatibility issue for the legacy / inflexible clients. However, it
should not be considered as a mechanism which may potentially encourage the
use of non-standard schema and access method. We instead need to consider
the definition of the standardized schema for attribute / matching rule
aliases in Component Matching.
- Jong-Hyuk

--------------
Jong Hyuk Choi

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Mon, 06 Dec 2004 15:44:48 -0800

>aliases in Component Matching.

It should also be noted that as an value extraction compatibility
mechanism, it is not 100% compatible with the value extraction
approach.  For instance, when the client uses a complex value
extraction filter and the entity has multiple certificates.

Kurt