Correct implementation of rfc4523

[389-ds-bot]

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

• Created at 2016-12-02 09:52:44 by firstyear (@Firstyear)
• Assigned to nobody

---

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]

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

• Change schema syntax of some attributetypes (using 'certificate syntax' (1.3.6.1.4.1.1466.115.121.1.8) rather than 'Octet String' (1.3.6.1.4.1.1466.115.121.1.40)). I think it looks similar to https://fedorahosted.org/389/ticket/48142. It was moved to 'FUTURE' because of the cost to implement usercertificate syntax and few ldapclient asking for it.

• Change the way 'certificate syntax' attributes are returned/requested/filtered. currently ';binary' is managed as a subtypes. Changing this can create compatibility issue. It looks valid to implement it as a transfert option but is not a priority for freeipa (ipaldap: handle binary encoding option transparently freeipa/freeipa#298.

[389-ds-bot]

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:
- On indexing: nothing to do more
- On filter evaluation: nothing to do more
- On returned values:
- If LDAP_V3
- if subtype/option requested: nothing to do more
- if option ';binary' not requested: add the option to the returned value (1)

    - If not LDAP_V3
        - remove option/subtype from return value (2)

'''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]

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]

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]

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:

• it will change the behavior of returned ';binary' attributes and that can break applications
• According to https://fedorahosted.org/389/ticket/49059#comment:2, we can return duplicated values for a same attribute

[389-ds-bot]

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]

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

Metadata Update from @nhosoi:

• Issue set to the milestone: 1.3.7 backlog

[389-ds-bot]

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

Metadata Update from @mreynolds389:

• Issue close_status updated to: None
• Issue set to the milestone: 1.4 backlog (was: 1.3.7 backlog)

[walshg3]

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]

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