[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: [ldapext] certificateExactMatch and certificateMatch


Jochen,

Kurt D. Zeilenga wrote: 
[CC list trimmed to single list]

At 07:10 AM 3/2/2006, Keutel, Jochen wrote:

Hello,
both X.509 and draft-zeilenga-ldap-x509 define the matching rules
certificateExactMatch and certificateMatch. Questions:

1. Where is the string encoding for these matching rules defined? 


Yes, draft-zeilenga-ldap-x509 (an approved Proposed Standard, an
RFC-to-be) specifies the LDAP string encoding of these matching
rules to be the GSER [RFC3641] encoding of the value.


I have seen that in OpenLDAP a string like
((userCertificate=1357$o=truetrust ltd,c=gb))



The old format used here should be considered deprecated in favor
of the standard GSER string encoding.


But I can't find a RFC/I-D which defines this string format. 


As noted above, see draft-zeilenga-ldap-x509.  As an example,
  (userCertificate={ serialNumber 1357, issuer "o=truetrust ltd,c=gb" })



2. certificateMatch is defined in X.590 as

certificateMatch MATCHING-RULE ::= {
      SYNTAX  CertificateAssertion
      ID                      id-mr-certificateMatch }
CertificateAssertion ::= SEQUENCE {
      serialNumber            [0]     CertificateSerialNumber OPTIONAL,
      issuer                          [1]     Name                    OPTIONAL,
      subjectKeyIdentifier    [2]     SubjectKeyIdentifier            OPTIONAL,
      authorityKeyIdentifier  [3]     AuthorityKeyIdentifier  OPTIONAL,
      certificateValid                [4]     Time                    OPTIONAL,
      privateKeyValid         [5]     GeneralizedTime         OPTIONAL,
      subjectPublicKeyAlgID   [6]     OBJECT IDENTIFIER               OPTIONAL,
      keyUsage                        [7]     KeyUsage                OPTIONAL,
      subjectAltName          [8]     AltNameType             OPTIONAL,
      policy                          [9]     CertPolicySet           OPTIONAL,
      pathToName              [10]    Name                    OPTIONAL,
      subject                         [11]    Name                    OPTIONAL,
      nameConstraints         [12]    NameConstraintsSyntax   OPTIONAL
}

. Is it possible to use this matching rule in LDAP? 


Yes, as specified in draft-zeilenga-ldap-x509.


Is there any product already supporting this matching rule? 


I believe this matching rule to be fully implemented as
specified in draft-zeilenga-ldap-x509 in at least one
implementation.

(I note that I am not counting OpenLDAP's implementation as it
is flawed in the current release, an issue I am currently working
on addressing.)

(I note I do not name implementations that I believe fully
implement this specification as I prefer not to make specific
claims regarding products of others.)


But those others can make claims about their own products :-).
eB2Bcom's directory server supports the certificateMatch matching rule.
In our current release the certificateMatch matching rule expects
the LDAP assertion value to be BER encoded by default, but it is possible
to use the GSER encoding, as specified in draft-zeilenga-ldap-x509, by
attaching ";transfer-gser" to the attribute type in the extensibleMatch
filter item. Now that draft-zeilenga-ldap-x509 is approved we will be
changing the default encoding over to GSER in the next release.




E.g. it should be possible to search for certificates with
- keyUsage="keyEncipherment"
or
- subjectAltName "e-mail: aaa@bbb.cc"
, right?

How would be the string encoding for these 2 examples? 

In the first case the LDAP assertion value would be:

   { keyUsage { keyEncipherment } }

Note that the subjectAltName field of CertificateAssertion only allows
searching for subject alt names of a particular kind. To find all
certificates with email addresses as subject alt names the assertion
value would be:

   { subjectAltName builtinNameForm:rfc822Name }

You can't use certificateMatch to search for particular subjectAltName
email addresses, but it is possible to use component matching (RFC 3687) to
do this. The LDAP extensibleMatch filter item would look something like this
(minus the line breaks):

   (userCertificate:componentFilterMatch:=item:{
       component "toBeSigned.extensions.*.extnValue.content.(2.5.29.17).*.rfc822Name",
       rule caseIgnoreIA5Match, value "aaa@bbb.cc" })

Our directory server supports this as well.

Regards,
Steven



As I don't trust my built-in GSER encoder to provide correct
encodings except for the most basic ASN.1 types, I'll leave
this to others.

Kurt 


_______________________________________________
Ldapext mailing list
Ldapext@ietf.org
https://www1.ietf.org/mailman/listinfo/ldapext




_______________________________________________
Ldapext mailing list
Ldapext@ietf.org
https://www1.ietf.org/mailman/listinfo/ldapext