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