#49059 Correct implementation of rfc4523
Closed: wontfix 3 years ago by spichugi. Opened 7 years ago by firstyear.

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

7 years ago

Metadata Update from @mreynolds:
- Issue close_status updated to: None
- Issue set to the milestone: 1.4 backlog (was: 1.3.7 backlog)

6 years ago

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.

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)

3 years ago

Login to comment on this ticket.

Metadata