Le 20/10/15 21:40, Emmanuel Lécharny a écrit : > Le 20/10/15 21:33, Radovan Semancik a écrit : >> Hi, >> >> Today I realized that there are some quite unusual OIDs out there, >> such as: >> >> 2.25.81407072025111374527560065493494091452 >> >> This is in fact UUID in an OID form, as specified in ITU-T X.667. The >> trouble is that the API seems to assume that each OID arc can fit into >> Java long (org.apache.directory.api.asn1.util.Oid:206). And this >> strange OID obviously does not fit there. >> >> It is not really a problem in relaxed mode as OID validation errors >> are ignored there. But it might be a problem in strict mode. However, >> I'm not really sure how to fix the code (switch to BigInteger instead >> of long?). As I'm using relaxed mode I'm not really affected by this. >> But I wanted to let you know that this might be a potential problem ... >> > The Queue<long> we use was convenient as much as we don't have longer > values. We could use BigInteger instead, or even better : simply check > that we have only '.' and ['0'-'9'] chars, in a loop. Working on it. I have created a JIRA : https://issues.apache.org/jira/browse/DIRAPI-260
There is also another bug in the implementation, we don't encode correctly the joint-iso-itu-t node (which value is 2 in teh first node), as we incorrecly assume the value of teh second node will be below 40. I have also created another issue for that : https://issues.apache.org/jira/browse/DIRAPI-261 In order to avoid using longs, I'm now using a FSA (work in progress) ASN.1 -- Communication between Heterogeneous Systems
