search

389ds / 389-ds-base

The enterprise-class Open Source LDAP server for Linux
https://www.port389.org/
Other
210 stars 90 forks source link

Correct implementation of rfc4523 #2118

Closed 389-ds-bot closed 2 months ago

389-ds-bot commented 4 years ago

Cloned from Pagure issue: https://pagure.io/389-ds-base/issue/49059

We attempt to support rfc4523 for certificate storage. This is consumed by DogTag and IPA.

However, in our schema, we incorrectly list a number of attributes as 1.3.6.1.4.1.1466.115.121.1.40 rather than 1.3.6.1.4.1.1466.115.121.1.8. In bin.c we can see that right now 1.3.6.1.4.1.1466.115.121.1.8 is octetString compatible, so we don't need to change this.

We need to fix a few things.

First, we need to update our schema to use the correct oid.

Second, part of the syntax is that any attribute returned of this syntax must have the ;binary attribute tag attached.

This is described in:

https://tools.ietf.org/html/rfc4523

Binary encoding of attributes is here:

https://tools.ietf.org/html/rfc4522

389-ds-bot commented 4 years ago

Comment from tbordaz (@tbordaz) at 2017-01-02 19:57:49

389-ds-bot commented 4 years ago

Comment from tbordaz (@tbordaz) at 2017-01-02 22:16:47

usercertificate indexed in 'pres' and 'eq'

Add the following values to an entry (note that values 3 and 4 are identical but on an attribute with ';binary')

ldapmodify -D "cn=directory manager" -w xxx <<!EOF
dn: cn=account19,cn=account,dc=example,dc=com
changetype: modify
add: objectclass
objectclass: pkiuser
-
add: usercertificate;binary
usercertificate;binary: value with binary
-
add: usercertificate
usercertificate: value without binary
-
add: userCertificate;binary
userCertificate;binary: value without binary
-
add: userCertificate;fr
userCertificate;fr: value with fr
!EOF

The resulting entry is 


ldapsearch -D "cn=directory manager" -w xxx -b "dc=example,dc=com"   -LLL  "usercertificate;binary=value without binary" usercertificate
dn: cn=account19,cn=account,dc=example,dc=com
userCertificate;binary:: dmFsdWUgd2l0aCBiaW5hcnk=
userCertificate;binary:: dmFsdWUgd2l0aG91dCBiaW5hcnk=     # b64: value without binary
usercertificate: value without binary
userCertificate;fr: value with fr

dbscan -f <db_path>/db/userRoot/usercertificate.db -r 
+                                       
    30 
=value%20with%20binary                  
    30 
=value%20with%20fr                      
    30 
=value%20without%20binary               
    30

So attribute value is indexed stripping the subtype or transfert option. The retrieved entries are tested against the filter (including the subtype and transfert option). If a subtype or transfert option is requested only values with that subtype/option are returned else all values are returned.

IMHO to conform https://tools.ietf.org/html/rfc4522:

'''A problem in (1) and (2)''' is that a an attribute may appear to contain twice the same value:

ldapsearch -D "cn=directory manager" -w xxx -b "dc=example,dc=com"   -LLL  "usercertificate;binary=value without binary" usercertificate
dn: cn=account19,cn=account,dc=example,dc=com
userCertificate;binary:: dmFsdWUgd2l0aG91dCBiaW5hcnk=     # b64: value without binary
usercertificate;binary: value without binary              # 
...

The first value is coming from 'userCertificate;binary' with a encoded64 "value without binary" The second value is coming from 'usercertificate' (returned as 'userCertificate;binary') with "value without binary"

389-ds-bot commented 4 years ago

Comment from nhosoi (@nhosoi) at 2017-01-05 08:26:06

When do we need this RFE? 1.3.6 or later?

389-ds-bot commented 4 years ago

Comment from firstyear (@Firstyear) at 2017-01-05 10:27:11

I don't think this is urgent, it can be later.

389-ds-bot commented 4 years ago

Comment from tbordaz (@tbordaz) at 2017-01-05 13:24:32

I agree with William, this is not a blocker for freeipa. It exists workaround and it will be implement in freeipa.

A question is will we fix it or not. Two concerns:

389-ds-bot commented 4 years ago

Comment from nhosoi (@nhosoi) at 2017-01-26 08:44:19

Thanks, William and Thierry! Set it to 1.3.7 backlog.

389-ds-bot commented 4 years ago

Comment from nhosoi (@nhosoi) at 2017-02-11 23:08:52

Metadata Update from @nhosoi:

389-ds-bot commented 4 years ago

Comment from mreynolds (@mreynolds389) at 2017-07-12 22:13:17

Metadata Update from @mreynolds389:

walshg3 commented 3 years ago

Hello,

I have came across this issue recently in my environment and was wondering if I could get guidance in how to continue. Our old LDAP server has the userCertificate;binary attribute for well over 300 entries. We have been testing 389ds as an open source alternative but I am running into an issue with importing my ldifs. On 389ds the userCertificate attribute loses the ;binary subtype. This is critical for my environment since we have scripts that look for the userCertificate;binary keyword in ldap searches . As a hotfix I changed the keyword search to just userCertificate but I was wondering if there is a better alternative to enforce the subtype when reading the ds.

While reading through the comments I tried adding the certificate following the naming sequences:

usercertificate;binary vs userCertificate;binary (Notice the capital 'C') usercertificate vs userCertificate (with and without ;binary as well)

but it did not work. Is that the current working implementation or was that the proposed solution? I also noticed something interesting that might be a bug. I have an ldif file that is importing a bunch of entries with userCertificate;binary and a bunch with userCertificate (without the ;binary).

The strange part is the ldif entries are exactly the same. They both have the following structure for identifying the certificate:

userCertificate;binary:: (THE BINARY)

however some appear in an ldap search with the ;binary subtype and some appear without it.

I can understand if 389ds decides one way or the other in the implementation but having a mix of both is making it really difficult to properly maintain my environment. Does anyone have any suggestions on how to approach my dilemma? I am not specifically asking for this issue to be solved but more so what is the proper suggested workaround. The desired outcome would be to always have the ;binary and be RFC compliant.

Thank you for taking the time to read this and offering me advice!

Firstyear commented 3 years ago

On 9 Jun 2021, at 03:29, Gregory Walsh @.***> wrote:

Hello,

I have came across this issue recently in my environment and was wondering if I could get guidance in how to continue. Our old LDAP server has the userCertificate;binary attribute for well over 300 entries. We have been testing 389ds as an open source alternative but I am running into an issue with importing my ldifs. On 389ds the userCertificate attribute loses the ;binary subtype. This is critical for my environment since we have scripts that look for the userCertificate;binary keyword in ldap searches . As a hotfix I changed the keyword search to just userCertificate but I was wondering if there is a better alternative to enforce the subtype when reading the ds.

While reading through the comments I tried adding the certificate following the naming sequences:

usercertificate;binary vs userCertificate;binary (Notice the capital 'C')

but it did not work. Is that the current working implementation or was that the proposed solution? I also noticed something interesting that might be a bug. I have an ldif file that is importing a bunch of entries with userCertificate;binary and a bunch with userCertificate (without the ;binary).

The strange part is the ldif entries are exactly the same. They both have the following structure for identifying the certificate:

userCertificate;binary:: (THE BINARY)

however some appear in an ldap search with the ;binary subtype and some appear without it.

I can understand if 389ds decides one way or the other in the implementation but having a mix of both is making it really difficult to properly maintain my environment. Does anyone have any suggestions on how to approach my dilemma? I am not specifically asking for this issue to be solved but more so what is the proper suggested workaround. The desired outcome would be to always have the ;binary and be RFC compliant.

Thank you for taking the time to read this and offering me advice!

;binary is an ldap tag/option.

https://ldapwiki.com/wiki/Attribute%20Options

So I think in this case, you actually want to import without the tag (userCertificate) and then in your client you should request userCertificate;binary as the attribute which should get all the binary values. IIRC the flagging of this as binary comes from schema.

Hope that helps,

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or unsubscribe.

-- Sincerely,

William Brown

Senior Software Engineer, 389 Directory Server SUSE Labs, Australia

vashirov commented 2 months ago

We are closing this issue as it has been inactive for some time and appears to be stale. If the problem persists or you have further information to add, please feel free to reopen this issue or create a new one.