openldap-bugs

openldap-bugs@openldap.org

1 participants
20997 discussions

(ITS#5072) Possibly incorrect certificateExactAssertion()
by ando＠sys-net.it 03 Aug '07

03 Aug '07

Full_Name: Pierangelo Masarati Version: HEAD/re24 OS: irrelevant URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (131.175.154.35) Submitted by: ando A certificate in certificateExactAssertion GSER form should be something like (wrapped for readability) { serialNumber 3, issuer rdnSequence:email=ca@example.com,cn=example ca,o=example,st=xx,c=us } according to RFC4523 & RFC3687, as far as I understand it. However, OpenLDAP HEAD uses the form { serialNumber 3, issuer "email=ca(a)example.com,cn=example ca,o=example,st=xx,c=us" } Note the quotes around the DN and the missing "rdnSequence:" prefix. p.

1 0

Re: (ITS#5069) SyncRepl on request
by bgmilne＠staff.telkomsa.net 03 Aug '07

03 Aug '07

On Wednesday 01 August 2007 23:53:22 hadmut(a)danisch.de wrote: > Full_Name: Hadmut Danisch > Version: 2.3.35 > OS: linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (85.180.64.215) > > > This is an enhancement request: > > When having a distributed LDAP structure with a master and several SyncRepl > clients, the clients can do the SyncRepl only on fixed refresh intervals > (e.g. type=refreshOnly, > interval=00:00:20:00) > > However, there are many situations where this is inappropriate, e.g. on > dial-on connections, roaming notebooks, and things like that. > > Therefore, slapd should have a client mode where the SyncRepl process is > performed only on request, but then immediately. There should be an > external trigger to pull, e.g. send a signal oder do a special LDAP > request. slapd should then start a SyncRepl. > > E.g. this could be put in scripts run at connect-time (pppd provides that > kind of scripting), or when notebook autoconfiguration detects (e.g. with > tools like guessnet) that it is connected to the home network to update > it's local slapd. While I'm not saying this feature should not be implemented, I note that there are other solutions for doing off-line authentication on (e.g.) laptops that don't expose the whole DIT (but only credentials that have already been used on the client).

1 0

Re: (ITS#5070) Issues in X.509 certificate parsing
by ando＠sys-net.it 03 Aug '07

03 Aug '07

Kurt Zeilenga wrote: > This and other RFC 4511 BER restrictions do not apply to > BER/DER-encoded attribute values, such as certificates. A cleaner and simpler solution is in HEAD for those serials that fit into a long long, when it's available. Otherwise, arbitrary precision support is required (OpenSSL's bignum, GNU's GMP or so). Please test. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it --------------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Email: pierangelo.masarati(a)sys-net.it ---------------------------------------

1 0

Re: (ITS#5071) ;binary issue
by kurt＠OpenLDAP.org 03 Aug '07

03 Aug '07

On Aug 2, 2007, at 11:01 PM, ando(a)sys-net.it wrote: > Full_Name: Pierangelo Masarati > Version: HEAD/re23 > OS: irrelevant > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (81.72.89.40) > > > I've noticed an issue related to operating on certificates with/ > without ;binary, > as detailed in the table below > > slapadd filter requested attrs > > | ;binary | no ;binary | ;binary | > no ;binary > -------------+--------------+--------------+-------------- > +--------------- > ;binary | results | results | returned | returned > -------------+--------------+--------------+-------------- > +--------------- > no ;binary | no results | results | not returned | returned > > So it seems that if data is loaded with ;binary then search > operations work > regardless of having specified ;binary in search filters or in > requested > attributes, while if data is loaded without, then search operations > only work if > ;binary is omitted. RFC 4523 states that ;binary MUST be used when > transferring > certificates, so perhaps slapd should be either liberal enough to > allow any > combination, or strict enough to prevent those data types from > working without > ;binary. The bug is in allowing a certificate to be loaded without ;binary. -- Kurt

1 0

(ITS#5071) ;binary issue
by ando＠sys-net.it 03 Aug '07

03 Aug '07

Full_Name: Pierangelo Masarati Version: HEAD/re23 OS: irrelevant URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (81.72.89.40) I've noticed an issue related to operating on certificates with/without ;binary, as detailed in the table below slapadd filter requested attrs | ;binary | no ;binary | ;binary | no ;binary -------------+--------------+--------------+--------------+--------------- ;binary | results | results | returned | returned -------------+--------------+--------------+--------------+--------------- no ;binary | no results | results | not returned | returned So it seems that if data is loaded with ;binary then search operations work regardless of having specified ;binary in search filters or in requested attributes, while if data is loaded without, then search operations only work if ;binary is omitted. RFC 4523 states that ;binary MUST be used when transferring certificates, so perhaps slapd should be either liberal enough to allow any combination, or strict enough to prevent those data types from working without ;binary. p.

1 0

Re: (ITS#5070) Issues in X.509 certificate parsing
by kurt＠OpenLDAP.org 03 Aug '07

03 Aug '07

On Aug 2, 2007, at 10:48 PM, ando(a)sys-net.it wrote: > ando(a)sys-net.it wrote: > >> I've an issue with X.509 certificate parsing in HEAD/re24. The >> certificate, >> according to OpenSSL, has a SerialNumber c8:5b:9a:dd:ea:bf:f9:fa >> and HEAD fails >> to parse it because it is an integer with length equal to 9, which >> is larger >> than sizeof(ber_int_t), as tested in ber_getnint() at decode.c: >> 254. The DER >> encoded value is: 2 9 0 200 91 154 221 234 191 249 250. >> Seems to be time >> to get past the sizeof(ber_int_t) limitation... > > ... which would violate RFC 4511 where it states that INTEGER means > from > 0 up to 2^31-1... This and other RFC 4511 BER restrictions do not apply to BER/DER-encoded attribute values, such as certificates. > I have a simple solution for this problem, at the > cost of partially violating rfc 4523: if an integer is larger than > 2^31-1, it could be represented in the certificateExactMatch > normalization in hexadecimal form, much like OpenSSL does. This would > increase interoperability with OpenSSL and be at least self- > consistent, > since all serialNumbers that large would be consistently expanded that > way. Another solution, preserving the decimal representation, would > probably require some arbitrary precision support from external > libraries. If there's consensus, I'd post my simple patch. > > p. > > > > Ing. Pierangelo Masarati > OpenLDAP Core Team > > SysNet s.r.l. > via Dossi, 8 - 27100 Pavia - ITALIA > http://www.sys-net.it > --------------------------------------- > Office: +39 02 23998309 > Mobile: +39 333 4963172 > Email: pierangelo.masarati(a)sys-net.it > --------------------------------------- > > >

1 0

Re: (ITS#5070) Issues in X.509 certificate parsing
by ando＠sys-net.it 03 Aug '07

03 Aug '07

ando(a)sys-net.it wrote: > I've an issue with X.509 certificate parsing in HEAD/re24. The certificate, > according to OpenSSL, has a SerialNumber c8:5b:9a:dd:ea:bf:f9:fa and HEAD fails > to parse it because it is an integer with length equal to 9, which is larger > than sizeof(ber_int_t), as tested in ber_getnint() at decode.c:254. The DER > encoded value is: 2 9 0 200 91 154 221 234 191 249 250. Seems to be time > to get past the sizeof(ber_int_t) limitation... ... which would violate RFC 4511 where it states that INTEGER means from 0 up to 2^31-1... I have a simple solution for this problem, at the cost of partially violating rfc 4523: if an integer is larger than 2^31-1, it could be represented in the certificateExactMatch normalization in hexadecimal form, much like OpenSSL does. This would increase interoperability with OpenSSL and be at least self-consistent, since all serialNumbers that large would be consistently expanded that way. Another solution, preserving the decimal representation, would probably require some arbitrary precision support from external libraries. If there's consensus, I'd post my simple patch. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it --------------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Email: pierangelo.masarati(a)sys-net.it ---------------------------------------

1 0

(ITS#5070) Issues in X.509 certificate parsing
by ando＠sys-net.it 02 Aug '07

02 Aug '07

Full_Name: Pierangelo Masarati Version: HEAD/re24 OS: irrelevant URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (81.72.89.40) Submitted by: ando I've an issue with X.509 certificate parsing in HEAD/re24. The certificate, according to OpenSSL, has a SerialNumber c8:5b:9a:dd:ea:bf:f9:fa and HEAD fails to parse it because it is an integer with length equal to 9, which is larger than sizeof(ber_int_t), as tested in ber_getnint() at decode.c:254. The DER encoded value is: 2 9 0 200 91 154 221 234 191 249 250. Seems to be time to get past the sizeof(ber_int_t) limitation... p.

1 0

Re: (ITS#5064) Issues with openldap 2.2 (Error 34 Invalid DN syntax )
by bgmilne＠staff.telkomsa.net 02 Aug '07

02 Aug '07

On Friday 27 July 2007 17:19:26 pbrinette(a)cc.in2p3.fr wrote: > > 1) both 2.0 and 2.2 are ancient. OpenLDAP 2.3 is mature, and 2.4 is > > about to exit beta stage. Unless the problem is related to a real > > software bug, and it persists either in HEAD/2.4 or in 2.3 code, this > > ITS will be closed. > > Currently, I've no mean to use an openldap 2.3 unless exists an RPM > update package for RHEL 4 (or CentOS). There is no update from RHEL or CentOS, but there are these (mine): http://staff.telkomsa.net/packages/rhel4/openldap/ Since you can install them in parallel, the upgrade path is quite easy ... (slapcat|slapadd2.3 after configuration). There is also: http://staff.telkomsa.net/packages/rhel3/openldap/ Regards, Buchan

1 0

(ITS#5069) SyncRepl on request
by hadmut＠danisch.de 01 Aug '07

01 Aug '07

Full_Name: Hadmut Danisch Version: 2.3.35 OS: linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (85.180.64.215) This is an enhancement request: When having a distributed LDAP structure with a master and several SyncRepl clients, the clients can do the SyncRepl only on fixed refresh intervals (e.g. type=refreshOnly, interval=00:00:20:00) However, there are many situations where this is inappropriate, e.g. on dial-on connections, roaming notebooks, and things like that. Therefore, slapd should have a client mode where the SyncRepl process is performed only on request, but then immediately. There should be an external trigger to pull, e.g. send a signal oder do a special LDAP request. slapd should then start a SyncRepl. E.g. this could be put in scripts run at connect-time (pppd provides that kind of scripting), or when notebook autoconfiguration detects (e.g. with tools like guessnet) that it is connected to the home network to update it's local slapd. regards Hadmut

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs