Something about this point is also mentioned in the book "ASN.1 communication between Heterogeneous Systems by Mr Dubuisson".
BitStringValue(when IdentifierList is used): ... Designers should then make sure that the presence or absence of trailing zerors remains meaningless for the application(no semantics should be assosicated with this). This rule has been changing depending on the versions of the ASN.1 standard; it should therefore be applied with great care. ... Ed --- John Larmouth <[EMAIL PROTECTED]> wrote: > This is a really tricky one! Specifications in > earlier versions of > ASN.1 were often imprecise in tnis area (I might > even say downright > ambiguous!). But I do not think they were actually > erroneous. > > It was always (I think) the case that DER required > the omission of all > trailing zero bits when there was a named bit list, > right from the very > first version of DER (although maybe not in the very > original X.509 spec). > > It was also always the case that anything that was a > DER encoding was a > valid BER encoding. > > So a DER encoding with a transmission of a single > one-bit (with all > other bits in the octet flagged as unused) would be > a valid BER encoding > for an abstract value with a SIZE constraint of 16 > to 32, or whatever. > > I am sure the text *implied* this in all previous > versions of ASN.1. > Whether it clearly *said* it may more debatable! > But I will be > surprised if you can find text in older versions > that clearly > contradicts the above. > > But then I could be wrong! > > John L > > > Edmond G wrote: > > The one open point is different handling of this > case > > in ASN.1 standards. So if that's an older protocol > > using ASN.1 standard 208,209 , the adding and > removing > > of zeros (trailing bits) is not allowed. So for > the > > decoder (in this case) would means invalid value > and > > decoding error when the SizeConstraint is > violated. > > Is this right? > > > > Ed > > > > --- John Larmouth <[EMAIL PROTECTED]> > wrote: > > > >>There is absolutely no reason why any tool should > >>not enforce > >>constraints, whatever the encoding that is in use, > >>and whatever the form > >>of a constraint - even a comment, if the tool is > >>clever enough. > >> > >>That was not the issue. The issue was not whether > >>you could transmit > >>abstract values outside the size constraint - you > >>can't (legally), in > >>BER or in PER or in DER or in XER or anyhwere > else. > >>The issue was > >>whether the given encoding was a valid BER > encoding > >>for a value in the > >>range of the size constraint, and it was. > >> > >>John L > >> > >> > >>Phillip H. Griffin wrote: > >> > >>>I don't disagree in a purely "technical" sense. > >> > >>But I do agree > >> > >>>that it is up to the protocol that uses ASN.1, > and > >> > >>not to ASN.1 > >> > >>>alone, as to what is actually a valid message. > >>> > >>>The constraint was intentionally placed in the > >> > >>message definitions. > >> > >>>I would assume that this rule was meant to be > >> > >>enforced. But where > >> > >>>this rule is enforced is a key issue. > >>> > >>>ASN.1 tool vendors and ASN.1 application > providers > >> > >>may provided > >> > >>>a "strict" switch that causes the constraints to > >> > >>be enforced so that the > >> > >>>protocol rules are obeyed as written, even if the > >> > >>ASN.1 standards > >> > >>>do not require the constraints to be enforced in > a > >> > >>given encoding > >> > >>>rules. > >>> > >>>The encoder tool obeying the ASN.1 as written > >> > >>would then detect the > >> > >>>encoding to be in error. But a 'vanilla' coder > >> > >>tool might choose to just > >> > >>>obey the ASN.1 standards and leave it to the > >> > >>underlying application > >> > >>>that uses the coder tool to enforce the rest of > >> > >>the protocol. > >> > >>>That is the underlying application, not the coder > >> > >>tool itself, may be > >> > >>>required to enforce the constraint specified in > >> > >>the protocol. Clearly some > >> > >>>piece of code must enforce the protocol as > written > >> > >>or the constraint should > >> > >>>never have been written at all. > >>> > >>>A tool vendor may allow his tools to "see" the > >> > >>constraints and enforce > >> > >>>them even in BER. This takes the burden off of > the > >> > >>underlying application > >> > >>>and places the burden for enforcing the protocol > >> > >>on the coder tool. > >> > >>>The SET protocol was defined such as this using > >> > >>ASN.1 and encoded in > >> > >>>DER. A set of guidelines was written for testers > >> > >>that made it clear what > >> > >>>errors had to be detected by implementers of the > >> > >>protocol. And in some > >> > >>>cases, the guidelines made it clear that the > coder > >> > >>tool was required to > >> > >>>enforce some protocol behavior that was outside > of > >> > >>the scope of the > >> > >>>ASN.1 standards. > >>> > >>>This situation sounds like the SET case and would > >> > >>seem to need some > >> > >>>guidance for implementers as to what is and what > >> > >>is not a valid protocol > >> > >>>message - not merely what is valid ASN.1. > >>> > >>>Phil Griffin > === message truncated === __________________________________________________ Do you Yahoo!? Yahoo! Tax Center - forms, calculators, tips, more http://taxes.yahoo.com/
