Subject: Re: Certificate Matching was:RE: Basic Cert-2-Directory mapping question

From: "Tom Gindin" <[email-masked]>
Date: Thu, 18 Jan 2001 23:16:16 -0500

Responses below.  I'm not against having a general component filter
matching rule, but I do want some shortcuts for common cases.  Users are
supposed to be able to formulate LDAP queries by hand, after all, and
something as simple as "find certificates with the following e-mail
address" shouldn't require a 6 line query.

          Tom Gindin

"Steven Legg" <[email-masked]> on 01/18/2001 07:11:24 PM

Please respond to <[email-masked]>

To:   Tom Gindin/Watson/IBM@IBMUS
cc:   <[email-masked]>
Subject:  Certificate Matching  was:RE: Basic Cert-2-Directory mapping
      question

Tom,

> -----Original Message-----
> From: Tom Gindin [mailto:[email-masked]]
> Sent: Tuesday, 16 January 2001 15:30
> To: [email-masked]
> Cc: 'Stephen Kent'; [email-masked]
> Subject: RE: Basic Cert-2-Directory mapping question
>
>
>
>      The technique you documented has some effects equivalent to the
> alternative 1 I proposed,

But also what I think are important differences. For a start, the use
of surrogate attributes to search for certificates throws responsibility
for managing the relationship between the surrogates and the certificate
onto the directory clients. It isn't necessarily the case that the
authority responsible for managing values of the surrogate attribute
(e.g. email addresses) is the same as the authority that manages
certificates.
The different authorities could end up stepping on each other's toes, and
access control policies could get in the way of any one authority managing
the relationship.

It isn't always appropriate that the value of the surrogate attribute
matches the value of the corresponding field in the certificate.
Maybe the certificate is valid but uses a superseded value for the
surrogate attribute (maybe the user has changed ISPs and is waiting for
an updated certificate). Maybe the certificate is in a secondary
repository that doesn't/can't hold the surrogate attributes (a partial
replica perhaps). Maybe the certificate is being stored in an entry
other than the certificate owner's nominal entry. Not requiring there
to be a relationship between the fields of a certificate and the other
attributes in an entry gives us more flexibility in how and where to
store certificates in a directory.

[Tom Gindin] In theory, if one of the values of SubjectAltName has been
superseded, the certificate should be revoked.  It might well be
appropriate to define a separate multi-valued attribute with a name like
"CertificateEMailAddresses" to hold these values, and in that case the
value goes in the same entry as the cert irrespective of certificate
ownership.

Using surrogate search attributes to support searching on certificates
also doesn't help to isolate one of a number of certificates stored in
the same entry. A matching rule that directly matches a component
in a certificate can be combined with the valuesReturnFilter control
so that the directory server only returns the certificate that matches.
With surrogate search attributes the client will get back all
certificates in the entry and have to filter them itself to find
which is the one it actually wants.

[Tom Gindin] You're right that it doesn't isolate a single cert.  It does
cut down the search space from a whole directory to a single entry,
however.

> although with a syntax which requires
> considerable knowledge of ASN.1 to formulate an LDAP query

I recognize that the need to understand ASN.1 in order to formulate a
query is an obstacle to acceptance. To get around that I propose adding
component matching templates to the LDAP/PKI profile for the set of
matching abilities that are regarded as most important and/or most useful.

For example, a section on searching on certificates by the email address
subjectAltName extension would present the following template.

(userCertificate:componentFilterMatch:=item:{
    component "toBeSigned.extensions.*",
    rule componentFilterMatch,
    value and:{
        item:{ component "extnId",
            rule objectIdentifierMatch, value 2.5.29.17 },
        item:{ component "extnValue.content.*.rfc822Name",
            rule caseIgnoreMatch, value "EMAIL-ADDRESS" } } } )

A user doesn't need to know any ASN.1 to form a query. They just copy
the template and substitute EMAIL-ADDRESS with the name of interest
(e.g. [email-masked]). There would also be a bit of ABNF
to describe the syntax of the different blanks to fill in in the templates
but that would be required no matter what approach is taken for the
LDAP/PKI profiles.

[Tom Gindin] They need to have the exact ASN.1 layout of the certificate.
They also appear to need to know the matching rule names in considerable
detail.

More sophisticated users can read up on the component matching rules
and try things not covered by the examples, something that wouldn't
be possible with ad-hoc specific definitions.

[Aside: I've changed my mind on how to handle constructs like the
extension value, which is a DER encoding stuffed into an OCTET STRING.
It will be more convenient and useful to extend the component reference
syntax to allow the contents of the OCTET STRING to be treated much
like an open type. So "extnValue" references the OCTET STRING and
"extnValue.content" references the ASN.1 value encoded into that OCTET
STRING, which in this case is expected to be of the GeneralNames type. ]

[Tom Gindin] That's a relief.  Frankly, one of the main uses for component
filtering on the PKI formats is to pick up extension values, and if you
can't treat the extension value as an open type you can't filter on
KeyUsage bits, EKU values, or SubjectAltName values.  You would still be
able to get the SubjectPublicKey algorithm and the issuer name, at least.

> and with no
> ability to index on the component field (as opposed to
> searching on it).

Why do you assume that component fields can't be effectively indexed ?
I've been implementing the component matching rules as a background job
and lately I've been working on the indexing support. There's a
variety of approaches, with different space/time characteristics,
but I've found indexing support for component matching to be
eminently do-able.

[Tom Gindin] It's possible to create an index out of a component value, but
isn't that more invasive to the implementation of a directory or LDAP
server than defining a simplified search syntax for those components?
Also, how does the user control whether the directory indexes on
SubjectAltName, which is a privacy issue?  In my proposal, the decision on
indexing is sent to the CA and RA on a per-user basis (inside CRMF's
publication control).

> This does not mean that I disapprove of the idea of component
> filtering in
> LDAP searches, which IMHO will solve a number of important problems.
> However, in view of the very high proportion of ASN.1 usage within
> directory attributes actually accounted for by the small number of
> PKI-based data structures, wouldn't it be reasonable to define a search
> syntax for them which uses keywords to identify fields,
> rather than the
> generic ASN.1 facility you proposed?

The problem with defining a specific assertion syntax with assigned
keywords is that it defines the limits of what matching can be performed.
If there isn't a syntax/keyword for what you want to do you have to wait
until a suitable syntax/keyword is assigned by some standard, if ever.
A generic facility doesn't have this problem. The component references,
though verbose, are uniform, unambiguous and work for any ASN.1 type
definition.

[Tom Gindin] A generic facility is desirable as a fallback.  I do not think
it is desirable as the normal way to get subfields of SubjectAltName or
KeyUsage, however.

> I cannot believe that
> it is really
> appropriate to require LDAP queries for known ASN.1 types to specify
> matching rules within the query.

An ASN.1 type may be known, but that doesn't mean that particular
component parts will always be matched in the same way. Most of the
time a string component will be matched by caseIgnoreMatch but I don't
think it is unreasonable to be able to sometimes match it according
to caseIgnoreOrderingMatch, caseIgnoreSubstringsMatch,
approximateStringMatch,
or presentMatch, among other possibilities. I believe the ability to vary
the matching semantics is useful. However for some component types
(e.g. OBJECT IDENTIFIER, BOOLEAN) there isn't much choice on how to match,
so there is scope to make the rule optional and to assume a reasonable
default rule when the rule is omitted. I wouldn't want to make the default
rules dependent on the attribute syntax because then component matching
can't be completely specified until the matching semantics for each
component of the syntax had been specified in an RFC.

With optional rules the template above would simplify to the following:

(userCertificate:componentFilterMatch:=item:{
    component "toBeSigned.extensions.*",
    rule componentFilterMatch,
    value and:{
        item:{ component "extnId", value 2.5.29.17 },
        item:{ component "extnValue.content.*.rfc822Name",
            value "EMAIL-ADDRESS" } } } )

Such simplifications aren't so important if most users are just filling
in the blanks in a template, although it might make it possible to
reduce the number of templates. For example, one template might suffice
for all subjectAltName cases.

(userCertificate:componentFilterMatch:=item:{
    component "toBeSigned.extensions.*",
    rule componentFilterMatch,
    value and:{
        item:{ component "extnId", value 2.5.29.17 },
        item:{ component "extnValue.content.*.ALT-NAME-TYPE",
            value ALT-NAME-VALUE } } } )

[Tom Gindin] That won't be very helpful for the compound types, nor for
OTHER-NAME.  However, it would give you a match for 5 of the 8 base types
in GeneralName.

Regards,
Steven

>
>           Tom Gindin
>
>
> "Steven Legg" <[email-masked]> on 01/15/2001 10:56:28 PM
>
> Please respond to <[email-masked]>
>
> To:   Tom Gindin/Watson/IBM@IBMUS, "'Stephen Kent'" <[email-masked]>
> cc:   <[email-masked]>
> Subject:  RE: Basic Cert-2-Directory mapping question
>
>
>
>
> Tom,
>
> > -----Original Message-----
> > From: Tom Gindin [mailto:[email-masked]]
> > Sent: Saturday, 13 January 2001 18:48
> > To: Stephen Kent
> > Cc: [email-masked]
> > Subject: Re: Basic Cert-2-Directory mapping question
> >
> >
> >
> >      Steve:
> >
> >      Isn't a substantial part of this problem the question of how to
> > publish a certificate in a directory where it will be
> > searchable by a field
> > within SubjectAltName, most importantly the e-mail address
> > when that is
> > included?  Most of the arguments which I have ever heard
> for including
> > e-mail address in the subject DN were actually searchability
> > arguments.
> > The names in SubjectAltName are typically hierarchically
> assigned, of
> > course, but they aren't X.500-based.
> >      Assuming that an EE wants their certificate published
> > under the e-mail
> > address, IMHO they should be able to request the RA or CA to
> > perform one of
> > the following actions on a successful certificate issuance
> (using the
> > publication info control or a similar mechanism):
> > 1    Add a directory attribute for e-mail address whose value
> > is the e-mail
> > address in the SubjectAltName to the directory entry named by
> > the Subject
> > DN.  Very often, the RA or CA has the privilege and the
> > knowledge to do
> > this and the EE has only one or neither.
> > 2    Send a certificate announcement to the domain of the
> > e-mail address,
> > in the hope and (reasonable) expectation that the
> certificate will be
> > published there.
> >
> >      Similar, but less practically important, considerations
> > apply to other
> > addresses in SubjectAltName.  IMHO we also need to profile
> > which directory
> > attributes should normally be used when indexing a
> > certificate under fields
> > within SubjectAltName, especially since there are at least
> two fairly
> > common attributes for e-mail address.
>
> Rather than using other attributes as surrogates for searching for
> certificates with particular fields (of subjectAltName or any other
> component) I think it is more appropriate to have the capability to
> search for those certificates directly. The refinement of the
> component
> matching rules in my last reply to David Chadwick would make
> it possible
> to search for entries containing certificates with a particular
> SubjectAltName regardless of whether the alternate name was reflected
> in any other attribute(s) in the entry. Such a solution
> avoids questions
> about which other attributes to search, and doesn't require
> RAs or CAs to
> populate said attributes.
>
> Regards,
> Steven
>
> >
> >           Tom Gindin
> >
> > P.S. -    The opinions above are my own, and not necessarily
> > those of my
> > employer.
> >

---

From: "Steven Legg" <[email-masked]>
Date: Wed, 24 Jan 2001 17:15:15 +1100

Tom,

> Sent: Friday, 19 January 2001 15:16
> Subject: Re: Certificate Matching was:RE: Basic
> Cert-2-Directory mapping
> question
>
>
>

We should make it clear who we think the "users" are. I assume that the
users
are programmers creating PKI-enabled applications. They would be using an
LDAP
API to access the certificate repository. Such folks should be able to
contend
with a six line query template. I don't think the users are the PKI
application
users. The user interfaces should protect these folks from ever having to
enter
an LDAP query by hand.

> value goes in the same entry as the cert irrespective of certificate

I did think of this, but this is getting into what Michael termed a
"new technical mechanism". If a new mechanism is going to be used then
shouldn't it be the one that better fits the requirement and also
puts most of the implementation effort into the small number of server
implementations rather than the larger number of client implementations ?

> cut down the search space from a whole directory to a single entry,

There's a second problem with the surrogate search attributes when
searching on more than one at a time. A search for X AND Y returns
the entries that contain a certificate with X and a certificate with Y,
but not necessarily a certificate with both X and Y, so the client
will have to filter out the spurious entries as well as the spurious
certificates in entries.

> They also appear to need to know the matching rule names in

We seem to be on different wavelengths. The above template basically
boils down to:

constant-string-one  EMAIL-ADDRESS  constant-string-two

The unsophisticated user needs to know how to format an email address
and how to copy a string of characters verbatim. No knowledge of the
Certificate ASN.1 type or of matching rules is required, given
sufficiently clear instructions on how to use the template.

> be possible with ad-hoc specific definitions.

[snip]

> server than defining a simplified search syntax for those components?

The component matching rules are a generalization of what is already
going on. Effective support for the objectIdentifierFirstComponentMatch
and other *FirstComponentMatch rules means building indexes on a component
of an attribute value. Some of the matching rules defined in the latest
edition of X.509 (e.g. certificateMatch) are "and" component filter
matching rules in disguise. The simplified search syntaxes are only
easier to deal with (with regard to index support) if they don't involve
a conjunction of user supplied component assertion values.

> indexing is sent to the CA and RA on a per-user basis (inside CRMF's

This is an access control issue rather than a matching/indexing issue.
Note that the current crop of matching rules in X.509 are already thwarting
a user's ability to prevent searching on particular components
of their certificates. Also, users can't currently control whether a
directory indexes on their simple attributes (e.g. telephoneNumber).

> it is desirable as the normal way to get subfields of

The reason why I'm pushing back on providing short cuts is because it
removes any incentive for server vendors to build in any of the generic
facilities (for matching, or anything else). Defining a bunch of short cuts
is effectively what is happening now, with a growing list of special case
matching rules being defined, each of which has to be separately
implemented.

However, I don't consider your desire for a simpler syntax for commonly used
matches to be unreasonable. If there are to be short cuts then I would
like them to be designed such that it is possible to create a machine
readable description of the relationship of the short cut to the generic
component matching capability. For users, the short cuts can be described
in typical fashion as though they are special case matching rules. Simple
server implementations might support the short cuts directly in this way.
The
advanced server implementations would support the component matching rules,
and the short cut matching rules just become a matter of configuration
rather
than individual hard-coding. Advanced users (of advanced servers) can use
the
component matching rules directly, or configure their own shortcut matching
rules. Adding a layer of short cut matching rules over the component
matching rules makes the server implementation more complex than I would
like, but
makes things easier for the users.

I'll have a think about a formal framework for describing short cut matching
rules on top of component matching rules.

[snip]

> OTHER-NAME.  However, it would give you a match for 5 of the

The default matching rule for compound types could be
directoryComponentsMatch,
which is basically a component-wise equality match. The ALT-NAME-VALUE would
be an LDAP string encoding of a value of the compound type. OTHER-NAME would
be treated as the equivalent SEQUENCE type (i.e. a compound type).

Regards,
Steven

---

From: Michael Ströder <[email-masked]>
Date: Wed, 24 Jan 2001 13:01:23 +0100

Steven Legg wrote:
> >  Users are
> We should make it clear who we think the "users" are.
> I assume that the users are programmers creating PKI-enabled
> applications. They would be using an LDAP API to access the
> certificate repository. Such folks should be able to
> contend with a six line query template.

I tend to say that even programmers creating PKI-enabled
applications appreciate simple approaches. A simple standard leads
to correct code soon. Standards "too complicated" will not be easily
adopted especially by developers of end-user applications. Bear in
mind that e.g. obtaining a certificate from LDAP in a S/MIME-aware
e-mail application is just a small side-job not very high on the
developer's priority list.

> I don't think the
> users are the PKI application users. The user interfaces
> should protect these folks from ever having to enter an LDAP
> query by hand.

I agree that applications should protect end-users from formulating
a LDAP query by hand.

But IMHO there is another user group: Folks doing customization of
applications. E.g. think of someone modifying a XML search form
template of a generic LDAP client. She/He's not a sophisticated PKI
application programmer nor an naive end user.

> If a new mechanism is going to be used then

Yes. Writing plug-ins for existing LDAP servers is easier than
modifying all client applications.

> [..lots of discussion about matching rules which made my
> brain hurt deleted..]

Hmm, at this point I would like to make a non-technical statement:
I have the feeling that we don't need so many new I-D's with even
more flexibility. We need I-D's which cut down the possibilities and
make statements about good practices (e.g. how to store certificates
in a directory and how to search them in the most possible simple
way).

I would expect that 90% of the scenarios considered here will never
ever make it into a real-world application. Therefore you can IMHO
safely consider simpler use-cases.

Ciao, Michael.