Subject: [ldapext] certificateExactMatch and certificateMatch

From: "Keutel, Jochen" <[email-masked]>
Date: Thu, 02 Mar 2006 16:10:12 +0100

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?

I have seen that in OpenLDAP a string like

((userCertificate=1357$o=truetrust ltd,c=gb))

works for certificateExactMatch; also RFC3876 (matched values only)
uses this string representation. But I can't find a RFC/I-D which
defines this string format.

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? Is there any product
already supporting this matching rule?

E.g. it should be possible to search for certificates with
- keyUsage="keyEncipherment"
or
- subjectAltName "e-mail: [email-masked]"
, right?

How would be the string encoding for these 2 examples?

Regards,  Jochen.

_______________________________________________
Ldapext mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ldapext

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Thu, 02 Mar 2006 08:41:01 -0800

[CC list trimmed to single list]

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

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

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

>How would be the string encoding for these 2 examples?

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

---

From: Steven Legg <[email-masked]>
Date: Fri, 03 Mar 2006 12:27:16 +1100

Jochen,

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

>>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 "[email-masked]" })

Our directory server supports this as well.

Regards,
Steven