Subject: RE: Basic Cert-2-Directory mapping question

From: "Tom Gindin" <[email-masked]>
Date: Mon, 15 Jan 2001 23:29:45 -0500

The technique you documented has some effects equivalent to the
alternative 1 I proposed, although with a syntax which requires
considerable knowledge of ASN.1 to formulate an LDAP query and with no
ability to index on the component field (as opposed to searching on it).
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?  I cannot believe that it is really
appropriate to require LDAP queries for known ASN.1 types to specify
matching rules within the query.

          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: Michael Ströder <[email-masked]>
Date: Tue, 16 Jan 2001 11:49:58 +0100

Tom Gindin wrote:
> 
> wouldn't it be reasonable to define a search

As far as I understand this I-D the LDAP client will just construct
LDAP filter strings as usual. The LDAP server deals with the ugly
stuff as it deals with ASN.1 structures when doing searches anyway.

Steve, David, correct me if I'm wrong.

Ciao, Michael.

---

From: "Steven Legg" <[email-masked]>
Date: Fri, 19 Jan 2001 11:11:24 +1100

Tom,

> Sent: Tuesday, 16 January 2001 15:30
> To: [email-masked]
> Cc: 'Stephen Kent'; [email-masked]
> 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. [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.

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

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.

> 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

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

---

From: "Steven Legg" <[email-masked]>
Date: Fri, 19 Jan 2001 11:29:50 +1100

Michael,

> From: [email-masked] [mailto:[email-masked]]On Behalf 
> Of Michael
> Str der
> Sent: Tuesday, 16 January 2001 21:50
> To: ietf-pkix

More precisely, the assertions in an LDAP filter are still text strings,
so a user doesn't need to understand BER to use component matching.
An understanding of the ASN.1 syntax definition of the attribute type
being searched helps, but it is possible to write the PKI profiles such
that ASN.1-unaware users can easily formulate useful queries.

An LDAP filter has actually always been a mix of BER and text encodings.
APIs generally hide the BER parts from users. An LDAP filter has a string
representation according to RFC 2254, but this is not used by the LDAP
search operation. 

Regards,
Steven

---

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

Steven Legg wrote:
> an updated certificate).

If I understand your example right you would like to use the cert
retrieved from the LDAP host containing the old e-mail address to
encrypt a message for the new e-mail address? This behaviour is not
what I would like to see in my e-mail application. Think of key
escrow mechanisms in a company...

> which is the one it actually wants.

IMHO the main benefit of this I-D would be that applications or
components not dealing with ASN.1 or certificates itself can
retrieve the appropriate certificate. If you require the
client-application to do anything else more than just submitting a
simple LDAP filter string you can stop writing the I-D.

> query is an obstacle to acceptance.

YES!

Another real-world example: A system administrator wants to pull
certificates via LDAP and feed them into a PKI-aware application.
She/He's using her/his favourite scripting language with a primitive
LDAP module to download the binary blobs containing DER-encoded
certificates. In this system the LDAP component itself is not
PKI-aware and the PKI-aware component is not capable of speaking
LDAP. Therefore the LDAP component is not able to sort out the right
certificate.

Ciao, Michael.

---

From: "Steven Legg" <[email-masked]>
Date: Thu, 25 Jan 2001 12:23:43 +1100

Michael,

> Sent: Wednesday, 24 January 2001 23:07
> To: [email-masked]
> Subject: Re: Certificate Matching was:RE: Basic 
> Cert-2-Directory mapping
> question
> 
> 
> Steven Legg wrote:
> > 

It was a general statement not directed at any particular attribute
type. Using surrogate attribute values to search for certificates
imposes a constraint between the certificate contents and the contents
of the other attributes in the same entry. I'm not bold enough or
knowledgeable enough to assert that there are NO current or future
applications where this constraint would cause serious difficulties.

As Tom pointed out, we could define a bunch of new attribute types
to act expressly and only as search attributes for fields in certificates.
It then doesn't matter that there is a constraint between the certificates
and the new attributes, except that the task of managing the correspondence
between the two falls to the large number of client implementations.
It makes more sense to change the small number of server implementations
to support direct searching on certificate contents.

> simple LDAP filter string you can stop writing the I-D.

I hope you haven't confused the issues. There are two things being
discussed.

1) Should surrogate search attributes or direct matching on certificates
be used to search for certificates ?

2) Given that there is direct matching, should the matching rules be a
series of special purpose certificate matching rules or a generic matching
capability that works for any syntax (certificates included) ?

With regard to 1), a search on a single surrogate attribute can only
return all certificates in a matched entry. If the entry contains
only one certificate the client can trust it is the right one (hopefully
the surrogate attribute value is the same as the corresponding field
in the certificate). If the entry contains more than one certificate
then it is up to the client to delve into each certificate to work
out which is the one it actually wanted. Searches on a combination
of surrogate attributes can return entries with certificates that
don't have the desired combination. Again it is up to the client
to delve into the certificates to see which entries and certificates
actually match its criteria. Surrogate search attributes generally require
the clients to be PKI and ASN.1 aware. Direct matching of certificates
doesn't.

With regard to 2), I'm drawing a distinction between LDAP filters that
are simple to use versus LDAP filters that look simple. Special
purpose certificate matching rules can be (relatively) simple to use
and also look simple. I contend that I can write component matching
rule templates that are equally simple to use, though they look more
complicated.

> LDAP. Therefore the LDAP component is not able to sort out the right

When you say that the LDAP component is not PKI-aware I take it you mean
that it doesn't understand the ASN.1 type of a certificate and supports
no matching rules for directly matching a certificate. In such a case
your hypothetical system administrator would have to use surrogate
search attributes with all the attendant imprecision. Some sort
of direct matching capability is required for the LDAP component to
return only the right certificate.

Regards,
Steven

---

From: Michael Ströder <[email-masked]>
Date: Thu, 25 Jan 2001 10:42:24 +0100

Steven Legg wrote:
> 
> I hope you haven't confused the issues.

I hope that too. ;-)

> be used to search for certificates ?

I vote for direct matching on certificates. IMHO surrogate
attributes will cause too much trouble. And I consider the directory
server to be less trustworthy than the CA which issued the
certificates in almost any case.

> Surrogate search attributes generally require

That's why I voted for direct matching on certificates.

> > Another real-world example:
> > [..]
> > In this system the LDAP component itself is not
> > LDAP.
> no matching rules for directly matching a certificate.

Yes. (Maybe my english knowledge is sometimes too limited to be very
precise.)

> In such a case

I hoped that a directory server extension could implement the direct
certificate matching stuff and simply return the right certificate
to the LDAP client not aware of the ASN.1 type of a certificate.

Ciao, Michael.