Le 21/10/15 18:04, Emmanuel Lécharny a écrit : > 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. > Here is a page on our site where I described the FSA to use in order to > parse an OID : > > http://directory.staging.apache.org/api/user-guide/6.27-oid.html Ok, almsot there.
As usual, it's way more complex than expected. I had to use BigInteger in cases the value is above Long.MAX_VALUE (actually, the limit is 9999999999999999999), and converting the BigInteger to a byte[] where each byte contains a 7 bits value - as requested by the ASN.1 spec - was a kind of a nightmare.
