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

["Steven Legg" <steven.legg@xxxxxxxxxxxxx>]

Tom,

> -----Original Message-----
> From: Tom Gindin [mailto:tgindin@xxxxxxxxxx]
> Sent: Tuesday, 16 January 2001 15:30
> To: steven.legg@xxxxxxxxxxxxx
> Cc: 'Stephen Kent'; ietf-pkix@xxxxxxx
> 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.

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.

> 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. steven.legg@xxxxxxxxxx). 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.

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

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

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

> 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 } } } )

Regards,
Steven

>
>           Tom Gindin
>
>
> "Steven Legg" <steven.legg@xxxxxxxxxxxxx> on 01/15/2001 10:56:28 PM
>
> Please respond to <steven.legg@xxxxxxxxxxxxx>
>
> To:   Tom Gindin/Watson/IBM@xxxxx, "'Stephen Kent'" <kent@xxxxxxx>
> cc:   <ietf-pkix@xxxxxxx>
> Subject:  RE: Basic Cert-2-Directory mapping question
>
>
>
>
> Tom,
>
> > -----Original Message-----
> > From: Tom Gindin [mailto:tgindin@xxxxxxxxxx]
> > Sent: Saturday, 13 January 2001 18:48
> > To: Stephen Kent
> > Cc: ietf-pkix@xxxxxxx
> > 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.
> >
> >
> >
>
>
>
>