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
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 (https://github.com/freeipa/freeipa/pull/298.
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"
When do we need this RFE? 1.3.6 or later?
I don't think this is urgent, it can be later.
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
Thanks, William and Thierry! Set it to 1.3.7 backlog.
Metadata Update from @nhosoi: - Issue set to the milestone: 1.3.7 backlog
Metadata Update from @mreynolds: - Issue close_status updated to: None - Issue set to the milestone: 1.4 backlog (was: 1.3.7 backlog)
389-ds-base is moving from Pagure to Github. This means that new issues and pull requests will be accepted only in 389-ds-base's github repository.
This issue has been cloned to Github and is available here: - https://github.com/389ds/389-ds-base/issues/2118
If you want to receive further updates on the issue, please navigate to the github issue and click on subscribe button.
subscribe
Thank you for understanding. We apologize for all inconvenience.
Metadata Update from @spichugi: - Issue close_status updated to: wontfix - Issue status updated to: Closed (was: Open)
Login to comment on this ticket.