I'm working on using openldap to store certificate requests (ie: PKCS#10 and SPKAC).
I thought I'd use the binary syntax '1.3.6.1.4.1.1466.115.121.1.5' for my custom attribute. However there doesn't seem to be a equality matching rule for that syntax.
I could implement one, but would such a contribution be accepted by the openldap project? I've looked around online, but I can't seem to find an OID for such a matching rule declared anywhere.
Am I barking up the wrong tree? If not I'll whip up a patch.
Cheers,
Stef Walter
On Feb 20, 2009, at 6:11 PM, Stef wrote:
I'm working on using openldap to store certificate requests (ie: PKCS#10 and SPKAC).
I thought I'd use the binary syntax '1.3.6.1.4.1.1466.115.121.1.5' for my custom attribute.
Why? This syntax should be avoided. It was dropped with revised LDAP specifications (RFC 4510) for good reason. Any uses of it will suffer significant interoperability problems.
If all you want is store certificate requests in the directory as octet strings, matched by octet string matching, then use OCTET STRING and octetStringMatch.
If what you want is matching based upon the request abstract value, then you will need to define a new syntax whose LDAP string syntax is the BER/DER encoding of the request (don't use ;binary) and then implement an equality rule for that syntax.
However there doesn't seem to be a equality matching rule for that syntax.
Equality mapping for the ASN.1 open data type? The underlying ASN.1 data type for the binary syntax is (depending on how you read the obsoleted specification) an ANY.
I could implement one, but would such a contribution be accepted by the openldap project?
It's not implemented for a reason.
I've looked around online, but I can't seem to find an OID for such a matching rule declared anywhere.
Am I barking up the wrong tree?
You are at least barking in the wrong direction.
Kurt Zeilenga wrote:
On Feb 20, 2009, at 6:11 PM, Stef wrote:
I'm working on using openldap to store certificate requests (ie: PKCS#10 and SPKAC).
I thought I'd use the binary syntax '1.3.6.1.4.1.1466.115.121.1.5' for my custom attribute.
Why? This syntax should be avoided. It was dropped with revised LDAP specifications (RFC 4510) for good reason. Any uses of it will suffer significant interoperability problems.
Interesting. Thanks for the clear reply.
I guess that means that uses of the userSMIMECertificate and userPKCS12 attributes in openldap will encounter these problems. These are both defined with the syntax of '1.3.6.1.4.1.1466.115.121.1.5'.
Cheers,
Stef
Stef wrote:
Kurt Zeilenga wrote:
On Feb 20, 2009, at 6:11 PM, Stef wrote:
I'm working on using openldap to store certificate requests (ie: PKCS#10 and SPKAC).
I thought I'd use the binary syntax '1.3.6.1.4.1.1466.115.121.1.5' for my custom attribute.
Why? This syntax should be avoided. It was dropped with revised LDAP specifications (RFC 4510) for good reason. Any uses of it will suffer significant interoperability problems.
I guess that means that uses of the userSMIMECertificate and userPKCS12 attributes in openldap will encounter these problems. These are both defined with the syntax of '1.3.6.1.4.1.1466.115.121.1.5'.
Do you have any use-case where you need equality matching on one of those?
BTW: I don't know any client which writes userSMIMECertificate except Netscape Communicator 4.5+. (AFAIK it's supposed to be opaque-signed S/MIME message with zero-length body signed by the private key holder.)
So IMO it's ok to leave this schema definition as is for backward compability.
Ciao, Michael.
On Feb 23, 2009, at 11:49 AM, Stef wrote:
Kurt Zeilenga wrote:
On Feb 20, 2009, at 6:11 PM, Stef wrote:
I'm working on using openldap to store certificate requests (ie: PKCS#10 and SPKAC).
I thought I'd use the binary syntax '1.3.6.1.4.1.1466.115.121.1.5' for my custom attribute.
Why? This syntax should be avoided. It was dropped with revised LDAP specifications (RFC 4510) for good reason. Any uses of it will suffer significant interoperability problems.
Interesting. Thanks for the clear reply.
I guess that means that uses of the userSMIMECertificate and userPKCS12 attributes in openldap will encounter these problems. These are both defined with the syntax of '1.3.6.1.4.1.1466.115.121.1.5'.
Yes, and such problems have been previously raised on openldap-software.
-
Kurt Zeilenga -
Michael Ströder -
Stef