Hello, I don't see any conflict in the text, but an omission in 8.19.2. You must read it from the beginning and follow the links given in each paragraph.
8.19.2 explains the octets is a list of subidentifiers, making reference to 8.19.3 and 8.19.4. Here it would have been good that a reference to 8.19.5 has been made also. The references are to explain what is a subidentifier. 8.19.3 explains the count of subidentifiers to encode (= the count of arcs minus 1). 8.19.4 explains what is the first identifier which is a combination of the two first arcs using x*40+y. 8.19.5 explains what are the next subidentifiers. Now if we get back to the reading of 8.19.2, it is explained how the subidentifier is to be encoded (including the first subidentifier computed from 8.19.4). In your examples: 0603813403 is 2.100.3, 0604868d6f02 is 2.99999.2, 060581068d6f02 is 2.54.1775.2. I hope this helps, Bruno KONIK uniGone > -----Message d'origine----- > De : [email protected] [mailto:[email protected]] De la part de > Peter Gutmann > Envoyé : jeudi 10 septembre 2009 11:20 > À : [email protected]; [email protected] > Cc : [email protected] > Objet : Re: [Asn1] Ambiguity in X.690:2002 for OID encodings > > > "Roman V. Gerasimov" <[email protected]> writes: > > >There is neither conflict nor overriding. > > Hmm, in that case I think the text isn't communicating the intent very > well, > or at least if three out of three libraries [0] misunderstood it then > there > appears to be some communications failure present. > > >Please, look at very helpfull example in clause 8.19.5. > > The problem is that this example is somewhat contrived, it demonstrates > an > encoding that would probably never be encountered in real life (my own > ASN.1 > tool, dumpasn1, has been around for about ten years and has seen > reasonably > widespread use - for an ASN.1 tool that is - including being included > in some > Linux distros, but this is the first time anyone's reported this issue > to me, > and that was only because they created a synthetic piece of data with > the > sample encoding from the standard in it). > > >Actually any library must encode/decode OIDs according to X.690 > standard. > > If all three implementations tested (and again, see [0] for a > disclaimer about > the small sample size) get it wrong then perhaps the text should to be > changed > to ensure that the implementers can get it right in future, maybe by > adding a > comment to make it explicit that .4 is used to encode the first two > arcs but > that the result of that encoding then still has to be encoded as per > .2. > > Peter. > > [0] I realise this is a terrible sample size, but it's all I had > available. > As I mentioned in my original post, I'd be interested in results > for any > other ASN.1 libraries, or code that uses ASN.1 (OpenLDAP, OpenSSL, > that > sort of thing). > > I'd also be interested in hearing if anything, apart from the > artificial > example in the standard, requires the continuation-flag encoding > for > the first octet. The current code I have flags it as a decoding > error > because, with no known users of the capability, it could only be an > encoding error if encountered. > _______________________________________________ > Asn1 mailing list > [email protected] > http://lists.asn1.org/mailman/listinfo/asn1 > > ----------------------------------------------------------------------- > ---------------- > Orange vous informe que cet e-mail a ete controle par l'anti-virus > mail. > Aucun virus connu a ce jour par nos services n'a ete detecte. _______________________________________________ Asn1 mailing list [email protected] http://lists.asn1.org/mailman/listinfo/asn1
